>
> Another part of the fix is to have
>
> listen(sock, 0)
>
> work like normal, but
>
> listen(sock, >0)
>
> should be changed (in the kernel) to be something like
>
> listen(sock, sizeof(input queue length))
I started a implementation of this (you'll see that newer 2.1 kernels
contain some code #ifdefed to NEW_LISTEN in net/ipv4/tcp_ipv4.c).
That implements exactly what you describe. It's not extensively tested
though. To manage larger queues efficiently requires so more work though
- currently the TCP connection requests are kept in a single linked list.
I have some experimental patches to solve this problem (and a few
others - including zero overhead timers for TIME_WAIT sockets), but
they are not ready for release yet.
Note that there are really two input queues involved here. The
packet input queue (which is only limited by free memory and later
by the socket rcvbuf settings) and the TCP connection request queue
(basically TCP SYN_RECV sockets). Incoming data packets could block
out incoming SYNs of course, when Linux runs out of memory, but
there is nothing that could be really done against it. In the
TCP open request queue only incoming SYNs are handled, never
other data packets. Because of this separation really big listen
backlog queues are only needed to defend against TCP SYN flood attacks
(together with random drop or tail drop on the syn queue). Linux
offers a nice alternative to these big queues though - syncookies.
-Andi