TCP Write sends length 0 string on occasion

[jmburns]

Hi All,

I have an application in LabVIEW 8.6.1 that writes commands via TCP/IP to an embedded system and then looks for a response.  I have been noticing occasional hiccups when running the program where I get a timeout from my TCP Read.  To try to figure out where the problem is, I built a tester program to write a command, read the response, and write another command.  I put this in a loop and it will write out a few thousand commands with no problem, but then I'll get a timeout.  To determine whether the problem is on the LabVIEW or embedded side, I have an ethernet sniffer going.  When I get a timeout I stop the LabVIEW program and look at the sniffer results.  It shows that the last packet "sniffed" was of length zero, but the Bytes Written output from the TCP Write says it has written 6 bytes.  So it seems that the reason I'm getting a timeout in my TCP Read is that LabVIEW hasn't actually written anything out, even though it thinks it has.

 I'm at a bit of a loss here to know how to proceed.  Has anyone experienced this before?  Any suggestions on what to try next?

Thank you,

Jason

[Kristen_K.]

Hi Jason,

What's the error code for the timeout?  Here's a document with the common TCP timeout errors:

TCP/IP Error Codes and Related Time-out Issues in LabVIEW

 Can you try forcing a timeout and comparing the sniffer information from this test to the one you've mentioned?  Also, have you noticed and regularity or pattern to the timeouts?

Kristen H.

[jmburns]

Hi Kristen,

Thanks for commenting.  The TCP Read timeout is a regular timeout error code of 56.  The timeout has been set to a very generous 3 seconds, but still happens.  The TCP Write does not throw any error - seems to think it has written the data.  Unfortunately I can find no pattern to the timeouts - once it will happen after 300 times, the next after 3000.   If I force a timeout by stopping the embedded code, the sniffer sees the six bytes sent, and I just get no reply.  Any ideas?

Thanks,

Jason

[Mark_Yedinak]

I have sent literally billions of bytes of data using the TCP VIs over the years. Specifically, I have been writing networking tests using LabVIEW. I have never encountered the issue you are describing. First, you should be aware that if you send multiple "packets", let's say 6 bytes each, you may not get an individual packet for each "packet" you send. The TCP stack can and does buffer data and send the data in a single TCP packet. It does this to maximize the efficiency of the data communications. Whether it does this or not depends on how quickly you send your individual packets of data.

In your application are you transmitting data in only one direction? That is there are no responses to the packets you send. A 0 length TCP packet could simply be an ACK packet and not necessarily carry any data. Are you sure that your application is correct? Have you tried using NI Spy to see what you are transmitting and receiving?

[jmburns]

Hi All,

Thanks for your help.  It appears to be an issue with the embedded application, which we're looking into now.  

Thank you,

Jason