It it might decrease the load and memory usage on the server a little, which is nice for users that use it for something different than http.
I don't think it matter much, though.
And don't forget that in a traditional unix, it's possible to decrease the backlog below 7, but it's not possible to use a larger backlog; all values for backlog parameter that are larger than seven simply mean seven.
I don't know if that limit is changed in more modern incarnations, but I think the point of using a large value for the backlog parameter is simply to make sure that you use the largest backlog that is supported by the kernel. Which is often 7, or some similarly small number.
/ Niels Möller ()
Previous text:
2003-01-22 10:35: Subject: Re: Stdio.port listen() backlog again...
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe?
Shorter backlog would cause connections to be rejected on the OS level, so those will never reach the server (application) itself. Those rejected sockets (slots) would be freed quicker, since no connections will be established.
How would that improve anything? Other users would get connection refused instead of having to wait for a somewhat slower server. Some service is better than none.
/ Henrik Grubbström (Lysator)