Hi Christopher, thank you for your reply.
> -----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. 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. 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. Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
