Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a situation where an application is listening on a TCP port and every once in a while, as seen in tcp dumps, gets its Receiving Window (RWIN) set to zero. When this happens, its Recv-Q stops moving (because the sender stop sending) and the application thread listening on the connection/port just hangs. In WireShark, I see "ZeroWindow" states being produced, which happens when RWIN is set to 0 (a Window of size 0).

I'm trying to determine whether my application, which uses many open source libraries full of mysterious code, is manually setting it's connection's RWIN = 0, or if this is happening at the OS layer. If its the application, I have access to all the source code and with some hard work can properly debug it.

But if its the OS that says "hey, there is something wrong with this connection, setting RWIN to 0..." then I haven't a clue as to how to go about diagnosing. Any thoughts? Thanks in advance!

share|improve this question
Either. Here is an example of an application setting it on a per-socket basis:… – Greg Askew Apr 18 '13 at 13:54
up vote 1 down vote accepted

The receive window is calculated/set by the OS. Linux can change the memory available for receiving TCP packets with the net.core.rmem_max sysctl setting.

There are many pages for TCP performance tuning, for example this one:

Alas this will most likely not help you, as it just increases the amount of data that is buffered.

If the buffer is full the window size is set to 0. You have to look at your application for why it doesn't collect the data from the TCP buffer. Logfiles, start it in debug mode, etc. Not much you can do at the OS level for that.

share|improve this answer
Ahhh gotchya - so the Recv-Q buffer fills up (because the app isn't reading anything) and Linux automatically steps in and sets RWIN to 0 to prevent very bad things from happening, yes? As always, thanks @Sebastian! – Mara Apr 18 '13 at 13:10
Yes to the first part. To be correct, it's just signalling the sender that the receiving buffer is full and that it can't accept more data on the connection at the moment. So it's not really "preventing bad thing" more "preventing useless data transmission". – Sebastian Apr 18 '13 at 13:12

It really depends. You didn't specify what OS you're talking about but, under Windows (and I suppose, Linux as well), the TCP window size is typically handled by the TCP stack.

However, it is perfectly possible for some non-OS component to affect that as well. For instance: - An application can influence the behavior of the TCP stack by specifying a non-default buffer size for the socket (SO_RCVBUF). - An application could be using raw sockets and reimplement TCP in user mode (not sure why you'd want to do that, but it's possible).

Finally, you should know that getting a windows size of 0 is actually a normal condition: it indicates that one of the party already have a full data buffer and that it needs more time to process it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.