Wireshark-dev: [Wireshark-dev] TCP ZeroWindow Probe Problem.
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Shankar Nair <snair@xxxxxxxxx>
Date: Tue, 19 Jan 2010 09:48:31 -0500
Hi,

Im currently working on a solution for streaming videos(over HTTP 1.1).
What im seeing(from the wireshark traces) is that when the client disables the read on its socket, the tcp_window size keeps reducing, which is right. At a point when it reaches, say 200 (something lesser than the MSS.), sometimes the server does not respond with a "WindowFull" segment( with that remaining 200 bytes of data offcourse). Thus, the client is not able to send a "ZeroWindow" as ACK. As a result the "ZeroWindowProbe" mechanism is not activated, as i understand that it should be according the following post (http://www.mail-archive.com/wireshark-dev@xxxxxxxxxxxxx/msg03799.html). When the client re-enables read on the socket, it sends out a "WindowUpdate". I see no activity between the time the client sent out the ACK with a window-length of 200 bytes and between the time the client sent out a WindowUpdate. It seems that during this period of inactivity the server cleaned up the connection and therefore on receipt of the TCP WindowUpdate it sent out an RST. According to me, the TCP ZeroWindowProbe mecahnism did not get activated due to the fact that the server did not send any data when the window length advertised by the client was less than the MSS. Had the server responded with a WindowFull, the client would have sent out a ZeroWindow and thereby activating a ZeroWindowProbe mechanism that would have probably kept the connection alive until the client was ready to read from its socket buffer.

Can anyone suggest a way that i could prevent (if possible) this connection termination ?

 Also, what are the plausible scenarios that force a server not to respond with that final "WindowFull" segment ?
 Is it possible that the server was experiencing load and therefore decided not to send out that last segment as it would then have begin the "ZeroWindowProbe" mechanism...?(which according to the RFCs MUST be done in response to a "ZeroWindow")
 http://www.freesoft.org/CIE/RFC/1122/103.htm
 Would initiating a TCP_KEEPALIVE probe (from the receiving-proxy end) help in solving this issue ?

 Thanks and regards,
 Shankar Nair.