Content deleted Content added
As stated in the reference: |
Citation bot (talk | contribs) Alter: template type, url. URLs might have been internationalized/anonymized. | You can use this bot yourself. Report bugs here. | Suggested by AManWithNoPlan | All pages linked from cached copy of User:AManWithNoPlan/sandbox3 | via #UCB_webform_linked |
||
Line 28:
This algorithm interacts badly with [[TCP delayed acknowledgment]]s (delayed ACK), 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. On Microsoft Windows the <code>TcpNoDelay</code> registry switch decides the default.
A solution recommended by Nagle is to avoid the algorithm sending premature packets by buffering up application writes and then flushing the buffer:<ref>{{
<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.
Line 51:
{{Reflist}}
*{{cite book|title=Computer Networks: A Systems Approach|authors=[[Larry L. Peterson]], Bruce S. Davie|publisher=Morgan Kaufmann|year=2007|isbn=978-0-12-374013-7|edition=4|page=402–403|url=https://books.google.com/books?id=fknMX18T40cC&
==External links==
| |||