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