Mailing List Archive: listen() bug

listen() bug

Oct 9, 1995, 9:38 AM

Post #1 of 3 (288 views)

I could have sworn that there was a patch which changed "listen(sd,512)" to
"listen(sd,5)" in http_main.c. But I just came across it in 0.8.14. Anyway,
whether there was a patch or not, it got me thinking.

The second parameter to listen() is the "backlog". i.e. how many pending
connections are allowed on this port before "connection refused" is returned
to the client. Now, the question is, is this the backlog for _all_ processes,
or is it a per process backlog? Or does it vary according to the system?

If it is per process, then a standalone server would work best with it set to
1 or 0 (depending on meaning). Is it worth making it settable? If we do, can
anyone measure the improvement?

BTW, the original reason for the patch, I thought, was that most systems
silently limit backlog to 5. Some system was not being so silent.

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Re: listen() bug [ In reply to ]

rst at ai

Oct 9, 1995, 10:28 AM

Post #2 of 3 (283 views)

Permalink

No, low backlogs are *not* a good idea. See the archived dicussion from
the last month or two on this mailing list on Linux (the system that was
silently limiting backlog to five), and on the severe problems that this
caused for people trying to run busy servers on Linux systems.

Sigh....

rst

Re: listen() bug [ In reply to ]

sanders at bsdi

Oct 9, 1995, 2:20 PM

Post #3 of 3 (279 views)

Permalink

Ben Laurie writes:
> I could have sworn that there was a patch which changed "listen(sd,512)" to
> "listen(sd,5)" in http_main.c. But I just came across it in 0.8.14. Anyway,
> whether there was a patch or not, it got me thinking.
>
> The second parameter to listen() is the "backlog". i.e. how many pending
> connections are allowed on this port before "connection refused" is returned
> to the client. Now, the question is, is this the backlog for _all_ processes,
> or is it a per process backlog? Or does it vary according to the system?
>
> If it is per process, then a standalone server would work best with it set to
> 1 or 0 (depending on meaning). Is it worth making it settable? If we do, can
> anyone measure the improvement?
The problem is that connections can get stuck for a period of time
in a state that ties up entries in this queue so you want to set
this as high as possible.

> BTW, the original reason for the patch, I thought, was that most systems
> silently limit backlog to 5. Some system was not being so silent.
You can change the default for the system that is being noisy but
something much larger should be the default for other systems that
are not being brain-dead.

> Cheers,
>
> Ben.
>
> --
> Ben Laurie Phone: +44 (181) 994 6435
> Freelance Consultant Fax: +44 (181) 994 6472
> and Technical Director Email: ben@algroup.co.uk
> A.L. Digital Ltd,
> London, England.