Re: TCP connections clogging up accf_http(9)

[Timo Buhrmester <timo%math.uni-bonn.de@localhost>]

> > I wonder if instead of dropping *one* socket in the case of an
> > overflow, q0 should be iterated and purged of *all* sockets that have
> > been on it for longer than $time.
> For what value of "purged"? Connect or drop?
I tend towards "drop"; that's mainly because I can't imagine(*) a situation
in which a client would legitimately connect and then uselessly linger
around for a substantial amount of time before sending their request.
Can anyone else, for any protocol in which the client is supposed to
be the first to send data?

(*) Actually, I can imagine two:
1. A human manually issuing a request using (line-buffered) telnet or
netcat.  This could be countered by making the decision to drop or to
accept depend on whether /any/ data has been seen on the socket so far
(like half a HTTP request).
2. The extra connections web browsers seem to open.  If however they
are not used to make actual requests for a while, one could arguably
consider them (practically) defective and it wouldn't hurt to RST them.
The browser is going to open new useless connections ones anyway.


I believe that a "maximum linger time" (in lack of a better term and
unrelated to SO_LINGER) as short as, say, 3 minutes would have a high
success rate at dropping de-facto dead connections while providing
adequate room for legitimate, but *really* slow, connections.

Now if the queue is full of only sockets that have been there for
*less* than those 3 minutes (like in a very busy server), I would
force one (or multiple) to be accepted rather than dropped, otherwise
it's pretty simple to DoS again.


> Or set a flag that will continue to connect two old sockets for
> every new one until the queue is one third/half empty again?
That sounds like a good idea too, I'd expect it to have good
"dynamics" regardless of whether one's dealing with a mostly idle
or mostly busy server.