It's about 200 ms on Windows 2000 Server, Linux, and Tru64 UNIX.
I believe TcpNoDelay should be true by default. While the Nagle algorithm was originally designed to reduce 1-byte payloads, this was in the era of single LANs, not of switched-networks and over-provisioning. We should be so lucky to cause congestion via SOAP -- the causes of congestion will likely be streaming media applications that use a TCP connection per client; if web services catch on this much (and it's Apache SOAP and not .NET), we'd all be very happy. > > 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]>
