A lot of beginning (and not-so-beginning!) TCP/IP developers see send() and recv(), and assume they will have a 1 to 1 correspondence.

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.
Actually, I believe TCP need not limit itself to these four causes, rearranging your data boundaries as it sees fit for performance or reliability.

You can reduce the risk by using:

But the risk remains, diminished but not gone.

To truly fix the problem:

Supporting articles:




Hits: 1260
Timestamp: 2024-02-29 10:37:47 PST

Back to Dan's tech tidbits

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