Assume you have a client application which is known to connect to a given IP, and send a fixed size message (of size X = ~dozen bytes) upon connection, and wait for a reply.

If you're writing a server, can you guarantee that the first (non-EAGAIN) call to read() (assuming no errors) on the (non-blocking) socket after the accept() will return X?

My understanding is that TCP/IP is a streaming protocol, so that isn't guaranteed, but it might be true in practice, since such a small packet isn't likely (possible?) to be split during transmission.

  • 2
    I consider this the same level of badness as using sleep for thread synchronization. It might work in practice, but it's still very wrong and might bite you once circumstances change. Aug 25, 2016 at 21:51
  • That's basically what I was thinking.
    – Bwmat
    Aug 25, 2016 at 21:53
  • There is no reason to expect the size/shape packet you sent to arrive in the same form. Treat it like it is a bursty serial port, purely a serial stream, anything else will lead to failure.
    – old_timer
    Aug 26, 2016 at 1:39

2 Answers 2


In practice it depends in part on the client application. If the client socket had local buffering disabled, and wrote the bytes to the socket one byte at a time then it is entirely possible that the 12 bytes are transferred in multiple wire level packets.

And in part on the way the server application is written. If the server socket read call is blocking and requesting 12 bytes then it will wait for 12 bytes regardless of how they arrive (or until a timeout or an error occurs). However, severs should really be using non blocking sockets for performance reasons.

  • I'm interested specifically when the client issues 1 blocking write call with the data, and the server is using select + non-blocking read. My worry was actually about the packet being split while being routed.
    – Bwmat
    Aug 25, 2016 at 22:35
  • Worrying about the wrong thing.... If a router receives a packet with the frag flag set, it waits for the rest of the original packet and reassembles it before forwarding. Aug 25, 2016 at 22:38

TCP is a stream-oriented protocol. It is entirely legal for either operating system, a router, or any other device involved in the connection to break up writes of any size into multiple packets, or to recombine them. A well written program must handle short reads.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.