== Why _listen(2)_'s backlog parameter has such an odd meaning

In light of [[what the _listen(2)_ backlog parameter actually means
ListenBacklogMeaning]], ie very little, you might sensibly wonder why
it has such an odd and basically useless definition. For instance, it
might be quite useful to be able to put a real limit on the number of
TCP connections that have been fully established but not _accept()_'d by
your server.

The simple answer is that the _listen(2)_ backlog is not about helping
your program out, it is about limiting how many kernel resources can be
(invisibly) consumed by connections that haven't yet been _accept()_'d
and surfaced in your program (and limited, if only by file descriptor
limits). Such connections are basically invisible to normal tools,
programs, and Unix limits because they haven't yet been materialized
as file descriptors and exist only in the depths of the kernel socket
stack. This means that the kernel needs to limit them somehow. In theory
the kernel could have applied the same limit to everything and not
provided any way for applications to change it. In practice, I suspect
that the early developers of BSD wanted to allow a way for some select
daemons they expected to be unusually active to raise the normal limit
(and perhaps for very inactive daemons to lower it to save kernel
memory).

This leads to a simple but not particularly useful rule for what the
_listen(2)_ backlog actually limits: anything that your kernel thinks
uses enough resources to care about. And this has changed over time.
As kernels have found clever ways to handle various things that have
traditionally consumed resources (such as half-open TCP connections),
they've stopped counting against the backlog limits. Some of this
evolution has been driven by necessity (such as people on the Internet
exploiting half-open TCP connections as one of the first denial of
service attacks) and some of it has simply been driven by the cleverness
of kernel programmers. This has led to the current situation where
understanding the effects of any specific backlog requires knowing
something about the kernel implementation of the specific socket type
involved and what things in it do and don't use up kernel resources.

(See also Derrick Petzold's [[somaxconn - That pesky limit
https://derrickpetzold.com/p/somaxconn/]], which has some interesting
quotes from Stevens' [[*Unix Network Programming* http://www.unpbook.com/]].)