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

[Mark S. Miller]

At 11:30 AM 11/8/00, Tyler Close wrote:
>I thought this bound was already implicitly implemented. The sending
>Vat can batch together a bunch of calls that use a RemoteVow, but will
>not hear back from the receiving Vat until the receiving Vat has
>resolved the promise. So long as the sending Vat doesn't start up
>additional connections to the same receiving Vat, there is a
>non-finite, but practically very small, bound on the number of
>messages with the unresolved promise that the receiving Vat will
>receive.

Your "So long as the sending Vat doesn't start up additional connections to 
the same receiving Vat" is always true, as part of the contract of 
Data-Pluribus is that there is always at most one live connection between a 
pair of vats.

Beyond this, I think we may be misunderstanding each other.

Why would the sending vat need to hear back from the receiving vat before 
sending further messages on RemoteVow that go from the sending vat to the 
receiving vat?  In the pipelined Pluribus protocol without Jed's suggestion, 
it doesn't.


>I am not intimately familiar with the E implementation of a "vine", so
>do not assume that any of the nouns I use are class names.
>
>A particular remote method call might have a return value that is
>pass-by-copy. There is no way for the sending Vat to know if it will
>be or not when the invocation is sent. The sending code might depend
>on eventually getting a local reference to this pass-by-copy return
>value; therefore, the sending Vat must allocate a deferred promise for
>a local object, which it gives to the sending code. In the original
>description, I referred to this deferred promise as a "slot". This
>slot has two addresses. An identical slot will eventually exist in the
>receiving Vat. When the sending code gives the reference for this slot
>to other code, the other code must receive both addresses: the address
>for the slot in the sending Vat and the address for the slot in the
>receiving Vat. When the receiving Vat receives an invocation that uses
>this slot reference, it first checks for the local version of the
>slot. If it does not exist yet, it sends a "whenResolved" message on
>the second address. I think of this second address as the "vine".

Gotcha.

Your "slot" is my "LocalResolver" of a "RemoteVow" (ie, a Resolver in the 
same vat as the arrowtail -- a peculiar concept useful (only?) in 
implementing the comm system).  Your description is close enough to what 
actually happens -- the receiving vat is indeed given the ability to resolve 
the sending vat's RemoteVow -- the promise for the result of a send.  
Returning to our standard scenario, let's say the sending vat is VatA, the 
receiving vat is VatC, and the problem we're solving is Alice sending to Bob 
the RemoteVow/promise for the result of a message Alice sent to Carol.  VatA 
does indeed also send the LocalResolver for this promise to VatC (as 
argument of a whenResolved message).

In your solution, VatA would also give this LocalResolver to VatB, who would 
give it to VatC as an extra argument in the lookup (instead of, or in 
addition to, the Vine).  VatC would do a whenResolved round trip to it, 
rather than a round trip to the Vine, in order to determine when to reject 
the SwissNumber lookup request.

This may or may not have the right scheduling behavior -- I'm not sure yet.  
However, it has a fatal security problem: VatB has been given the authority 
to resolve the RemoteVow in VatA.


        Cheers,
        --MarkM