[28466] in Kerberos
Re: MIT Incremental Propagation
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Fri Sep 21 20:49:31 2007
Message-Id: <200709220049.l8M0n6hR028443@ginger.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <31949.1190411200@malison.ait.iastate.edu>
Date: Fri, 21 Sep 2007 20:49:05 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
