TCP server stream loses data

Question

Hi,
I have a high visibility application that has a bug in it that I'd like some
sharp minds of NI discussion forum to make a suggestion about.
The app is on the International Space Station. I have a LV executable on a
laptop on the ISS that sends TCP and UDP data to a LV executable on an earth-bound
computer.
The path is not a standard or "trivial" IP but it is intended to be equivalent to
a standard IP.  The catch comes when some data bytes are lost en route.
When this happens, the earth-bound LV says something like "Not enough memory
to complete operation"
Here's what we found...
=======================================================
The TCP Server (on the ISS) send a TCP data stream with the following format...
...LLLLSTART$d1$d2...$dN#llllSUMccccENDLLLLSTART...
where
    * LLLL is a 32bit binary integer with the number of bytes in the following packet beginning with the text string START and ending with the text string END.
    * $, #, START, SUM, and END are delimiters.
    * d1, d2, ... dN are text string data values.
    * llll is a text string with the decimal number of bytes beginning with the text string START and ending with # symbol.
    * cccc is a text string with the decimal number checksum of the bytes beginning with the text string START and ending with # symbol.
The TCP Client (on earth) reads 4 bytes as LLLL, then reads LLLL bytes (usually about 85 bytes) as the packet beginning with the text string START and ending with the text string END.
The error comes when the LLLL data is lost, so the TCP Client reads four bytes (probably S,T,A,and R) as LLLL, which convert to a number that is very large, then reads LLLL bytes (maybe 50M) but this read fails because there is not enough memory to read that much data.
The fix entails ensuring that LLLL is a reasonable size (like 20 to 200) and ensuring that the data packet begins with START.  The difficulty is how to restructure the code to reset the packet loop when LLLL is out of bounds or when that START header is not present.
=================================
My quandary is that in LV, I can't see what's going on in the TCP Server or
TCP Client vis.
Any suggestions will be appreciated.
JIM
Solved!
Go to Solution.

Answer 1

I would look at configuring the Nagle Algorithm and/or Delayed ACK options on your remote and earth-bound stations.
Do LabVIEW TCP Functions Use the Nagle Algorithm?
TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK
From wikipedia:
Applications such as networked multiplayer video games expect that actions in the game are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY  to bypass the Nagle delay.
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness