[e-lang] WormholeOp questions

Mark Miller erights at gmail.com
Wed Aug 8 12:00:47 EDT 2007


On 8/7/07, Kevin Reid <kpreid at mac.com> wrote:
> http://www.erights.org/elib/distrib/captp/WormholeOp.html says:
>
> > When VatA introduces VatB to Carol, she first wormholes the
> > unacknowledged portion of her outgoing VatA-to-VatC VatTP stream
> > through VatB for delivery to VatC. VatB then wormholes it towards
> > VatC before acting on further messages from VatA.
>
> Am I correct that this last ordering guarantee is only for messages
> from VatA which would cause VatB to enqueue more traffic toward VatC?

Yes, but this always includes the case described above. If vatA sends
to vatB a farRef to Carol in vatC, this will cause vatB to communicate
to vatC.

> I ask because a premise of my CapTP design -- that CapTP messages can
> be implemented as messages delivered to an E object -- depends on not
> having to delay more than can be done synchronously (i.e. enqueue for
> VatB before the end of the turn).

I don't see the conflict. The suggested WormholeOp protocol is fully
non-blocking. I think I don't understand the question.


> > ... LookupDesc(VatCSearchPath,
> >                VatCID,
> >                nonce,
> >                carolSwissHash,
> >                vine) ...
>
> Should this be Far3Desc? There is no LookupDesc documented on the
> main CapTP page.

Yes.


> > So, if VatA and VatB are cooperative, they are both assured that
> > the needed provideFor "from" VatA will be processed by VatC before
> > VatC sees the corresponding acceptFrom from VatB. If either is
> > uncooperative, they cannot cause damage beyond that accounted for
> > by the object-level semantics. Because the data takes redundant
> > paths, neither side will get stuck waiting on the other to timeout.
>
> Am I correct that the reason VatB being uncooperative does no harm is
> that VatB cannot get a reference to Carol until the A->C provideFor
> is delivered, thus not performing the WormholeOp results in
> acceptFrom either failing or succeeding after the older A->C traffic
> has been delivered?

Yes.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM


More information about the e-lang mailing list