Hi Jens, To clarify, when I say "Carol lives in Vat A, i.e. next to Alice", I am saying that Alice and Carol are two objects living in the same process. So a capability pointing to Carol was passed across the network and then back again, over the same connection. In this case, we want to shorten the path so that calls from Alice to Carol are direct local calls, not bouncing across the network connection. This scenario does in fact come up in Level 1, as it only involves two "vats" (a "vat" is essentially one process running Cap'n Proto; the RPC protocol is used to communicate between vats).
Embargoes are needed here for the reasons described in the comments: When Alice discovers her promise P resolves to Carol, she may have already sent some messages towards the promise using pipelining. Before Alice can start making direct local calls to Carol, those messages have to cross the network connection and reflect back, so that they are delivered first. -Kenton On Sat, Dec 17, 2022 at 3:18 PM Jens Alfke <j...@mooseyard.com> wrote: > As I peruse the RPC spec (rpc.capnp), I’m following along pretty well > until I hit the ‘disembargo’ message (which my spellchecker keeps changing > into ‘disembark’, but that’s another matter.) > > At this point I’m only interested in Level 1 functionality, two peers, > which AFAIK is as far as the implementation is gotten.Disembargo is a level > 1 message, and I’m having some trouble understanding it, partly because it > seems to only be relevant at levels 2+. The description starts on line 660: > > # Message sent to indicate that an embargo on a recently-resolved > promise may now be lifted. > # > # Embargos are used to enforce E-order in the presence of promise > resolution. That is, if an > # application makes two calls foo() and bar() on the same capability > reference, in that order, > # the calls should be delivered in the order in which they were made. > But if foo() is called > # on a promise, and that promise happens to resolve before bar() is > called, then the two calls > # may travel different paths over the network, and thus could arrive in > the wrong order. In > # this case, the call to `bar()` must be embargoed, and a `Disembargo` > message must be sent along > # the same path as `foo()` to ensure that the `Disembargo` arrives after > `foo()`. Once the > # `Disembargo` arrives, `bar()` can then be delivered. > > > I was following along OK until “the two calls may travel different paths > over the network.” We’re at Level 1, so there is only one path, the socket > between peer A and peer B. > > Also, in "that promise happens to resolve before bar() is called”, should > that be "*after* bar() is called”? Because if foo resolves before, why > would that make the foo call arrive after the bar call? > > If you have time, Kenton, I’d love to see the " Carol lives in Vat A, i.e. > next to Alice. In this case, Vat A needs to send a `Disembargo` message > that echos through Vat B and back…” scenario broken down step-by-step. (Or > if this situation is discussed in the old erights.org site, let me know > the URL; I didn’t see it when I was reading through their protocol docs.) > > Thanks! > > —Jens > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to capnproto+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/capnproto/E3F6C227-23BD-41E9-A4BA-A93EE4586C49%40mooseyard.com > <https://groups.google.com/d/msgid/capnproto/E3F6C227-23BD-41E9-A4BA-A93EE4586C49%40mooseyard.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQn8z9VdU2wNeix%3DDjeOzr%3Div9C8_ej%3DbN0PJEaiMYS27Q%40mail.gmail.com.
