Who sets the TCP window size to 0, Indy or Windows?

Question

We have an application server that observed sending headers with a TCP window size of 0 when the network was congested (on the client site).

We would like to know if it is Indy or the basic level of Windows, which is responsible for setting the TCP window size from the nominal 64K when adapting to the available bandwidth.
And we can act on it, becoming 0 (nothing sends, users wait => there is no benefit).

So, any information, link, pointer to Indy code is welcome ...

Disclaimer: I am not a network specialist. Please keep the answer clear to the average me ;-)
Note: this is Indy9 / D2007 on Windows Server 2003 Service Pack 2 (SP2).

More about the mountains:
TCP zero window cases occur at the middle level, talking to the database server.
This happens at the same time that end-users complain of a slowdown in the client application (which triggered a network investigation).
2 main network problems causing bottlenecks. A TCP null window occurred when a network congestion occurred, but may or may not be caused by this.
We want to know when this will happen, and we have a way to do something (by entering at least a minimum) in our code.

So, the main question: who sets the window size to 0 and where?
Where to get the hook (in Indy?) To find out when this condition occurs?

Answer 1

The size of the window in the TCP header is set using the TCP stack software to display the size of the available buffer space. If your server sends packets with a window set to zero, probably because the client sends data faster than the application running on the server reads it, and the buffers associated with the TCP connection are now full.

This is absolutely normal for the TCP protocol if the client sends data faster than the server can read it. The client should refrain from sending data until the server sends a non-zero window size (it makes no sense, since it will be discarded anyway).

This may or may not reflect a serious problem between the client and the server, but if this condition persists, it probably means that the application running on the server has stopped reading the received data (after it starts reading, it frees up buffer space for TCP and the TCP stack will send a new nonzero window size).

Answer 2

A TCP header with a window size of 0 indicates that the receiver buffers are full. This is a normal condition for a faster writer than a reader.

When reading your description it is not clear whether this is unexpected. What made you open the protocol analyzer?

Answer 3

Since you may also be interested in solving your problem:

If you have control over what is being done on the server side (the one that sends window size 0 messages): Do you consider using setsockopt () with SO_RCVBUF to significantly increase the size of your socket's receive buffer?

In Indy, setsockopt () is a TIdSocketHandle method. You must apply it to all TIdSocketHandle objects associated with your socket. And in Indy 9 they are located through the Bindings property in your TIdTCPServer.

I suggest first using getsockopt () with SO_RCVBUF to find out what the OS gives you as the default buffer size. Then significantly increase this, maybe by sequential testing, doubling the size each time. You can also rerun the getsockopt () call after your setsockopt () to make sure your setsockopt has actually been executed: usually there is an upper limit that the socket implementation sets to the buffer size. And in this case, there is usually an OS-dependent way to move this ceiling value up. But these are quite extreme cases, and you hardly need it.

If you do not have control over the source code on the side that is crowded, just check if the running software shows any parameter to change this buffer size.

Good luck