Re: TCP connections clogging up accf_http(9)

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> the best thing to do when the server is (for whatever reason) refusing to 
> accept connections is to reject attempts to make them
Yes. The question is whether the kernel should drop them or pass them to the 
application which then drops them (after logging or taking counter-measures).

> the 192 connections clogging the queue, and new connections still arriving 
> - it would probably be better to clear the queue of all the backlogged crud 
> rather than removing one at a time
I also felt that it would be preferrable to clean the queue, but I couldn't 
make any rational argument to support that feeling.

> while also ignoring the incoming request that provoked it.
Why that?

> I suspect it might easily happen that by the time the client that is
> making the new connection tries again, some other connection will have
> occupied the (one) free queue slot, and is working its way to satisfying
> the filter - thus causing another old connection to be bumped to the
> server, and ignoring the incoming request, again .. perhaps over and over
> again.
But that would mean that going-to-be-dead connections arrive at a similar 
rate as ordinary ones. I would say that, if that is the case, the application 
is in serious trouble no matter what you do.
With the Timo variant of the tls approach, the new connections would have a 
chance to get passed to the application. They simply push out the older ones 
out of q0.

> But I believe that to handle this properly, the code needs to have some 
> concept of time, and use it.
Isn't relative time (i.e. queue position) enough?

Can you make up a scenario where the tls/Timo solution doesn't work well 
but there still is a way to deal with it better that doesn't require looking 
into the future?