>Ubik is an elected-master protocol. All updates go to the master >which replicates. If the master goes away, after a while the >remaining nodes notice and revote a new master (this can take a while). > >I'm not sure that model works well with the KDC's single-threadedness. > >I expect a 3-phase commit model would be more robust.
I think you're conflating the master election protocol with the transaction protocol. You still need to decide on a master (aka "coordinator") with 2PC or 3PC. While Ubik does both the database election and transaction protocol, this isn't really required. And from looking at the description of 3PC, I think Ubik as implemented today would be considered 3PC, since transactions are aborted if a new master needs to be elected. Of course you wouldn't want to use Ubik as currently implemented today, unless you really like having a dependency on AFS LWP & Rx. I actually wrote a completely new implementation of Ubik at one point ... the recovery phase didn't quite work right, but I got busy with other things before I could finish it. As an aside ... I think the issue of the KDC being single/multithreaded is a red herring. I don't see a reason why the database update process has to be part of the KDC process. If you just restrict the multithreaded parts to a seperate database update daemon, it shouldn't be a problem. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
