[e-lang] WormholeOp questions
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
> 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.
> > 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?
Text by me above is hereby placed in the public domain
More information about the e-lang