Jeff here from the SDK team.
A customer was writing a high performance computing type application that needed to handle lots of incoming winsock connections all at the same time.
Normally the listen() API is used to control the maximum number of incoming (backlogged) requests, but there is a caveat with the listen() API, we don’t define the maximum limit of incoming requests that are allowed.
A value for the backlog of SOMAXCONN is a special constant that instructs the underlying service provider responsible for socket s to set the length of the queue of pending connections to a maximum reasonable value.
On Windows Sockets 2, this maximum value defaults to a large value (typically several hundred or more). 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.
Starting in Windows 8, there is a new parameter for the listen() API.
/* Maximum queue length specifiable by listen. */
#define SOMAXCONN 0x7fffffff
#define SOMAXCONN_HINT(b) (-(b))
While SOMAXCONN was defined as 0x7fffffff, it was limited to a few hundred in Winsock 2, or as few as 5 in Winsock 1.
In Windows 8, we can pass in any number we want with the macro SOMAXCONN_HINT(b). So now in Windows 8, you have much more control over how many connections listen() will accept/backlog.
Follow us on Twitter, www.twitter.com/WindowsSDK.