Re: TCP connections clogging up accf_http(9)

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

> > It does, but Robert is right in that eventually, when the queue is
> > full, it remains full (drop one from q0, add one to q0, ad inf.), so
> > the accept filter is for all practical purposes defeated.
> I disagree.
> If q0 is full, then every new connection will be inserted at the "new" end 
> and push out another one at the "old" end. If there's more pressure on q0, 
> more of the old entries will be pushed out. Provided you have substantially 
> more real connections (i.e. those that will send a full request in a short 
> time) than dead ones (i.e. those that will linger in the Accept Filter 
> indefinetely), in the long run, you will get exactly what you need: just 
> enough free entries on q0 to have new connections stay in the Accept Filter 
> as short as they need to.
Edgar and I have discussed this in person and I agree now, other than
cluttering up what netstat reports, the "dead" connections should cause
no harm with tls@'s approach (and my modification to it). 

We also believe it is not too late to document that accept filters
might, under special (i.e. these) circumstances, pass through sockets
that would under normal conditions be retained.  Accept filters are
young enough a concept so it seems unlikely that there's any major
software that inherently depends on accept filters (as opposed to using
them opportunistically and hence being prepared to handle "dead"
connections anyway.)  Or is there?

That said, what FreeBSD does is, in fact, calling soabort() on
connections that are pushed out of their accept filter.  While this
does preserve the filter's semantics for accept(2) to only ever
return sockets that can be read(2), it keeps the service from ever
noticing anything about the situation, which might be desirable for,
say, telling blacklistd about it.