So, Are you saying that if we do TCPNODELAY, just make sure we setup a BIG BufferedOutputStream and make sure we got our flush()es in the right places??? The question is: how BIG should the buffer be???
Regards, Hiram >From: "Jeff Tulley" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] jbossmq message transport times >Date: Wed, 16 Jan 2002 10:03:23 -0700 > >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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
