Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Anyone familiar with the internals of the ISOCKET module.

I am opening a socket to listen to a data stream. I am receiving
about 200 bytes every 1.5 - 2.0 seconds. When this data comes in it is parsed and display updates are made.

Also at the same time the user can press up and down buttons which also cause display updates.

Every so often I need to send about 30 bytes back upstream through the socket to change the data feed.

However, sometimes it seems that sending data upstream never happens. Either the socket never becomes writeable or the data never appears to leave the device.

My hunch is that the inbound data rate is preventing the socket from ever being able to enter a writeable state.

Any ideas?

On at least some devices you can open more than one socket, so you may be able to do it that way.
Since you receive data every 1.5 seconds or so, why not just queue the 30 bytes to be sent the next time the socket finishes a read? That way you know it wont be busy starting another read.
I always do a send/receive pair from the handset, and a receive send on the server, so I have not experimented with doing both at the same time.

On at least some devices you can open more than one socket, so you may be able to do it that way.
Since you receive data every 1.5 seconds or so, why not just queue the 30 bytes to be sent the next time the socket finishes a read? That way you know it wont be busy starting another read.
I always do a send/receive pair from the handset, and a receive send on the server, so I have not experimented with doing both at the same time.

Hmmm...I can try that, but I won't be able to guarantee that the socket will be writeable at that moment will I?

Hmmm...I can try that, but I won't be able to guarantee that the socket will be writeable at that moment will I?

Quote:Originally posted by gscott2112
Hmmm...I can try that, but I won't be able to guarantee that the socket will be writeable at that moment will I?
I am not sure what you mean by this. The Write/Read pairs you do are under your control. Perhaps you can elaborate on the whole design (client and server).

Quote:Originally posted by gscott2112
Hmmm...I can try that, but I won't be able to guarantee that the socket will be writeable at that moment will I?
I am not sure what you mean by this. The Write/Read pairs you do are under your control. Perhaps you can elaborate on the whole design (client and server).

Sorry, I was referring to your suggestion to try writing after every read, not the dual socket implemention. Dual sockets won't work for me, there are other non-brew clients connecting to this server and changing all client interfaces is unlikely.
I can ATTEMPT to write to write to the socket after every read is performed, but the socket may very well return a WOULDBLOCK error, meaning I have to call ISOCKET_Writeable() anyways.
My client sends some information over the socket to tell the server which data stream it wants to hear, at which point the server sends different information back. These streams create real-time selection lists.
The only time I am REALLY seeing problems is when the user starts scrolling rapidly. To keep the UI snappy I am painting immediately in response to those events. When I rapidlly hit the down key and attempt to scroll numerous times, those events are being queued up by the OS. I believe that in the time required to handle such events, the ISOCKET input buffer is being filled since I am delayed from reading from it by handling UI events. One of these UI events will eventual cause a normal condition where the application needs to switch topics to show a different list of data.
At this point I never seem to be able to send data back upstream to do so. It SEEMS like I am getting a valid ISOCKET_Write() result, but that the implementation is not immediately sending data out at that point, but qeueing it up and waiting for an opportunity to do so.
(YES the data being sent to and from the server is correct. This functions normally when not handling very frequent UI events.
Also runs on J2ME and desktop clients, so the server is a very unlikely failure point for this situation)
Hope that helps clarify a little...

Sorry, I was referring to your suggestion to try writing after every read, not the dual socket implemention. Dual sockets won't work for me, there are other non-brew clients connecting to this server and changing all client interfaces is unlikely.
I can ATTEMPT to write to write to the socket after every read is performed, but the socket may very well return a WOULDBLOCK error, meaning I have to call ISOCKET_Writeable() anyways.
My client sends some information over the socket to tell the server which data stream it wants to hear, at which point the server sends different information back. These streams create real-time selection lists.
The only time I am REALLY seeing problems is when the user starts scrolling rapidly. To keep the UI snappy I am painting immediately in response to those events. When I rapidlly hit the down key and attempt to scroll numerous times, those events are being queued up by the OS. I believe that in the time required to handle such events, the ISOCKET input buffer is being filled since I am delayed from reading from it by handling UI events. One of these UI events will eventual cause a normal condition where the application needs to switch topics to show a different list of data.
At this point I never seem to be able to send data back upstream to do so. It SEEMS like I am getting a valid ISOCKET_Write() result, but that the implementation is not immediately sending data out at that point, but qeueing it up and waiting for an opportunity to do so.
(YES the data being sent to and from the server is correct. This functions normally when not handling very frequent UI events.
Also runs on J2ME and desktop clients, so the server is a very unlikely failure point for this situation)
Hope that helps clarify a little...

"ISOCKET input buffer is being filled since I am delayed from reading from it by handling UI events. One of these UI events will eventual cause a normal condition where the application needs to switch topics to show a different list of data.
(1c) is not finished?"
Still seems like a timing issue (like threaded versus cooperative multitasking). Are you using IThread? (I have not used this, but I would be interested in knowing how well it works).
If not, and everything is on the same thread, then it seems you need to decide when in the UI would be a good time for a "Please wait" type dealio while you finish reading data from the socket (at which point you would ignore anything that requires an immediate screen update until you can do so).
Perhaps someone from Qualcomm can verify the behavior of ISocket with respect to IThread....

"ISOCKET input buffer is being filled since I am delayed from reading from it by handling UI events. One of these UI events will eventual cause a normal condition where the application needs to switch topics to show a different list of data.
(1c) is not finished?"
Still seems like a timing issue (like threaded versus cooperative multitasking). Are you using IThread? (I have not used this, but I would be interested in knowing how well it works).
If not, and everything is on the same thread, then it seems you need to decide when in the UI would be a good time for a "Please wait" type dealio while you finish reading data from the socket (at which point you would ignore anything that requires an immediate screen update until you can do so).
Perhaps someone from Qualcomm can verify the behavior of ISocket with respect to IThread....

You may be running into Nagle's algorithm, where the TCP stack attempts to coelecse multiple small writes into one TCP packet. Does your 30 bytes never leave the device, or is it merely delayed?

You may be running into Nagle's algorithm, where the TCP stack attempts to coelecse multiple small writes into one TCP packet. Does your 30 bytes never leave the device, or is it merely delayed?

Hey Guys,
Thanks for the help. Line me up and shoot me for mental lapse on this one. Took me way more many debug statements than it needed to, but I figured out my problem.
Unfortunately I had to port a synchronous based protocol (political reasons) that doesn't include termination sequences nor packet length headers. :(:(:(
I just happened to get lucky once my stream started. Once I interrupted the stream with the write call, suprise suprise, my read call wasn't reading a full packet. Bah...
(removing egg from face)

Hey Guys,
Thanks for the help. Line me up and shoot me for mental lapse on this one. Took me way more many debug statements than it needed to, but I figured out my problem.
Unfortunately I had to port a synchronous based protocol (political reasons) that doesn't include termination sequences nor packet length headers. :(:(:(
I just happened to get lucky once my stream started. Once I interrupted the stream with the write call, suprise suprise, my read call wasn't reading a full packet. Bah...
(removing egg from face)