How can I prevent TCP from concatenating messages?

[D. Haaland]

My client program (written in CVI 6.0) goes into a loop to send 10 TCP messages, one right after another, to the server. Each message is sent by a separate call to ClientTCPWrite. The server program (also written in CVI 6.0) makes one call to ServerTCPRead, and receives all those 10 messages concatenated into one. It would be much simpler for me if they were received exactly the same way as they were sent. At first, I didn't realize that they were concatenated, and I thought the later messages were getting lost. My software was not smart enough to look beyond the first message to see if there was more received. I talked with Pravin Borade at NI tech support about it, and emailed him my code, and he said it worked fin
e on his machine. All 10 messages were received separately. Apparently there is a way to get TCP not to concatenate the messages, but I don't know how to do it. Mr. Borade is using the following computer set-up:
Windows 2000 pro, service pack 1. Gateway pentium 3 with 130MB RAM. The network card is 3Com Etherlink XL 10/100 PCI.

I am using a Pentium II, 350 MHz, 96 MB RAM, Windows 2000 Professional, with 3Com Etherlink XL 10/100 PCI NIC. If anyone has knowledge about this issue please let me know. Thank you.

[Chris Matthews]

Sorry TCP doesn't work that way. It's a data stream and there is no notion of message packaging. The different behavior you are seeing is just timing related. The CVI TCP server events will notify you when there is new data from the client, but not in message "packets" created by separate Client write calls. What you should do is incorporate a message header that lets you parse the message. For example, put a integer at the first of each message that specifies length of the message. Then, you will know how much data is included in that message and how to break it off from the start of the next message. Pretty much all TCP communication programs rely on such message headers to parse the data stream.

Many people try to rely on the messages being "space
d" enough to be read separately, but it is not a good idea. Transmission lag, other activity in the server program and many other things can cause this to break down and messages to get read together.

Best Regards,

Chris Matthews
National Instruments

[menchar]

We've had good luck using a simple worker thread to "watch" the incoming TCP byte stream and "parse" the stream into messages, then signal the main thread (using Win32 events is one way, or a simple flag in the form of a thread-safe variable) that a message has arrived when a complete message has been detected.

CVI supports multithreading so it's relatively easy to do this.