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 > programmers. 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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html