Konstantin, On 10/7/13 10:24 AM, Konstantin Preißer wrote: >> -----Original Message----- >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Sent: Monday, October 7, 2013 3:29 PM >> To: Tomcat Developers List >> Subject: Re: 8.0.x / 7.0.x progress >> >> Konstantin, >> >> >> Note that it's not Tomcat sending the ACKs, but the TCP/IP stack in the >> OS running underneath the JVM. I wanted to point that out because it >> means that Tomcat may be entirely unaware that data exists for reading >> for some reason. If Tomcat itself were sending the ACKs, it would mean >> that Tomcat was at least conceptually aware of the data, but refusing to >> read it for some reason. > > Yes, that's correct. I guess there is some buffering in the various > layers (TCP/IP stack of OS, Sockets in the JVM etc) so that when sending > data, the client receive ACKS with a new window size even if the remote > java code might not be reading the data.
Exactly. > However, the buffering will not be endlessly so at some point TCP > will advertise a window of 0 if the java code does not read from the > Socket (at least this will be the case with blocking IO - though I do > not exactly know how the non-blocking IO is implemented so I may as > well be wrong here). This would mean that Firefox will have to wait > until there is more window available to continue sending data. I'm not sure how big the average TCP/IP receive buffer size is. I'd suspect a few MBs at least. It's bufferbloat at its finest ;) > In this case, I guess to verify that the remote TCP endpoint is > actually reading the data, one would have to send much bigger > messages to make sure the buffer of the remote endpoint runs out of > space if it is not reading from the connection. I can try that if I > have some time left. Just add a few zeros to your loop limit ;) -chris
signature.asc
Description: OpenPGP digital signature
