> > > I have also understood that turning on no delay causes more > > > network traffic. That was partly the reason for leaving it off > > > by default. > > > > That's the idea behind the Nagle algorithm, but in practice it only > matters > > for things that resemble interactive typing. The idea is that you get a > > lot of 1-byte payloads with 41 bytes or so of packet overhead, so the > Nagle > > algorithm waits a bit (200 ms) to see if you're going to type more. In > > the case of a SOAP request, all the payload is ready to go at once, so > > there is nothing to wait for. Using the Nagle algorithm in this context > > always inserts the delay and never reduces any network traffic. > > I *hate* to be pedantic, but I just whipped out my Stevens "TCP/IP > Illustrated" to brush up on Nagle. The Nagle algorithm itself accumulates > segments into a single segment while it is waiting for an ACK. If ACKs come > fast enough, segments don't have to be accumulated. The 200 ms enters the > picture from the server side. The "delayed ACK algorithm" waits 200 ms to > send the ACK to a packet, so that if the server wants to send data, the ACK > can be part of the data packet. > > Having read this, it sounds like disabling Nagle should help large payloads > as well as small, but the experimental physicist in me still wants to make > some measurements.
Oops, I spoke too soon. The Nagle algorithm will only accumulate packets and wait for the ACK while it has a packet less than the segment size. For large payloads, it will keep accumulating segment size packets and sending them, so it should suffer the delayed ACK penalty only on the last packet. Also, I read more about delayed ACK. It is 200 ms at most, not a fixed 200 ms. The implementation is described as a timer that goes off every 200 ms. It is not a 200 ms timer started with the packet is received. Scott Nichol -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
