> > So long as any one send is larger than MSS (or there is only one
> > send when < MSS :), the Nagle Algorithm will not be a problem on any
> > stack where Nagle is implemented correctly.
>
> Ok. I was not aware of the level of importance to do it like this.
> Thanks a lot for clarifying.

basicaly, a proper nagle implementation behaves like this on each send:

1) is this send, plus any queued, unsent data >= MSS if yes, send now
(assuming there is remote and congestion window). if no, go to question
2

2) is the connection otherwise idle? that is is there no unACKed data
from us on the network. if yes, send the data now. if no go to 3.

3) queue the data - we will either get an ACK from the remote for the
sent, unACKed data, a retransmission timeout, or the user will send us
more data and we will get to >= MSS, or the user will call close() or
shutdown(*WR*) and we will flush the queued data because we know there
is no more coming.

so, if the last send of a logically associated chunk of data is < MSS it
_may_ be delayed by Nagle, and that delay _may_ last as long as the
remote's standalone ACK timer.

rick

-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en