listen() maximum queue size per Windows version

The Winsock function listen(socket, backlog) has a parameter to specify the size of the queue for pending connections. The program should pass SOMAXCONN to set the queue to its maximum size.

Question: What is the maximum queue size for e开发者_如何学编程ach Windows version: 2000, XP, Vista, 7?

Thanks!

Reference: listen() on MSDN Library

It was 5 back on NTWS 4.0: http://support.microsoft.com/kb/127144

I believe in XP it was also this way, although from XP on it's hard to find anything concrete from Microsoft. (At least for me, that is how I ended up here hoping for an actual answer).

A quick seat-of-the-pants Java test showed that the default for Windows 7 Pro is 50, and the limit is 200. FWIW.

I'm not sure why someone would answer this with an assumption about why the question is asked. There are legitimate reasons for knowing the actual answer.

For example, you have software where you may receieve a burst of requests. If the max backlog by the operating system is 5, you may end up refusing connections even if handing them off as quickly as possible. And a backlog of 200 alleviates this. And because of this, you may want to make a OS system requirement to not use an OS that has such a backlog limitation.

The backlog parameter of the listen(socket, backlog) function is limited to SOMAXCONN. If set to SOMAXCONN, the underlying service provider responsible for the socket will set the backlog to a maximum reasonable value¹.

The maximum value on Windows platforms was²:

• Windows Sockets 1 defines SOMAXCONN = 5. Winsock 1.1 was part of Windows 95 and Windows NT 3.5.
• Windows Sockets 2 defines SOMAXCONN = 0x7fffffff and limits the listen backlog to a large value (typically several hundred or more). Winsock 2.1 was an add-on to Windows 95 and part of Windows 98, Windows NT 4.0 and all subsequent Windows releases.
• Windows 8 includes the "RIO" (Registered IO) extensions for Winsock. These extensions are designed to reduce the latency of network applications³. The macro SOMAXCONN_HINT(N) can be used to set the backlog to a larger value than possible with SOMAXCONN. The backlog value will be N, adjusted to be within the range (200, 65535)¹.

Note:

"When calling the listen() function in a Bluetooth application, it is strongly recommended that a much lower value be used for the backlog parameter (typically 2 to 4), since only a few client connections are accepted. This reduces the system resources that are allocated for use by the listening socket. This same recommendation applies to other network applications that expect only a few client connections."¹

Sources:

1. listen function, Winsock2.h documentation, Windows Dev Center
2. Winsock’s Listen() Backlog Offers More Flexibility In Windows 8+
3. Winsock, Wikipedia

I've seen it be 200 on Windows 7, but I don't know if it's tied to the OS or if networking drivers etc. might have an influence.

You can experimentally determine this by listening on a port and making a lot of connections to that port without accepting them until you're done (then see how many you got).

If you take Len's advise and use AcceptEx with IOCP, you can pretty much determine for yourself how large of a backlog you have by calling it in advance on a pool of waiting connections. I've seen this work with as many as 1,600 connections in the pool, but it does seem to have a limit as well.

For what it's worth, there is a default of 5 in the async sockets Listen() code for Visual Studio 9.0 (aka 2008). I found this in c:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include\afxsock.h: BOOL Listen(int nConnectionBacklog=5);

Also documented here: https://learn.microsoft.com/en-us/cpp/mfc/reference/casyncsocket-class?view=vs-2019#listen

What do you hope to achieve once you know the answer to this?

There are many ways to improve the performance of connection acceptance, you should focus on that and not what the actual number of queued connections can be.

The listen backlog should simply accommodate short term discrepancies between the rate at which the server software can accept new connections and the rate at which these new connections are arriving. You should strive to ensure that your server can accept new connections at a suitable rate, ideally by using AcceptEx() with IOCP for overlapped accept calls and posting a suitable number of overlapped accepts when your server starts and then topping these up as connections are established.

I talk about this kind of thing on my blog, here and here.