• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 477 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3000 combining separate TCP packets received less than 2 seconds apart

chad ely
Intellectual 480 points

TI,

I am seeing what I think is an issue, where the CC3000 is combining packets that arrive to it within 2 seconds of eachother.  Is this expected behavior?  I have verified that the packets are indeed sent separately but when read from the CC3000 they are combined.  The data is very short, less than 7 characters and happens mostly when the same packet is sent back to back.  I have seen up to 3 separate packets combined into one when reading from the CC3000.  Just to be clear this is from one call to recv.

I am also seeing lots of ack errors when capturing traffic via wireshark.  Everything starts out fine but then the other device starts complaining about acks being duplicates and some other errors.  Should I be concerned about this or is it just wireshark getting confused because I restarted the devices at some point or something like that?

Thanks,

Chad

p.s. I am on the latest fw.

  • 0
    Expert 2685 points

    Hi Chad,

    Small packets that arrive less than 2 seconds apart are being combined due to the Nagle's Algorithm, which you can read more about on Wikipedia:

    http://en.wikipedia.org/wiki/Nagle%27s_algorithm

    The Nagle's Algorithm is on by default in all Berkeley sockets implementations. It can be turned off by using setsockopt(...) with the TCP_NODELAY flag, but unfortunately the CC3000 API does not support this. This in my opinion is a significant shortcoming and should be addressed by TI.

    There is a sloppy workaround - make your packets large enough, so that the algorithm does not kick in. I am not sure what the right size is, but it can be easily discovered by trial and error.

    I am not sure about the ack errors - maybe someone else can answer this.

  • 0 in reply to Ivor Sargoytchev
    Intellectual 480 points

    Ivor,

    Interesting, I knew that could be an issue on the send side but did not realize that could be an issue on the receive side.  I am sending from java and do have to set that flag to get individual packets sent to the CC3000 but I must agree that this should be fixed.  It is causing me all kinds of grief right now trying to work around it.  

    I am doing software acks and this happens most when receiving them and thus why my packets are so short.  Problem is I may have to implement a full buffer solution like java does with readline and that will be a headache and something I should be able to avoid.  Please help TI.

    Thanks,

    Chad

  • 0 in reply to chad ely
    TI__Mastermind 27095 points

    Hi Chad,

    I will check on this internally and get back to you. Can you please give a bit of background on how you are executing this test? This will help.

    For instance, after the establishing a connection with the 2 clients, what does each recv on the respective client_fd would store in the receive buffer? 

    Thanks & Regards,
    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Intellectual 480 points

    The CC3000 is the TCP server and I am using my android smartphone to connect as the client.  When the client sends quick enough the CC3000 starts combining segments.  When I look at my capture of the traffic the CC3000 and my phone are getting confused with the seg and ack numbers for the segments and then I  get stuck waiting for the buffer command to come back(opcode 4100) from the cc3000.  It seems like the two are connected but I am not sure which is causing it.  I am gonna get a good capture today and post it.

    Thanks,

    Chad

  • 0 in reply to Raghavendra Shenoy
    Intellectual 480 points

    It seems my issue here was actually caused by a workaround form TI to MDNS not working in this release.

    " ii) For the mDns issues, after the WLAN connection is completed, please make a call to 'gethostbyname' with host_name set to "localhost".
    After this, make calls to "mdnsAdvertiser"."

    Seems like the workaround was not tested at all and caused me to waste two weeks thanks TI.

    Chad