Project review: Parallel KDC

[Nicolas Williams]

On Thu, Mar 11, 2010 at 05:14:11PM -0500, ghudson at MIT.EDU wrote:
> I've started a one-week review period for the Parallel KDC project:
> 
>   http://k5wiki.kerberos.org/wiki/Projects/Parallel_KDC
> 
> The brief summary of this project is to add a "-w NUM" option to
> krb5kdc, which will cause it to spawn NUM worker processes all
> listening on the same ports.

I'd have preferred a combination of refactoring for async I/O +
multi-threading, not because it's a better solution (multiple processes
are safer than multiple threads) but because the core of the KDC should
be a library since there are protocols where having such a library would
be very handy (e.g., PKU2U).

Note too that the KDB DAL needn't be restructured: you can have a pool
of worker threads doing blocking KDB DAL calls and then issuing the
event that gets the main event loop to restart requests that had been
waiting on DAL responses.  You'd only have to make the KDC core routines
async, reentrant, thread-safe.  But I digress.

I'm happy with the proposal, though I have a few comments:

 - I don't see the need for two options.  One option will do.
 
 - A good default process count might be 2 * NCPUs.  If you're using the
   LDAP backend maybe higher (since it's blocking).  I'd say a default
   of 4 * NCPUs is safe.  Admins should have to specify 1 as the number
   of processes to avoid this feature.

 - The reply cache is less important if you can handle many concurrent
   requests.  A per-KDC reply cache would be fine.  Alternatively using
   a replay cache where each request/reply pair is stored in an
   individual file named after a hash of the request, with each file
   created with O_EXCL.  This would move all locking to the filesystem
   (which should be tmpfs).

Nico
--