Multithreading the KDC server

[Ken Raeburn]

On Mar 21, 2005, at 05:01, Rahul Srinivas wrote:
>    eDirectory lookups are more time consuming than local database 
> lookups.
> Because of this and the fact that the KDC server is single threaded, 
> the
> KDC server's performance deteriorates under high load. To overcome this
> problem, I am working on making the KDC server multi-threaded. In 
> krb5-1.4,
> though a large portion of the Kerberos libraries have been made
> thread-safe, the KDC server remains single threaded. Have there been 
> any
> attempts to make the KDC server multithreaded ? If so, are there any
> documents available which outline the approach ?

No documents or attempts that I am aware of.  However, it's been the 
topic of one or two conversations around MIT.  One idea that was kicked 
around was trying to make the high-level code in the KDC multithreaded, 
with locking around the bits that haven't been converted, including the 
current database code for now.  Perhaps single-threading around the 
socket code, too, and multiple worker threads for processing the 
individual messages.  But that doesn't deal nicely with retransmits 
caused by the KDC taking too long; it'll probably try to process each 
copy of the message.  (Currently, where all request processing is 
serialized, any such replays would be caught by the replay/lookaside 
caches.  But in the multithreaded case, a replay could conceivably come 
in and start going through processing while the original message is 
still being processed.)  Multiple eDirectory lookups of the same data 
might not be combined, though if there's caching in that code that may 
be okay.

There's a bunch of global state dealing with things like which of the 
(potentially multiple) realms the KDC supports is actually being 
queried currently; that internal "interface" should probably change to 
variables that get passed around.

Just some thoughts...I haven't tried actually making this work....

Ken