Multithreading the KDC server - a design
wayne.morrison at hp.com
Mon Apr 4 15:26:09 EDT 2005
On Monday, April 04, 2005 3:00 PM Roland Dowdeswell [elric at imrryr.org] wrote:
> Given that the KDC itself does not really need to maintain state,
> wouldn't it be substantially easier to simply fork off $n$ children
> directly after binding to all of the listening sockets and process
> requests separately in each child? The approach works quite well
> for a number of other projects and:
> 1. eliminates porting difficulties with subtly
> incomatible threading implementations, and
Forking is *MUCH* more of a problem in our environment than threading. It most certainly does NOT make porting easier for us, and has to be redesigned/rewritten for our port. What you're proposing would, unfortunately, be a nightmare for us.
I realize that most of the actual implementations are on UNIX or UNIX-like platforms, but there are some (OpenVMS or Windows, for example) that do not have the same tools to work with. Consider this a request to use mechanisms that are standard across all the ported platforms as much as possible.
More information about the krbdev