[E-Lang] Hash Chaining & Capabilities, Proposal #1b: SimplifyingPluribus

[Mark S. Miller]

At 10:21 AM 10/17/00, Mark S. Miller wrote:
>Anyone have any better ideas?  Again, this is orthogonal to hash-based 
>proposals for simplifying Pluribus.  The only difference between the above 
>description and current Pluribus is that, in current Pluribus, VatB would 
>ask VatC to look up the pair <VatID(X), swissNumber(Carol)> rather than 
>swissNumber(Carol).  VatID(X) would be VatID(C) for the standard Granovetter 
>case, and VatID(A) if Carol is the result of a pipelined message from VatA 
>into VatC.

Call me stupid: The issues aren't orthogonal after all.

In the current protocol, where the lookup request looks up a pair of <VatID, 
swiss number>, and where the vatID identifies the vat that generated the 
swiss number, then that should be used instead of the Vine to determine what 
machine to round-trip to.  In the pipelined case, it amounts to the same 
thing -- VatC waits until a round trip to VatA completes before reporting 
lookup failure.  However, in the standard non-pipelined case, where the 
generating vat is VatC but the Vine still comes from VatA, VatC could 
immediately report lookup failure without initiating a round trip to VatA.

If I simplify the protocol the way I was proposing, then I lose this 
"optimization".  However, I think the proposed optimization is still the 
right thing, since, in the non-pipelined case when everyone is behaving 
properly, the lookup of Carol will immediately succeed.  There is only extra 
overhead to deal with a case in which someone was acting improperly, or 
where Carol's sturdiness has expired.

So, if no one has a counter-argument, I'm still planning to look up a 
swissNumber rather than a pair, and I'm still planning to use the Vine to 
determine what vat to round trip to, rather than provide other extra 
information for this purpose.