Hi, i'm having some questions about the TCP ZeroWindow flag. According to my capture we have the following scene:
The host 192.168.45.182 is the client and the host 192.168.45.178 is the server. One of my doubts is if the WIN in line 98412 is from client or from server. The tcpguide web (http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm) site tells that the send window to the client is the received window to the server. See the following text:
And this picture even better explains the situation: But I'm still having doubts about the output of wireshark. Some one can explain me better? Thank you very much. asked 08 Nov '10, 04:01  Plinio Monteiro |
2 Answers:
OK, walk with me...
... the client sends 282 bytes to the server and also tells the server that it's receive buffer only has 118 bytes left...
... the server sends 118 bytes (filling up the receive buffer of the client) and tells the client that it can still send 64112 bytes before it's receive buffer is full...
... the client sends 165 bytes to the server and also tells the server that it's receive buffer is now completely full so the server should stop sending data (until the application on the client fetches the data from the TCP receive buffer)...
... this looks like a natted version of the last packet???...
... the server acknowledges the data that the client has sent, tells the client that the application has read some data from the TCP receive window so that there is now again room for 65535 more bytes. It also does not send data, as it has not received word from the client that some buffer space has been freed... Does it make more sense like this? answered 08 Nov '10, 05:27  SYN-bit ♦♦ showing 5 of 6 show 1 more comments |
SYNbit and hansangb, Just one more question. If the client's window size reaches zero, and there ins't a negotiation of the window, can be a problem in the SERVER application or de CLIENT application? Can be a problem of the machine too? Thank you again. answered 09 Nov '10, 03:07 Plinio Monteiro If the client advertizes a window that reaches zero, then the Application on the client does not read quickly enough from the TCP receive buffers. So it's a client application problem. (09 Nov '10, 03:13) SYN-bit ♦♦ thank you very much again. (09 Nov '10, 03:20) Plinio Monteiro ZeroWindows can be hard to diagnose. if the client is Windoze box then you should look at I/O contention of the harddrive and page file utilization - for some silly reason Windoze tends to swap out "sleeping" connections. When new data is sent to one of these sessions it has to be put back into active memory before the buffers are emptied. If the client workstation is already underload AND the harddrive is active then this process can take a while - which leads to full buffers and zero windows. Also, if the server is dumping a LOT of data at once the client can get temporarily choked. (09 Nov '10, 08:22) GeonJay |
Hi SYNbit,
Thank's for the return. Yes, it's clear, but i have some questions:
1- When the server restart the application, the "problem tcp zerowindows" is solved;
2- This client connect with others server's and we don't receive any TCP ZeroWindow;
3- According to the picture, the window of the client is overlap by the window of the server. On steps 1, 2 and 3, the client send a 140b data and has a window of 360, leaving only 220bytes, but in the next send, the window is 260 and not 220, so the client took the window size from the server. It's that or am I wrong? Thank you very much again.
1) It is the responsibility of the application to fetch data from the TCP receive buffers. Since the buffer decreases to 0 and (assuming from your information) does not get back to a normal value, it is the application that is at fault here. It does not fetch data from the TCP receive buffer. So it's logical that the "zero window" condition vanishes as the application is restarted. However, the exact cause of the lockup does not go away that way.
2) As it's an application problem, communication to other servers will not be affected. Unless the same application runs on other systems without problems. Then you need to look for the specifics on the faulty server. If not, then you need to troubleshoot the application.
3) I don't think the picture is any good, for one thing, the ACK's of the server don't seem to free buffer space on the client, which of course it should be doing.
Plinio, it's important to separate the send versus receive window sizes. Remember, you cannot see the send window size in the packet traces. Only the RECEIVE window sizes are visible in the packet trace files. Things to keep in mind are: 1) Typically SEND and RECEIVE window sizes are set equally. So whatever your RCV window size is, that's the SEND window size as well. 2) The WIN field in the packet trace is ALWAYS the RECEIVE window size. It has nothing to do with what it can send.
3) TCP is a two way communication. So often it helps if you analyze the flow in one direction.
4) The RCV window size tells the SENDER what the RECEIVER can take. In other words, RCV window is the throttling mechanism used by the RECEIVER. 5) The SEND window is the throttling mechanism for the sender. If it runs out of the SEND window size, it has to stop (regardless of the receiver's RCV window size).
6) The SENDER has to stop if the RECEIVER advertises a zero window.
When the application removes the data from the TCP stack, the stack will advertise the new window size as appropriate. There are some rules about when it can advertise this, but don't worry about that for now.
Thank you very much guys for the help.