reject_delay

[Ben Wiechman]

> 
>   Hmm... OK.  The simplest thing to do would be to simply discard the
> packet *without* logging it if it was marked as a delayed reject.
> 
>   If the reject is delayed for only a second, most clients *shouldn't*
> retransmit quickly.  If they do, they're seriously broken.  They need
> to
> implement the RFC5080 client retransmission algorithm.

That would be best, I agree.

> 
>   But the "discarding duplicate" request message is printed *only* when
> the server is still processing the request, and hasn't decided to
> reject
> it yet.  When "reject_delay" is being applied, there is *no* log
> message

Hmmm... 

> by default.  See src/main/event.c, look for "discarding duplicate
> request".
> 
>   It seems that the issue is one of the following:
> 
> - the server is slow
>   - i.e. slow DB
>   - or slow proxying
> - the client is too fast
>   - retransmitting multiple times a second

I haven't entirely ruled out database issues. However the authentication
database is hosted locally and small enough so that it should remain
entirely in memory unless the record is on a dirty page or something. No
proxying. 

Reject_delay was configured at 1s, and I typically only saw this for auth
requests for non-existent clients on public wifi APs. Since configuring
reject_delay to 0 I have not seen a log entry, but that could be
happenstance as well. Given your statement about no logging I'm going to
dive back to the database. Not a major issue, more an annoyance and a check
for me to see if I need take a deeper look at the database.

Thanks.