AnsweredAssumed Answered

Should RTCS_selectall() return on a TCP ack?

Question asked by Joel Fieber on Jun 7, 2013
Latest reply on Aug 15, 2013 by Joel Fieber

MQX 3.8



I am using all the default socket options for this connection.


From the user guide RTCS_selectall (for a stream socket) should return on:


Data or Shutdown requests that are initiated by the remote endpoint.

But I'm seeing after a send(), my call to RTCS_selectall() is returning (after blocking only briefly) with a valid socket handle when NO data was transmitted (verified with Wireshark). The code falls through to recv() but blocks indefinitely, there is no data to receive.

I believe found the code within RTCS that wakes my task from RTCS_selectall(). It is in TCP_Process_ack() [tcp_send.c]

        if ( tcb->sndlen == 0 ) {

            ** Notify socket layer in case some task is blocked on select()
            ** waiting for this data.

            _SOCK_select_signal(tcb->SOCKET, tcb->state, 1);

            TCP_Event(tcb, TCPS_TACKED);   /* all data to send got acked */

        } /* Endif */

So, this seems totally contrary to the point of TCP. Yet, the comment indicates this is a useful move. Why should my server care that the client TCP stack has ACK'd my data? That is a layer-3 acknowledgement. It doesn't tell me anything about the client application. And the send() call itself was blocking.. it wouldn't have returned until RTCS had buffered all the data.

What am I doing wrong here? This feels like a bug and yet has existed in RTCS since MQX 3.1.. although curiously not in RTCS 2.97.

If it's not a bug.. how do I distinguish between RTCS_selectall() waking me up with data versus no data (only a TCP ack received)?