Socket data corrupted during TCP/IP transfer

Question

When i send data over a pre-connected TCP-IP socket, I see that the data is getting corrupted.

Example:

Station1 is sending data to Station2. I have printed the data, before sending (at S1) and after receiving (at S2). Below is the message:

S1: Data sent is ACK
S2: Data received is AC�����

Not sure what is the problem. I have even cleared the char-buffer before sending the data (at S1) and before receiving (at S2).

Any hint/info for the above would be of great help.

Answer 1

This is usually the result of something like:

/* BAD CODE */
const char* ack = "ACK";
err = write( sockfd, ack, strlen( ack )); /* sender */
/* ... */
char buf[SOME_SIZE]
readb = read( sockfd, buf, SOME_SIZE ); /* receiver */
printf( "%s", buf );

The problem with the code above is that sender writes only three (3) bytes to the socket. That does not include string zero-terminator. Then the receiver gets the data and either does not check system call return value at all or/and blindly prints the received data. The printf will print everything until it finds zero-valued byte in memory.

Edit:

Based on your comments I think you are assuming that one send(2) over TCP socket should result in one recv(2) on the other end with corresponding number of bytes (I'm guessing this is what you mean by "number of bytes read being wrong"). This is not the case with TCP though. You have to treat the socket as a stream that can give you arbitrary-sized chunks of what has been sent to you. It's your job to put them back together and recognize application message boundaries. This simply means you always read from a socket in a loop (not counting non-blocking designs with select(2) and friends - that's a separate topic).

Two accepted application-level protocol designs are:

• Communicate via pre-defined fixed-length messages - this way you read until you get that many bytes from the socket. Simple.
• Include message type and/or message length into the message itself - this is usually done with fixed-length message header that is followed by varying message payload. Read until you get full header then switch/dispatch/continue reading depending on type/length.

Don't forget about endianess - networks like network byte order.