(RADIATOR) Hacking around an upstream issue.

[Martin Edge]

Hey Guys,

Want to see if anyone has any ideas of how I should deal with this
situation.

We are currently getting the following for the 'occasional' user session
from our Upstream RADIUS..

Order	Amount	Type
-------------------------------------------------
1	1 		Start
2	Many 		Alive's (every 15 min)
3	1		Stop (0 sec, Acct-Delay-Time)
4	1		Alive (9 seconds afterwards, Acct-Delay-Time=10)

We are told that what is happening, is the first attempt is made to send the
first Alive packet. By coincendence, the user disconnects between these
retries, and the Stop packet is fired off. The Retry Alive packet is sent
after the Stop packet for that session has arrived.

Until they can come up with a network-fix for the problem (to prevent
Additional Packets for the Same Session to be sent before completely failing
the current packet (until $x times tried), I'm going to have to develop a
hack around to work out on what basis to ignore these extra Alives.

I was thinking I have two options

1:- Make Radiator see whether the SessionID is still active for an Alive
packet (could be costly on DB work each instance)
2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM
file, and check incoming Alive packet -isn't- in the recently expired list.

Which would be the best? Where should I start? :)

Thanks,
Martin

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.