Tee accounting via detail

[Alan DeKok]

Pavel Levshin wrote:
> 1. Detail reader can process one request from the file at a time. So, if
> we have relatively slow (in terms of round-trip-time, like satellite)
> link, then we cannot process packets at any reasonable speed. If RTT is
> 0.5s, then we cannot relay more than 2 requests per second. It is
> horribly slow. Did I miss something?

  No.  Processing multiple packets in parallel is more complicated, and
requires changes to the code.  As always, we welcome patches.

> 2. Most of our accounting traffic should be delivered in realtime. Delay
> in transmission is much worse than some degree of loss. Now, one
> undelivered request may block complete detail file for some time.

  "one undelivered request" means "the home server isn't responding"

  i.e. the home server is *already* blocking accounting traffic.  Don't
blame the detail file when the home server goes down.

> 3. Even when detail reader has not been blocked, it may stuck for
> poll_interval seconds when processing of detail.work has been finished.
> Even when new detail file exists.

  Submit a patch to use a notification scheme such as "inotify".  Or,
submit a patch that ties the detail writer to the detail reader.  The
write can track readers, and wake them up when there's new data.

> 4. Some of the destinations may not reply at all (RADIUS sniffers behave
> so). We would be happy to send them a copy of each accounting request
> and forget it immediately. Is it possible?

  No.  You will need to modify the source code for this.

  Alan DeKok.