LabWindows/CVI
How can I force TCP data to transmit in only one message?
Everything is converted to ASCII. The number of parameters are fixed, as is their formatting, so the length of the string should be very similar if not the same every time. Sometimes I get the first message and it is only ~8 numbers. Other times it could be half of the message. It is random. Right now I am working on parsing it better by taking the substring that starts at 0 and ends at the index before CONTROLS or SAFETIES. I can stand to lose a CONTROLS message or SAFETIES message because they are just displayed on the screen. I don't want to lose the DATA message because the data goes to SQL at 1 Hz. Each time I drop a data message I lose a row of data.
TCP is a streaming protocol, not a datagram protocol. It means that it guarantees that all bytes arrive in the same order than how they were sent, but it does not guarantee that the messages chunks are arriving in the same size than what they were send. The basic principle of TCP is that parts of the message could get routed over a relay in Singapore and other parts could go through a relay in the town next to you. In the end the TCP stack will make sure that the data arrives at your application in the same exact order as it was send or not at all, if some packages got lost and didn't arrive even after several retry requests.
Consider it similar to a binary file. It doesn't really matter if you wrote the file in 1000 little chunks of 100 byte each or in 10 chunks of 10000 bytes each. You can later read it in 50 chunks of 2000 bytes each, or in 1 chunk of 100000 bytes. The only thing that a stream guarantees is that the total size of the stream is known and that every byte in the stream stays in the same order as it was sent/written.
That is very different for UDP. Here messages are sent in datagrams. UDP only guarantees that a datagram arrives consistently at the receiving end if it is smaller than the smallest MTU in the communication chain. That is why UDP typically is limited to 512 or so bytes, anything bigger has a chance to be cut up in smaller pieces on intermediate gateways and not arrive or not arrive completely.
If your stream is not a consecutive stream of bytes and you want to have some framing structure in it, you need to provide that mechanism in the data stream yourself. There is simply no reliable way to get TCP/IP to deliver you messages in exactly the same size as what you send them off. Even if the devices are connected directly together without any gateways, routers or more complex devices in between, there is no guarantee that blocks of data arrive in exactly the same sized chunks as they were sent off. A TCP/IP stack has the freedom to process things in different sized chunks if it finds that more useful for memory or performance reason. The only thing it needs to guarantee is that the bytes in the stream are handed to the application in exact the same order as they were sent, or to produce an error indicating that data could not be transported consistently. Theoretically some of the bytes in your data stream could be routed over the moon and take several seconds before they arrive at the other end, while other parts of your stream my be routed directly. It's all within the specifications of TCP/IP, although this extreme example is unlikely, but if you consider that telecommunication channels can go through satellites you still have potentially significant delays for data, and some of your data may go over satellite and other may go through a sea cable. TCP/IP was designed to be a highly reliable transmission channel rather than a super fast one and data streams can be routed over very different channels if the network decides that a particular channel momentarily is unreliable or cut off.
You could make this sort of work, if you are using rather slow communication speeds. As long as your timeout on the reading side is significantly smaller than the interval in which you send messages, you can sort of do what you want at least if your data doesn't go over routers or similar smart devices that can do all kind of repackaging. However you can't make the timeout to small or you risk only receiving parts of a message.
Much more robust is to actually integrate the size of your messages into your protocol. Then you only have to make sure to initially synchronize somehow, read the message header with the integrated size and then read the indicated amount of data. As long as both sides adhere to this protocol your data is both guaranteed to be in proper sequence (thanks to TCP/IP) and in proper message chunks (thanks to your protocol provision).
That's what I figured. I'll just have to make sure my TCP receive callback does a good job of parsing the messages. My changes did great last night until the issue below happened in the event viewer, but that's not an issue for this forum.
