Android ws Streaming

#1

Hello,

I'm using Autobahn in an Android app which communicates with a device
that gathers ECG signals and sends it to a python server (also using
Autobahn) to be filtered, downsampled, and retrieved in order to be
plotted back in the Android smartphone (I've already talked about this
in other threads, when having other issues).

I have everything working now. My sampling rate is 1000Hz, and in
order for this to be the most "real-time" possible I'm sending a ws
message to the server every 100ms with 100 samples (in strings with
short[] format, and a little header for the server (about 10 chars)),
so I'm sending messages through the AB ws at 10Hz. The thing is: as I
start sending data at this rate, the plot immediately starts to drag
and after a while I easily end up with a 30 seconds (or even more, as
it seems cumulative) of delay.

My suspicion is that messages start to pile up in one of the ws
connection (probably client) as I probably can't send one message
until the previous is completely received, causing the cumulative
delay.

I read a little about websockets and found out that they can handle A
LOT more and bigger messages/s than I I'm requesting mine to. Also
found that AB's Android imp. is somewhat advanced, as is message
based, and that what would probably help me would be using streaming.

My questions are: Is it planned streaming support for AutobahnAndroid?
If yes, is there an ETA? And also (and probably more important for
now) is there a (clever) way for me to use the message based API and
avoid the (cumulative) delay?

Regards,

Michel Cânovas

0 Likes

#2

Could, turnig off Nagle, help me? If so, how should I do it? I read somewhere that it was ON by default…

Segunda-feira, 7 de Maio de 2012 16:59:32 UTC+1, Michel Cânovas escreveu:

···

Hello,

I’m using Autobahn in an Android app which communicates with a device

that gathers ECG signals and sends it to a python server (also using

Autobahn) to be filtered, downsampled, and retrieved in order to be

plotted back in the Android smartphone (I’ve already talked about this

in other threads, when having other issues).

I have everything working now. My sampling rate is 1000Hz, and in

order for this to be the most “real-time” possible I’m sending a ws

message to the server every 100ms with 100 samples (in strings with

short[] format, and a little header for the server (about 10 chars)),

so I’m sending messages through the AB ws at 10Hz. The thing is: as I

start sending data at this rate, the plot immediately starts to drag

and after a while I easily end up with a 30 seconds (or even more, as

it seems cumulative) of delay.

My suspicion is that messages start to pile up in one of the ws

connection (probably client) as I probably can’t send one message

until the previous is completely received, causing the cumulative

delay.

I read a little about websockets and found out that they can handle A

LOT more and bigger messages/s than I I’m requesting mine to. Also

found that AB’s Android imp. is somewhat advanced, as is message

based, and that what would probably help me would be using streaming.

My questions are: Is it planned streaming support for AutobahnAndroid?

If yes, is there an ETA? And also (and probably more important for

now) is there a (clever) way for me to use the message based API and

avoid the (cumulative) delay?

Regards,

Michel Cânovas

0 Likes

#3

You can turn off Nagle by doing

factory.setProtocolOptions(tcpNoDelay = False)

before you do

listenWS(factory)

All options are documented here

http://autobahn.ws/developers/reference/python/websocketserver.html#factory

However, I doubt that this is the cause of the issue. Also,
AutobahnAndroid does easily handle messaging at >10Hz .. using the
message-based design. I'd probably try to create a stripped down
client that does send random messages at 10Hz by using a simple timer
and then work from there ..

···

On May 10, 12:27 pm, Michel Cânovas <michelm...@gmail.com> wrote:

Could, turnig off Nagle, help me? If so, how should I do it? I read
somewhere that it was ON by default...

Segunda-feira, 7 de Maio de 2012 16:59:32 UTC+1, Michel Cânovas escreveu:

> Hello,

> I'm using Autobahn in an Android app which communicates with a device
> that gathers ECG signals and sends it to a python server (also using
> Autobahn) to be filtered, downsampled, and retrieved in order to be
> plotted back in the Android smartphone (I've already talked about this
> in other threads, when having other issues).

> I have everything working now. My sampling rate is 1000Hz, and in
> order for this to be the most "real-time" possible I'm sending a ws
> message to the server every 100ms with 100 samples (in strings with
> short[] format, and a little header for the server (about 10 chars)),
> so I'm sending messages through the AB ws at 10Hz. The thing is: as I
> start sending data at this rate, the plot immediately starts to drag
> and after a while I easily end up with a 30 seconds (or even more, as
> it seems cumulative) of delay.

> My suspicion is that messages start to pile up in one of the ws
> connection (probably client) as I probably can't send one message
> until the previous is completely received, causing the cumulative
> delay.

> I read a little about websockets and found out that they can handle A
> LOT more and bigger messages/s than I I'm requesting mine to. Also
> found that AB's Android imp. is somewhat advanced, as is message
> based, and that what would probably help me would be using streaming.

> My questions are: Is it planned streaming support for AutobahnAndroid?
> If yes, is there an ETA? And also (and probably more important for
> now) is there a (clever) way for me to use the message based API and
> avoid the (cumulative) delay?

> Regards,

> Michel Cânovas

0 Likes