(RADIATOR) AuthBy DYNADDRESS / AddressAllocatorSQL

[Andy M]

Hi,

We are using a Radiator configuration with AuthBy DYNADDRESS and AddressAllocator SQL in order to allocate IP addresses from an Oracle 9i database.

We have a configuration where we don't use separate SelectQuery and UpdateQuery, but instead have a SelectQuery which calls an Oracle stored function that picks an IP address, marks it as unavailable (taking care of contention with other Radiator processes doing the same thing), records the username etc, and returns the IP address. We therefore have a blank UpdateQuery, as updates are done in the SelectQuery. See goodies/address-allocator-sp.sql and goodies/address-allocator-sp.cfg for an example of the sort of thing we are doing.

The problem is that when the SelectQuery (which is something like "select 1, get_ip(?, ?) from dual", with bind variables of the poolhint and the expiry time) cannot return a valid IP address, it needs to return something, e.g. a NULL response, or an error. This might happen, for instance, if the address pool is completely full, or it is invalid pool hint, or there is just so much contention that it has given up trying to find an IP address.

If it returns NULL, Radiator goes ahead and sends an Access-Accept to the client (and so not suitable).

If it returns an error, Radiator sees this as an error in DBI 'fetch' and disconnects from the database. This does result in an Access-Reject being sent to the client, but the database disconnections/reconnections kill the DB performance whenever the problem is due to e.g. a completely full address pool.

Some possibilities might be:

1. Recode AddressAllocatorSQL to use PL/SQL with in/out bind variables (similar to AuthByPLSQL - although this doesn't handle address allocation), and to handle scenarios where no address could be allocated
2. Recode AddressAllocatorSQL to recognise a response from the SelectQuery which isn't a valid IP (e.g. an IP address of '0.0.0.0' or 'NO_IP' could mean 'no IP address found') and return an Access-Reject to the client in this case.

What are your thoughts on this? I will have a go at #1 as support for PL/SQL for address allocation seems to be a better generic solution - so if I get something working I'll send in the code. But would be interested to get opinions from anyone else on this.

Regards,

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20041026/ff5ee7d3/attachment.html>