HUP handling: a thought

[Alan DeKok]

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