[RADIATOR] RADIUS/Radiator concurrency enforcement race condition?

[Dave Kitabjian]

Hi folks,

I'm a little rusty here, so help me understand. But I seem to have
discovered a problem, and I'm not sure whether it's fundamental to the
RADIUS protocol or just Radiator's implementation. 

Here's an illustration:

1)	"mikem" is allowed only one session at a time, and is currently
offline.
2)	"mikem" is clever, and he sets up 20 access clients to all log
in at the same time.
3)	Radiator receives 20 Access-Requests for "mikem", and processes
them rapidly. Because he was offline, the SessionDatabase shows no hits
for "mikem", and all Access-Requests are approved. 
4)	One by one, mikem's access clients receive these Access-Accepts
and opens up a session. As each session goes online, an
Accounting-Request is sent to Radiator, and Radiator adds it to the
session database. 
5)	At the end, the session database shows all 20 sessions online,
and mikem has successfully evaded simultaneous-use limits.

In other words, the problem is caused by the fact that the step that
checks for concurrency is separated from the step that logs the session.
A DB Admin will describe this as a lack of "transaction processing". 

Now, normally, this might be a rare situation. But we are working on a
solution that will use Radiator to enforce concurrency with a "NAS" that
will be hit with an automatic (software) dialer which will rapid-fire
the requests as illustrated. 

Any thoughts or feedback is most welcome!

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20080707/7d5aba54/attachment.html>