reject_delay

[Alan DeKok]

Ben Wiechman wrote:
> When an access-reject is being delayed due to the configuration of
> reject_delay, is the server core in any way aware of that?

  Yes.  The reject_delay is enforced by the server core.

> Problem: misbehaving clients that are not valid making many, many repeated
> network entry attempts in quick succession. Receiving a repeat request from
> the client appears to be causing a "discarding duplicate request" entry in
> the logs. Is there a (simple...) way to identify if a response is being
> delayed and update the discarding dups log entry accordingly? 

  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.

  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
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

  Alan DeKok.