TCP Streaming/Segmentation issue

[ademclk]

TCP Streaming/Segmentation issue

[ademclk]

In TCP, data is sent as a continuous stream of bytes. As such, it does not inherently preserve message boundaries. If you send two messages "Hello" and "World", TCP could deliver them as one combined message "HelloWorld". This can cause issues when trying to interpret the received data, as seen in the issue with checking parity bits.

The solution to this problem is to implement a message framing protocol on top of TCP. In this case, we've used a length-prefix framing where each message is prefixed with its length. This means that before sending a message, we first send the length of the message, allowing the receiver to know exactly how many bytes to expect for each complete message.

The implementation involves modifying the send and receive functions. In the sendDelimitedMessage() function, we first send the length of the message (converted to network byte order), then the actual message. On the receiver side, in the receiveDelimitedMessage() function, we first read the length of the message, then read that many bytes for the actual message.