HUP handling: a thought

[Alan DeKok]

Claudiu Filip wrote:
> That is a good idea, but on most applications where a "state machine"
> was critical, users solved the problem by using a database.

  Which won't handle 100 DB lookups per packet.  That's why main memory
is used: fast access to necessary configuration information.

> FR has the possibility to change those 1000 users without restarting
> everything.

  Because it queries a database for those users.  Often only once per
request.  Maybe 2-3 times, but definitely not 10-20.  If all of the
configuration information was in a DB, it would do 100-200 DB lookups
per request.  Even if they were cached, that's still a huge load.

> We can easily grow from 1000 users to 1M users.
> Imho, the next step is to have the possibility to change radius
> clients on the fly. Not only VoIP carriers or access providers want to
> manage/grow to 10k radius clients.

  I know.  That's the goal.

> If IP addresses are not so easy to compare when (re)building large lists, why
> not having a numeric ID for each client to seek faster the tree and
> change the IP address, secret, name?..
> This numeric ID can also be used for snmp requests and it will be
> natural for users running a database backend with a "serial" field.

  2.0-pre already does that for SNMP requests.

  Maybe the solution is to separate the server into multiple processes.
 One can handle packets going in and out, but wouldn't connect to a DB.
 Another would connect to the DB, but would only have the first program
as a listed as a client.

  That separation would solve most of the reloading problems.  The only
difficulty left would be fast sharing of packets between the programs.
But I suspect that for almost any real-world traffic, the extra overhead
of moving 20 packets/s between two processes would be negligible.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog