Content deleted Content added
→Algorithm: Perhaps there would be less confusion if we didn’t mention tinygrams and silly windows at all? |
→Algorithm: Restore context of Nagle’s Slashdot quote. Wikipedia should say what the sources recommend, rather than recommending things itself. |
||
Line 23:
This algorithm interacts badly with [[TCP delayed acknowledgment]]s, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications that do two successive writes to a TCP connection, followed by a read that will not be fulfilled until after the data from the second write has reached the destination, experience a constant delay of up to 500 milliseconds, the "[[ACK (TCP)|ACK]] delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the <code>TCP_NODELAY</code> option.
A solution recommended by Nagle is to avoid the algorithm sending premature packets by buffering up application writes and then flushing the buffer:
<blockquote>"The user-level solution is to avoid write-write-read sequences on sockets. write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works."<ref>[http://developers.slashdot.org/comments.pl?sid=174457&threshold=1&commentsort=0&mode=thread&cid=14515105 Boosting Socket Performance on Linux - Slashdot]</ref></blockquote>▼
▲<blockquote>"The user-level solution is to avoid write-write-read sequences on sockets. write-read-write-read is fine. write-write-write is fine. But write-write-read is a killer. So, if you can, buffer up your little writes to TCP and send them all at once. Using the standard UNIX I/O package and flushing write before each read usually works."<ref>
==Negative effect on non-small writes==
| |||