AnsweredAssumed Answered

RTCS send function blocks on send for missing socket devices

Question asked by Matthew Miller on Mar 11, 2014
Latest reply on Mar 11, 2014 by Martin Latal



I've got an application where I'm serving data to connected devices (ipads, droid tablets) so that they can update their user interfaces to reflect the system state.  So whenever the system state changes, I go through all connected sockets and send the updated data:

result = send(socketHandle, dataPtr. dataLength, 0);


And everything works great.  However, I find that if one of my connected devices loses the socket ungracefully (for example, changing wifi networks on the ipad), my application will continue to send the updates, and result will continue to show the proper number of bytes sent.  Eventually, I'm guessing once the tx buffer is filled, the send command blocks.  This is the only indication I have that the message was not actually sent.


I've tried changing the socket options for OPT_SEND_NOWAIT, but it doesn't seem to affect this behavior.


It may be relevant to note that if the missing client returns to the network, the send unblocks and all previous messages are sent.


Likewise, I've found if, after the send blocks, I use a separate task to send a:

shutdown(socketHandle, FLAG_ABORT_CONNECTION);


... the task containing the send unblocks.


One final piece of information - when the client closes the socket normally, my task that reads for data on the socket gets a RTCS_ERROR in its:

result = recv(...)

... and performs its own shutdown.  So I only appear vulnerable to sockets that I think are still open, but the device isn't actually connected any longer.


So my question:  is there a methodology of determining if the message packet has actually been sent?  Maybe a way to see how full the tx buffer is before calling send?  Or alternatively, do I need a supervisory task to monitor for this blocked condition and force the socket shutdown?


Thanks for the help - please let me know if more information would help.