[e-cvs] cvs commit: e/doc/elib/distrib/captp WormholeOp.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Tue, 15 May 2001 13:10:37 -0400
markm 01/05/15 13:10:37
Modified: doc/elib/distrib/captp WormholeOp.html
Log:
added anchors and link to Tyler's solution
Revision Changes Path
1.4 +60 -49 e/doc/elib/distrib/captp/WormholeOp.html
Index: WormholeOp.html
===================================================================
RCS file: /cvs/e/doc/elib/distrib/captp/WormholeOp.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- WormholeOp.html 2001/05/13 02:48:28 1.3
+++ WormholeOp.html 2001/05/15 17:10:37 1.4
@@ -71,14 +71,14 @@
bytes towards <code>dest</code> before allowing any further causality
to flow from the requesting vat through the receiving vat to <code>dest</code>.
Otherwise is can discard this data.
- <h1 ALIGN="left">The Conflict Solved by WormholeOp</h1>
+ <h1 ALIGN="left"><a name="conflict"></a>The Conflict Solved by WormholeOp</h1>
<p>Without the WormholeOp, there are a set of requirements in the E semantics
that are individually quite sensible and compelling, but that jointly
seem to be impossible:</p>
<p>
<ul>
<li>
- <p><a href="../../concurrency/partial-order.html#tree-order"><b>Partial
+ <p><a name="partial-order"></a><a href="../../concurrency/partial-order.html#tree-order"><b>Partial
ordering</b></a>: In a 3-vat Granovetter introduction, that the forked
reference sent to Bob gives Bob access only to post-X Carol, only
enabling messages from Bob to arrive at Carol after X is delivered.
@@ -86,8 +86,8 @@
this requirement.)</p>
</li>
<li>
- <p><b>Allow services with Near arguments</b>. In order to allow services
- like the <a href="../../capability/ode/ode-capabilities.html#simple-money">MintMaker</a>
+ <p><b><a name="simple-servers"></a>Allow services with Near arguments</b>.
+ In order to allow services like the <a href="../../capability/ode/ode-capabilities.html#simple-money">MintMaker</a>
to be correct when written this simply, we allow it to require its
arguments, such as the src argument of the deposit message, to be
Near. Of course, this requirement can only be satisfied when the argument
@@ -114,11 +114,11 @@
the current implementations of E meet this requirement.)</p>
</li>
<li>
- <p><b>Preserve passability</b>. A PassByCopy object that contains only
- passable parts should be passable by copy between vats. The problem
- here is a hashtable-based PassByCopy collection, T, (whether the current
- <a href="../../elang/collect/tables.html">EMap</a> or the anticipated
- <a href="http://www.waterken.com/Hydro/2.0/doc/abridged-index.html">Hydro</a>-based
+ <p><b><a name="passability"></a>Preserve passability</b>. A PassByCopy
+ object that contains only passable parts should be passable by copy
+ between vats. The problem here is a hashtable-based PassByCopy collection,
+ T, (whether the current <a href="../../elang/collect/tables.html">EMap</a>
+ or the anticipated <a href="http://www.waterken.com/Hydro/2.0/doc/abridged-index.html">Hydro</a>-based
replacement) that has as one of it's keys a PassByProxy object, let's
say Carol in VatC. If T is passed to Alice in VatA, everything's cool,
and it arrives with a Far reference to Carol as its key. However,
@@ -143,56 +143,67 @@
However, because Near references give immediate access, it may not arrive
as a Near references until all prior messages, such as X from Alice, have
drained out.</p>
- <h1>Three Plausible Engineering Solutions</h1>
+ <h1><a name="solutions"></a>Some Plausible Engineering Solutions</h1>
<p>
- <ol>
- <li>
- <p>Introduce a new kind of reference into our reference taxonomy:
- The <i>Indirect</i> reference is a Settled but not Resolved remote
- reference to a PassByProxy object. Dean, MarcS, and I (MarkM) actually
- worked out the semantics for this, and earlier in the cvs history
- you'll find some corresponding taxonomy diagrams and explanations,
- but it just made E too hard to explain.</p>
- </li>
- <li>
- <p>Block all further communications from VatB to VatC until all communications
- from VatA to VatC prior to the introduction have drained out, or
- until the VatA/VatC timeout period expires, killing the connection.
- This could repeatedly impose a huge cost on VatB for the sake of
- only a few objects in VatB. While E avoids making any claims about
- resistance to denial of service attack, this would be too aggregious
- a vulnerability to such an attack.</p>
- </li>
- <li>
- <p>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. VatTP already encrypts this traffic
- for secrecy, integrity, authenticity, and protection against replay
- attacks, so that this communications can be carried by untrusted
- intermediaries. VatB is just another untristed intermediary. If
- VatC gets the next communication in the VatA/VatC stream via a wormhole
- from VatB, that's fine. It doesn't matter where the bits came from,
- as long as they pass all the crypto tests. When these same bits
- come in redundantly through another path, they may be safely ignored.</p>
- </li>
- </ol>
- <p>As you've no doubt guessed, we're planning to pursue path #3.</p>
- <h1>Wormhole Introduction Scenario</h1>
+ <ol>
+ <li>
+ <p><b><a name="indirect"></a>Invent the Indirect reference</b>. Introduce
+ a new kind of reference into our reference taxonomy: The <i>Indirect</i>
+ reference is a Settled but not Resolved remote reference to a PassByProxy
+ object. Dean, MarcS, and I (MarkM) actually worked out the semantics
+ for this, and earlier in the cvs history you'll find some corresponding
+ taxonomy diagrams and explanations, but it just made E too hard to
+ explain.</p>
+ </li>
+ <li>
+ <p><b><a name="wait"></a>Wait for drainage</b>. Block all further communications
+ from VatB to VatC until all communications from VatA to VatC prior
+ to the introduction have drained out, or until the VatA/VatC timeout
+ period expires, killing the connection. This could repeatedly impose
+ a huge cost on VatB for the sake of only a few objects in VatB. While
+ E avoids making any claims about resistance to denial of service attack,
+ this would be too aggregious a vulnerability to such an attack.</p>
+ </li>
+ <li>
+ <p><a name="WormholeOp"></a><b>WormholeOp</b>. 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. VatTP already encrypts this traffic for secrecy, integrity,
+ authenticity, and protection against replay attacks, so that this
+ communications can be carried by untrusted intermediaries. VatB is
+ just another untristed intermediary. If VatC gets the next communication
+ in the VatA/VatC stream via a wormhole from VatB, that's fine. It
+ doesn't matter where the bits came from, as long as they pass all
+ the crypto tests. When these same bits come in redundantly through
+ another path, they may be safely ignored.</p>
+ </li>
+ <li>
+ <p><b><a name="new-identity"></a>Inter-vat forks make new identities</b>.
+ Do (or adapt) what Droplets does, as described in the thread rooted
+ <a href="http://www.eros-os.org/pipermail/e-lang/2001-May/005270.html">here</a>.
+ Briefly, give each inter-vat fork of a reference its own new Resolved
+ sameness identity, whether the original reference was Resolved or
+ not at the time of the fork. </p>
+ </li>
+ </ol>
+ <p>The WormholeOp needs to happens iff with decide to pursue path #3, which
+ is the current expectation.</p>
+ <h1><a name="scenario"></a>Wormhole Introduction Scenario</h1>
<p>The Wormhole introduction is only needed when VatA sends to VatB a Far
reference for an object on VatC. It isn't needed for any 2-vat introductions,
and it isn't needed when the reference passed from VatA to VatB is Unresolved,
such as a RemoveVow whose Resolver is on VatC, or is travelling to VatC.</p>
<p>*** To be written, but involves these CapTP steps:</p>
<p>VatA to VatC:</p>
- <blockquote>
+ <blockquote>
<pre>def vine := NonceLocator <- provideFor(farCarol,
vatBID,
nonce,
carolSwissHash)</pre>
- </blockquote>
+ </blockquote>
<p>VatA to VatB:</p>
- <blockquote>
+ <blockquote>
<pre>
WormholeOp(<font face="Times New Roman, Times, serif">/*unacknowledged encrypted A-to-C traffic*/</font>,
vatAID,
@@ -203,7 +214,7 @@
nonce,
carolSwissHash,
vine) ...</pre>
- </blockquote>
+ </blockquote>
<p>VatB to VatC:</p>
<blockquote>
<pre>WormholeOp(<font face="Times New Roman, Times, serif">/*unacknowledged encrypted A-to-C traffic*/</font>,
@@ -214,7 +225,7 @@
carolSwissHash,
vine)</pre>
/* carolPromise, a RemoteVow, is then magically turned into farCarol,
- a Far reference. */</blockquote>
+ a Far reference. */</blockquote>
<p>So, if VatA and VatB are cooperative, they are both assured that the
needed <code>provideFor</code> "from" VatA will be processed
by VatC before VatC sees the corresponding <code>acceptFrom</code> from