> On Sun, 14 Dec 1997, Marc Slemko wrote:
>
> > On Sat, 13 Dec 1997, Larry McVoy wrote:
> >
> > > listen(sock, >0)
> > >
> > > should be changed (in the kernel) to be something like
> > >
> > > listen(sock, sizeof(input queue length))
> >
> > I would think that is a bad idea. Some programs deliberately set a low
> > listen backlog and have valid reasons for it.
>
> I'm curious, why? Admittedly I'm a fan of long listen queues because I've
> seen enough performance problems solved just by increasing the listen
> queue length.
Say you have some application that can only handle a very limited (eg. 1
or 4) number of connections at once. You may not want a large backlog
building up, especially if accepting a connection means that the client
has to wait around a lot longer for the server to finally finish some
long-running (eg. in the order of hours or days) connection than if you
just didn't accept it and eventually it would look for some other server.
You can call this a dumb way to do things, and I can't really argue, but I
have seen it done sometimes for simplicity when something better isn't
needed.
Not ideal (for various reasons including BSD, and other's, silly
calculation of length, the fact that connections aren't refused but just
not acked, etc.) but in some situations it is useful. I don't see any
real reason to break the way it works just to deal with old software that
sets a low limit. The real problem that does need to be fixed is broken
OSes that set tiny (eg. 5) limits in the kernel; Linux doesn't have that
problem.
>
> > It is easy to fix any other programs that you have source for.
>
> And if you don't have source, my two favourite tricks are to hack a shared
> lib, or to just hack the kernel itself. I've done both now to work around
> commercial linux programs that don't do quite what I want them to.
Exactly.