Acct-Delay-Time attribute in buffered-sql server mode

[Alan DeKok]

Rygl Aleš wrote:
> Using (and updating) Acct-Delay-Time is correct when the request proxied
> and internal processing on the Radius server takes some time or there is
> a retry. If I use this file buffer for doing proxy then it makes sense
> of course. But I do not see the point updating it when the file is just
> being loaded to DB.

  Arran and I both explained why it's useful.  Perhaps you could read
those explanations.

> IMHO it matters to store the DB record with correct timestamps (I can
> use there either Event-Timestamp or %S)

  No. Event-Timestamp is time when the event happened.

  %S is the time when the packet is being processed.  It might be a long
time after the event.

  Acct-Delay-Time is the delay between Event-Timestamp and %s.

  In mathematical terms:  Event-Timestamp = %S - Acct-Delay-Time.

> In this case the %S is "Sun Oct 5 12:11:21 2014", The delay indicates
> that it is not on time. When I store it using %S for session start I
> have to use a correction

  The correction is to use Acct-Delay-Time.

> The problem is that if there is a huge detail.work file loading it may
> take some time. Buffered-sql server then updates (or creates if it is
> not already present in the detail.work file) the Acct-Delay-Time on the
> time the request was waiting in the detail.work file. If the server
> manages to load the detail.work file every 20s the Acct-Delay-Time delay
> stored in DB is then not 10 but 20 or 30s (I am not sure here, it seems
> to me that previous value is replaced).

  Yes.  That's exactly how it's supposed to work.

  You shouldn't be storing Acct-Delay-Time in the database.  It's not
needed.


> Now I see I could use Event-Timestamp and %S and reconstruct the delay
> from them...

  That delay is Acct-Delay-time.

  Alan DeKok.