Socket performance

[Roy Smith]

In article <4c4bd0b1$0$1624$742ec2ed at news.sonic.net>,
 John Nagle <nagle at animats.com> wrote:

>     1.  When writing to a TCP socket, write everything you have to write
>         with one "send" or "write" operation if at all possible.
>         Don't write a little at a time.  That results in sending small
>         packets, because sockets are "flushed" after each write.

There's nothing that guarantees that a single write won't be split into 
multiple packets, nor that multiple writes won't be coalesced into a 
single packet.  Or any combination of splitting and coalescing that the 
kernel feels like.

That being said, for any sane implementation, what John says is true 
most of the time, and is indeed a reasonable optimization.  Just don't 
depend on it being true all the time.  The most common case where it 
will not be true is if you're trying to send a large amount of data and 
exceed the MTU of the network.  Then you are certain to get 
fragmentation.

Depending on what you're doing, this can be a point of networking 
trivia, or it can be the difference between your application working and 
not working.  If you're just streaming data from one place to another, 
you don't have to worry about it.  But, if you're doing some sort of 
interactive protocol where you send a command, wait for a respond, send 
another command, etc, you really do need to be aware of how this works.

Let's say you're writing something like a HTTP client.  You send a bunch 
of headers, then expect to get back something like "200 OK\r\n", or "404 
Not Found\r\n".  You can't just do a read() on the socket and then 
examine the string to see if the first three characters are "200" or 
"404", because (regardless of how the server sent them), it is legal for 
your read() to return just a single character (i.e. "2"), and then for 
the next read() to get "00 OK\r\n".  You need to do buffering inside 
your application which keeps doing read() until you find the "\r\n" (and 
stops there, even if the read() returned more data beyond that).