On Mon, Oct 7, 2013 at 5:39 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> 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 ;) > The SO_RCVBUF and SO_SNDBUF are system dependent socket options and typically are in range of 8Kb up to 60Kb. Those are socket level options though. BTW I was able to reproduce the "hanging" problem described above. I haven't looked deeper for now but it seems that both sockets are closed cleanly after the "suspended" browser is resumed. Hence normal TCP close sequence is initiated and normal two way FIN, ACK sequences are communicated between the sockets. > > > 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 > >
