First the suggestion... regarding AuthRADIUS.

Right now, when a request is proxied, as far as I can tell, the
identifier is chosen by simply adding 1 to the last identifier sent from
that AuthBy.

I suggest that the behaviour be changed a bit.  Make a table that keeps
track of what identifiers have been taken for each host in a given
AuthBy RADIUS.  Then when an identifier is allocated, you do a search
for a free identifier in the table.  If no identifier is found, send an
Access-Reject with a reason of "System Busy" or something, to prevent a
runaway condition that the current AuthRADIUS is very prone to.  If an
identifier is found, use that identifier, and start your search from
that number plus 1 next time.

Now there's one other cool yet simple thing you can do with this
method.  You can keep track of how many identifiers are allocated per
host in a given AuthBy RADIUS, and intelligently load balance by taking
the minimum of those.  This is the most efficient method possible for
RADIUS proxying that I can think of, and yet it is very simple.  Note
that Merit RADIUS behaves in a way very similar to what I have
described, and its proxy can handle much higher load than Radiator's.

Now here's the second idea that sort of springs from the first in a way.

I'm thinking about implementing a <LoadMonitor xxx> clause that knows
how to talk to a load balancing protocol, like you would find in a
load-balancing firewall.  This LoadMonitor clause would contain one or
many AuthBy keywords that specify what AuthBy methods we wish to
monitor.  The AuthBy modules would have an instance method called
getLoad or something that would return a percentage load for a given
AuthBy instance.  For example, in the AuthRADIUS method I described
above, it would return the percentage of (total free identifiers /
(number of servers * 256)) to determine its load.

That way, you can load balance several Radiator servers.

This idea has me fired up... wait till I tell our firewall admin. :-)

- D

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to