This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Dealing with a split TCP message when receiving data

I am sending a TCP message with 1074 bytes from my PC to the CC3000 and every once in a while I will see two 536 byte messages in the Wire Shark trace.  My code does not handle this since I check the number of bytes receive from recv() and compare it to the message length which I have embedded in the first 2 bytes of the TCP data. I am trying to figure out how recv() works.  If I execute recv() and get a length of 536 meaning only have of the message was received.  If I go back a few ms later and execute recv() will I see 1074 bytes or will I see 536 again?  It is hard to reproduce otherwise I would just test and figure it out.

Thanks, Kevin

  • Hi Kevin,

    This should depend on the sequence number that is provided by the TCP stack at the client side. And each of these PDUs received at the CC3000 should be re-ordered based on the sequence number. Therefore, you should receive 536 bytes. Please check the sequence numbers in the Wireshark.

    Thanks & Regards,
    Raghavendra

  • With further investigation, I am seeing a retransmission just prior to the PC sending out a shorter data length.  Right now my main focus is on the CC3000 not being able to send or receive a TCP or UDP messages after the series of re transmissions occurs.  The only way out is to reset the CC3000.  This only seem to occur when the CC3000 and the PC are not on the same access point.  If both device are on the same access point they communicate all day with no problems.