Actually it is even a little more complicated than that. Nagle's
algorithm by itself would not cause such delays, but what happened is
that at the other end somebody (I forget who) came up with the idea of a
delayed ACK. Since an ACK is a small packet, and one ACK can
acknowledge receipt for multiple packets, the delayed ACK algorithm
tries to send an ACK only every other packet. This saves the wire from
having too many "tini-gram" ACK packets.
Combined with the Nagle algorithm, this causes death of communication
since neither side will budge Eventually the delayed ACK algorithm
times out (typically 200 ms, depending on the OS), and the ACK is sent.
So, you get down to about 5 packets per second throughput.
There are two other algorithms, which modify NaglReceived: from INET-PRV-MTA by
prv-mail20.provo.novell.com
wite's to get around this
problem. One, the "Doupnik" algorithm, uses information from the data
to determine if there is more coming, and it sends the last bit
immediately without waiting for the buffer to fill up. So, you get full
packets until the last one, which will be a "tiny gram", but you do not
get the 200 ms delay for every packet since the receiving end is
continually getting information. See
http://netlab1.usu.edu/pub/misc/draft-doupnik-tcpimpl-nagle-mode-00.txt
for information.
The other algorithm is called the Minshall Algorithm. I do not know a
lot about it, but it is along the same lines. See
http://lists.w3.org/Archives/Public/ietf-discuss/1998Dec/0025.html
for a discussion.
The problem with setting TCPNODELAY is that it disables Nagle's
altogether and you get the wire flooded with a lot of tiny packets.
But, in the web space it is exactly these tiny packets which trigger the
problem, and otherwise you lose throughput. The best solution, lacking
the ability to change your OS TCP stack, is to turn Nagle's off (with
the TCPNODELAY), and then use a bigger buffer for your data. Then you
are using the wire more efficiently in that you are not flooding it with
tiny-grams.
I wouldn't know all of this except the coworker in the office next to
me took a class from Doupnik himself, and has recently just finished
working with NetWare's TCP engineers to implement the Doupnik algorithm.
He found that most programs he dealt with in testing for the problem
turned off Nagle's algorithm for efficiency. Some OS's have this fix in
them, some do not. (Most do not???)
If we turn off Nagles algorithm in that code, we defintely need to look
at the buffer size if we want the most efficient data transfer.
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> "Sacha Labourey" <[EMAIL PROTECTED]> 1/16/02 2:58:30 AM
>>>
Hello,
I guess that if you want to modify this, you need to make it optional.
The TCPNODELAY flag is related to the Nagle's algorithm
This algorithm is made to avoid sending very small paquets each time
you
send data through your socket but instead wait 400ms (generally) or a
full
buffer (or a message from the other side if I remember well) and send
a
paquet that wrap more data. Thus, it tends to minimize the amount of
small
data that are sent.
I am not familiar with JBossMQ code base but if you think that the
implementation could, at some time, send many small messages and would
suffer from sending each time a paquet, then you should most probably
make
this setting optional. But, on the opposite, if you think that your
paquet
(*all* paquets, even ACK) always have a sufficient size and don't want
Nagle
to take care of you, then it is up to you.
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Hiram Chirino
> Envoy� : mercredi, 16 janvier 2002 04:17
> � : [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] jbossmq message transpo
rt times
>
>
>
> I can't think of a reason that it would break anything...
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
