Multithreading the KDC server - a design
srahul at novell.com
Tue Apr 12 04:09:45 EDT 2005
> I probably would have chosen approach 4.1 (not surprising since I
> suggested it). We just haven't run into cases where KDC performance
> requires multiple CPUs at all.
There are many eDirectory deployments with more than 1 million objects in
the directory. If such a deployment is kerberized and each object is
associated with a kerberos principal, then the rate at which the KDC would
have to handle requests could become very high. BTW, in your experience,
what is the maximum rate at which the KDC has to handle requests in
current deployments ?
> Given that you did not choose 4.1, I think the HP comments about fine
> grain locking are important. I don't undersatnd why under your
> proposal the fine grain locking would be significantly harder than a
> single lock.
> I also agree with those who have said that recursive mutexes should be
In the initial design, my objective was to add locks to the existing KDC
code to make it multithreaded without any major rewriting of the KDC code.
That would have required locking across function calls and that is why I
proposed the use of a single recursive lock. But, after the last week's
discussions on the list, with almost everyone being horrified at the idea
of using recursive locks :) , it seems that rewriting portions of the KDC
code would be better. That would also make fine grained locking easy.
> I don't understand why TCP and UDP are handled separately. It seems
> like you would want to read the entire request in the main thread
> (using non-blocking reads for TCP) and then dispatch it.
As I said in my reply to Ken's mail, the reason for receiving TCP packets
in the service threads, but UDP packets in the main thread is that the TCP
buffer size is 1MB while the UDP buffer size is 4KB. I was afraid that the
main thread might be delayed if it had to handle huge TCP segments (Could
this be a DOS attack ?). Ken also felt that for now we should have the
main thread receive both UDP and TCP requests. If that is the general
opinion, I will change the design to have the main thread receive all the
More information about the krbdev