What is the connection backlog

 
When a connection request comes into a network stack, it first checks to see if any program is listening _disibledevent="http://tangentsoft.net/wskfaq/glossary.html#peer">remote peer, completing the connection. The stack stores the connection information in a queue called the connection backlog. (When there are connections in the backlog, the

accept()

call simply causes the stack to remove the oldest connection from the connection backlog and return a socket for it.)

The purpose of the

listen()

call is to set the size of the connection backlog for a particular socket. When the backlog fills up, the stack begins rejecting connection attempts.

Rejecting connections is a good thing if your program is written to accept new connections as fast as it reasonably can. If the backlog fills up despite your program's best efforts, it means your server has hit its load limit. If the stack were to accept more connections, your program wouldn't be able to handle them as well as it should, so the client will think your server is hanging. At least if the connection is rejected, the client will know the server is too busy and will try again later.

The proper value for

backlog

depends _disibledevent=NSimsun>accept() calls. Let's say you expect an average of 1000 connections per second, with a burst value of 3000 connections per second. [Ed. I picked these values because they're easy to manipulate, not because they're representative of the real world!] To handle the burst load with a short connection backlog, your server's time between

accept()

calls must be under 0.3 milliseconds. Let's say you've measured your time-to-accept under load, and it's 0.8 milliseconds: fast enough to handle the normal load, but too slow to handle your burst value. In this case, you could make

backlog

relatively large to let the stack queue up connections under burst conditions. Assuming that these bursts are short, your program will quickly catch up and clear out the connection backlog.

The traditional value for

listen()

's

backlog

parameter is 5. On some stacks, that is also the maximum value: this includes the worstation class Windows NT derivatives and on Windows 95 derivatives. On the server-class Windows NT derivatives, the maximum connection backlog size is 200, unless the dynamic backlog feature is enabled. (More info on dynamic backlogs below.) The stack will use its maximum backlog value if you pass in a larger value. There is no standard way to find out what backlog value the stack chose to use.

If your program is quick about calling

accept()

, low backlog limits are not normally a problem. However, it does mean that concerted attempts to make lots of connections in a short period of time can fill the backlog queue. This makes non-Server flavors of Windows a bad choice for a high-load server: either a legitimate load or a SYN flood attack can overload a server on such a platform. (See below for more on SYN attacks.)

There is a special constant you can use for the backlog size,

SOMAXCONN

. This tells the underlying service provider to set the backlog queue to the largest possible size. This is defined as 5 in winsock.h, and 0x7FFFFFFF in winsock2.h. The Winsock.h definition limits its value somewhat.

There are even better reasons not to use

SOMAXCONN

: that large backlogs make SYN flood attacks much more, shall we say, effective. When Winsock creates the backlog queue, it starts small and grows as required. Since the backlog queue is in non-pageable system memory, a SYN flood can cause the queue to eat a lot of this precious memory resource.

After the first SYN flood attacks in 1996, Microsoft added a feature to Windows NT called "dynamic backlog". (The feature is in service pack 3 and higher.) This feature is normally off for backwards compatibility, but when you turn it _disibledevent="http://support.microsoft.com/default.aspx?scid=kb;en-us;142641">article that describes the feature also has some good practical discussion about connection backlogs.

You will note that SYN attacks are dangerous for systems with both short and very long backlog queues. The point is that a middle ground is the best course if you expect your server to withstand SYN attacks. Either use Microsoft's dynamic backlog feature, or pick a value somewhere in the 20-200 range and tune it as required.

A program can rely too much _disibledevent="http://tangentsoft.net/wskfaq/examples/basics/basic-server.html">this example to see the technique at work.) You should not take advantage of the feature this way unless your connection rate is very low and the connection times are very short. (Pedagogues excepted.)