Tee accounting via detail
Hello. I have to copy our accounting flow to multiple destinations. It can be done with multiple detail files and multiple detail readers, each proxying to one destination. But there are problems: 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? 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. 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. 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? -- Pavel Levshin
On Thu, May 06, 2010 at 10:20:08AM +0400, Pavel Levshin wrote:
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?
If all you need is "fire and forget" then the easiest way is to write a custom freeradius module to duplicate accouting packets, update message authenticator and send them to your destinations. I guess you could also do it completely outside radius by sniffing accouting packets and replying them. See if you could adapt this script to do that: http://horde.net/~jwm/software/misc/comparison-tee -- Szymon Roczniak
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.
participants (3)
-
Alan DeKok -
Pavel Levshin -
szymon roczniak