The argument has mostly been about the effect of the backlog in a DoS attack, not against making it configurable.
I model the situation like this: A factor k of all incoming connections are DoS generators during an attack. The server handles the connections slower than they come in, and the backlog becomes full so connections get rejected with a factor l. Of those rejected connections would the same factor k as above be DoS generators. The longer backlog don't affect the speed in which the server is processing the incoming connections. So barring transient effects none of this is affected by the backlog length.
The only effect I can see is that the longer backlog in itself consumes more system resources. With a reasonable queue implementation, the only resource that can be significantly taxed would be the available port numbers for incoming connections. So it could affect connections to other applications on the server, as you've pointed out. But besides that the DoS would be just as bad anyway.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-22 16:12: Subject: Re: Stdio.port listen() backlog again...
On Wed, Jan 22, 2003 at 03:55:03PM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
The backlog size does not change the number of connections that can be opened. At all.
OK, not opened - waiting to be accepted. Currently there is no way to notify the client that service is unavailable due to high server load, with backlog we can do this.
Otherwise the server has to accept every connection and immediately close it (not every protocol supports "5xx Service not available").
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
Regards, /Al
/ Brevbäraren