Content deleted Content added
Artoria2e5 (talk | contribs) |
Artoria2e5 (talk | contribs) mNo edit summary |
||
Line 25:
'''end if'''
'''end if'''
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.
Line 42 ⟶ 41:
==Interactions with real-time systems==
Applications that expect real-time responses and low [[latency (engineering)|latency]] can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing [[Bandwidth (computing)|bandwidth]] efficiency at the expense of [[latency (engineering)|latency]]. For this reason applications with low-bandwidth time-sensitive transmissions typically use <code>TCP_NODELAY</code> to bypass the Nagle-delayed ACK delay.<ref>[https://bugs.freedesktop.org/show_bug.cgi?id=17868 Bug 17868 – Some Java applications are slow on remote X connections].</ref>
Another option is to use [[User Datagram Protocol|UDP]] instead.
| |||