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.