TCP Streaming/Segmentation issue

[ademclk]

There’s a problem that when you send multiple messages to the client, they receive it as a single message.

This is a common issue with TCP, which is a stream-based protocol and does not guarantee that messages will arrive as sent. Instead, TCP guarantees that all bytes will arrive in the order they were sent.

This means that if we send two messages, "Hello" and "World", it's possible that the client will receive them as a single message, "HelloWorld". It causes an error while checking parity bits.

To handle this, implement a message framing protocol on top of TCP. One common method is to prefix each message with its length.

[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.