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

MCF52259

CW10.2

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)?



Thanks,

+Joel.

 

Outcomes