notifying another server on accounting
aland at deployingradius.com
Fri Mar 5 21:59:42 CET 2010
Michael Fowler wrote:
> Unfortunately, we seem to be hitting a wall in terms of packets
> transmitted to the vendor. It is my understanding that the detail
> reader is serial in nature, meaning it only sends one packet to the
> vendor (in this case), and will not send another until it gets a
> response. The vendor is over a slow link, or the packets are otherwise
> delayed, so we are getting a backlog of detail entries. The detail
> file is filling faster than it can be flushed to the vendor.
Yes, that is a bit of an issue.
> My question is, how can we fix this?
Hack the code. :(
> A few ideas have been batted around. One is to write some code (via
> rlm_perl or rlm_python) that essentially does what the entire
> writer/reader combination is doing, only in parallel. Meaning, it
> handles transmitting and retransmitting to the vendor. In the short
> term this might be viable, but it's reinventing wheels, and it's hard to
> justify long-term given most of the people dealing with this are not
Too much work.
> Another was to somehow load-balance the readers. I cannot find a
> configuration example to support this, but would it be possible, and
> more importantly useful, to have multiple readers pointing to the same
> detail file?
Fix the reader to handle more than one packet.
The issue right now is that it only tracks where it is in the "detail"
file in memory. It *could* have an auxiliary file giving:
- packet offset
- packet data (received response, last sent data, etc.)
This should be tracked automatically, and cleaned up when the detail
file is deleted.
There are a number of corner cases to deal with (files getting out of
sync, etc.), but it's possible.
More information about the Freeradius-Users