Nicolas Baradakis wrote:
Indeed. At some point we need to make a tradeoff between a solution that is simple for the administrator but not very efficient, and a complex configuration mechanism that allow extensive control on a running server. (personally I tend to prefer the former solution)
Step 1: Make it work. Step 2: Make it work better/faster/smarter :)
But if all you're doing is adding one realm... why the heck do you want to reload the other 3000 realms to add just one? That doesn't make sense. It's an O(N^2) solution to a problem that should be O(1).
I agree. But large sites should have multiple servers, therefore perhaps they could address the issue differently.
They still have the problem of tracking state for ongoing sessions. Maybe what's needed instead is a state manager. i.e. a program with no knowledge of clients or home servers that manages requests and responses. It can be told about received packets, and can be queried for duplicates. Then, the main server can safely lose track of almost all state on restart, as it could still query the state manager. It could add significant delays to the packet processing, but it should work for everything other than ongoing EAP-TLS sessions. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog