On Thu, 9 Nov 2000, Scott Howard wrote:
> On Wed, Nov 08, 2000 at 11:14:42PM +1100, Anthony Rumble wrote:
> > Perhaps someone who knows exactly what "Nagle" is and does, could perhaps
> > explain a little more in depth what it is and what it does, and why to the
> > list, so that we could all know more about it.
>
> An example shows it better than a description...
>
> Without the Nagle Algorithm.
> Consider a telnet session. You hit one key about every 1/10th of a second.
> Telnet tries to send each character as you type it. TCP does the same.
> This means that every 1/10th of a second you're sending a TCP packet
> which contains around 40 bytes of header and 1 byte of data - or a
> total of 410 bytes/second to send 10 characters/second.
>
> With the Nagle Algorithm.
> You still type one key every 1/10th of a second, and telnet still tries to
> send each character as you type it.
> For the first packet, TCP will send it as per normal. The difference is
> that TCP will not send the next packet until the first has been acknowledge
> by the remote host. Over a fast link, the delay for the ack might be a
> few milliseconds, so the 2nd character (which get sent to TCP 100ms after
> the first is sent) will be sent instantly, and nagle has no effect.
> However, over a slower link the delay might be 450ms. This means that the
> 2nd through 6th characters will all be held at the TCP layer, and all
> transmitted in one packet. Ditto for the 7th to 11th characters, etc.
> The means that with a delay of 450ms, only 2-3 packets, or around 100
> bytes/second (including header) will be sent - saving around 3/4 of the
> traffic from the first example.
>
> The advantage of Nagle is that it's self-paceing. If you're on a fast (and
> thus most likely high-bandwidth) link you get instant transmission of
> data, without worring about the bandwidth used. If you're over a slow
> (and thus most likely low-bandwidth) link you get slower transmission, but
> at a huge bandwidth saving! The slower the link, the less traffic you send.
>
> Of course, like most things there's a few disadvantage - the one Howard
> mentioned is one of the more common. Function keys and the like (including
> arrows) are transmitted by sending an escape character, followed quickly by
> another character. Over a fast link this will normally work fine (normally
> - see below!) but over a slow link the second character will not be sent
> until the first is ACKed, resulting in a delay which is often too great for
> the remote system to detect it as a function combination.
This also explains why SSH doesn't exhibit the same issues as telnet, as
it pads the data with random rubbish to obscure the crypto.
--
Anthony Rumble - Managing Director
EverythingLinux.com.au - The Alternative Operating System Store
LinuxHelp.com.au - Support,Training,Development,Consulting
Phone: 0500 500 368 Direct 02-9712-1799 Fax 02-9712-3977
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
