Socket performance

[Navkirat Singh]

On 25-Jul-2010, at 5:52 PM, Roy Smith wrote:

> 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).
> -- 
> http://mail.python.org/mailman/listinfo/python-list

Thanks John, Roy. I really appreciate your valuable input. I have made a note of what you have said and will implement keeping the same in mind : )

Nav