[16338] in Kerberos_V5_Development
Re: KDC worker processes project
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Sep 17 14:34:13 2010
Mime-Version: 1.0 (Apple Message framework v1081)
From: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <29690.1284677453@malison.ait.iastate.edu>
Date: Fri, 17 Sep 2010 14:34:08 -0400
Message-Id: <D01C984F-E25B-4F09-9C6B-C57472341CF2@mit.edu>
To: "krbdev@mit.edu Dev List" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I find the disabling of automatic handling of network reconfiguration based on platform plus whether you're using worker processes rather unappealing, since conceptually they're not related.
It shouldn't be that tough to do. I think it's basically in two main pieces:
* Detect the network change in the parent; reconfigure, tell the existing children (via signal, or EOF on an internal pipe) to go away when they finish their current work, and spawn new children. My guess is this probably belongs in the common network-server driver code, though you might need callbacks to initialize after forking and clean up before exiting (i.e., make the network-server code closer to taking over all of main() with callouts to server-specific code).
* In reconfiguration, don't simply close all sockets and open them all over again with a new, possibly-overlapping set of addresses; if children linger a while, the parent may not be able to reopen some addresses. Instead, compare the addresses scanned against the already-open sockets; open new sockets only when addresses aren't found, and close sockets if they're no longer in the new address set. (Of course, if you make it support an empty starting socket list, you can still use this same code at KDC startup.)
The latter leads to cleaner behavior in the one-process case too, since even while dealing with a network configuration change, we wouldn't briefly reject connections/packets on interfaces/addresses that haven't been reconfigured.
Though, it *is* more work than just giving up on automatic reconfiguration support...
Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
