Re: [9fans] Nagle algorithm

[forsyth@caldo.demon.co.uk]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

and that's what happened even with nagle enabled?

that's one reason i asked about the source of the ``vast majority''
of packets on the net.  if they are as you say, then i can't see nagle
being invoked by any of those applications.   they already do their
own buffering (i was looking at the code for them just now).
ftp for instance writes in blocks of 4k (it's fairly old code) and
others do better than that.  that's much larger than the
typical MSS (which is indeed rather smaller than 4k), so the
nagle delay will do sod all.   as the rfc defines it, it isn't invoked,
except for the FTP requests, which are small,
and then all it does is delay them pointlessly, since nothing
will be added to those!

there is buffering in the tcp/ip implementation,
so concurrency isn't affected by the mismatch
between MSS and write buffer size.   (ie, ftp can dump its 4k and read
the next block of the file whilst the previous ones are going out.)
same for http.  does apache dribble the bytes out in titchy quantities?

the second point is that the MSS provided by TCP/IP, if based only on
the host interface's MTU configuration, isn't sufficient anyway.  path
MTU discovery could be used i suppose except that it was added in retrospect,
relies too much on routers, gateways and firewalls all behaving well,
all the way there, and even then there are non-trivial problems
with it and tcp/ip.


[-- Attachment #2: Type: message/rfc822, Size: 1925 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
Date: Tue, 27 Nov 2001 10:16:18 GMT
Message-ID: <87g070wwg7.fsf@becket.becket.net>

cross@math.psu.edu (Dan Cross) writes:

> If you wanted to buffer 200 ``a's'' before sending them, why not do that
> explicitly?

Because the only way to know the correct number to buffer involves
knowing transport level information like the MSS and so forth.