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. – CodesInChaos Aug 25 '16 at 21:51
  • That's basically what I was thinking. – Bwmat Aug 25 '16 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 '16 at 1:39

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 '16 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. – Michael Shaw Aug 25 '16 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, privacy policy and cookie policy

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