[RADIATOR] RADIUS/Radiator concurrency enforcement race condition?

[Joe Hughes]

2008/7/7 Dave Kitabjian <dave at netcarrier.com>:
> Hi folks,
> 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.

I had to work around a similar situation. We have DSL customers who do
he normal 'Access-Request, Access-Accept, Accounting-Start' scenario -
and we create the session on the Start. This caused us weird problems
because some DSL customers (unfiltered, poor lines) were sending login
attempts every couple of seconds. The NAS woudls sometimes only do
'Access-Request, Access-Accept, .... {No Start}..... Access-Request,
Access-Accept,' So it wouldn't send a START message if a DSL session
broke down during the login processs.

I worked around this by having two AuthBy SQL clauses, the second one
would fire only if the first was successful (ContinueWhileAccept). The
first clause would authenticate the Access-Request using our database
and enforce any session limits. Within the second clause, I can assume
the credentials were correct so I then create a session in our session
table.

I then have a datetime Accounting-Start column which is by default
NULL. In 99.9% of cases, when I send back the Accept, I will receive a
'Start' within seconds - in which case I set the Accounting-Start
column to said value. If I don't receive an Accounting-Start message
within a time-frame (30 seconds for instance) - I can assume the
Session didnt come up and I can clear it from our table (where
Accounting-Start is NULL). Obviously during this 30s period any
duplicate attempts are blocked, until my procedure clears the session
down.

I think this would solve your problem because as soon as the first
client successfully authenticates, a session is created (albeit
temporary) and is ratified when the START is received. If no START is
received, then the session is cleared down.

Rather than using the built-in session management, I actually wrote
our own session table\management using a combination of triggers on
the accounting table and sprocs just to give some added flexibility.