In fact, they usually will, but they are not guaranteed to. This makes the false assumption more prevalent.

TCP reserves the right to aggregate multiple smaller packets into fewer larger packets, or split large packets into a greater number of smaller packets. And this is reflected in the send()/recv() in C code, or Python code. This is because TCP is a byte-oriented protocol, not a message-oriented protocol.

The practical upshot is, if you write your code assuming a 1:1 relationship between send() and recv(), your application will most likely work most of the time, but suffer from seemingly strange failures now and then.

TCP splits or aggregates because of things like:

1. The Nagle algorithm
2. MTU mismatches resulting in packet fragmentation
3. Retransmissions
4. ISTR it can also sometimes happen because of the receipt of a POSIX signal; one end of the communication may EINTR as a result, midtransfer.

You can reduce the risk by using:

• a pair of computers with little else running on them
• a short network path (few router hops)
• network segments that are only lightly loaded (if at all)
• Path MTU Discovery
• few to no signals

To truly fix the problem:

• you should make sure your messages have a well-defined structure, with terminator characters (\n or \0, for example) or lengths (ASCII or network order int's, for example) or whatever. \n has the advantage of making it so you can do manual testing via telnet or netcat
• restart your system calls as needed:
  • C: put for loops around all your EINTR-capable system calls, plus check and act on return values. In some cases a length will be returned, and it won't necessarily be the length you originally requested
  • Python: use something like bufsock

Supporting articles:

• Stackoverflow: Handling partial return from recv() TCP in C
• Stackoverflow: Socket programming issue with recv() receiving partial messages
• Dr. Dobbs: TCP Programming Gotchas

You can e-mail the author with questions or comments: