cannam@62: # Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors
cannam@62: # Licensed under the MIT License:
cannam@62: #
cannam@62: # Permission is hereby granted, free of charge, to any person obtaining a copy
cannam@62: # of this software and associated documentation files (the "Software"), to deal
cannam@62: # in the Software without restriction, including without limitation the rights
cannam@62: # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
cannam@62: # copies of the Software, and to permit persons to whom the Software is
cannam@62: # furnished to do so, subject to the following conditions:
cannam@62: #
cannam@62: # The above copyright notice and this permission notice shall be included in
cannam@62: # all copies or substantial portions of the Software.
cannam@62: #
cannam@62: # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
cannam@62: # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
cannam@62: # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
cannam@62: # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
cannam@62: # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
cannam@62: # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
cannam@62: # THE SOFTWARE.
cannam@62: 
cannam@62: @0xa184c7885cdaf2a1;
cannam@62: # This file defines the "network-specific parameters" in rpc.capnp to support a network consisting
cannam@62: # of two vats.  Each of these vats may in fact be in communication with other vats, but any
cannam@62: # capabilities they forward must be proxied.  Thus, to each end of the connection, all capabilities
cannam@62: # received from the other end appear to live in a single vat.
cannam@62: #
cannam@62: # Two notable use cases for this model include:
cannam@62: # - Regular client-server communications, where a remote client machine (perhaps living on an end
cannam@62: #   user's personal device) connects to a server.  The server may be part of a cluster, and may
cannam@62: #   call on other servers in the cluster to help service the user's request.  It may even obtain
cannam@62: #   capabilities from these other servers which it passes on to the user.  To simplify network
cannam@62: #   common traversal problems (e.g. if the user is behind a firewall), it is probably desirable to
cannam@62: #   multiplex all communications between the server cluster and the client over the original
cannam@62: #   connection rather than form new ones.  This connection should use the two-party protocol, as
cannam@62: #   the client has no interest in knowing about additional servers.
cannam@62: # - Applications running in a sandbox.  A supervisor process may execute a confined application
cannam@62: #   such that all of the confined app's communications with the outside world must pass through
cannam@62: #   the supervisor.  In this case, the connection between the confined app and the supervisor might
cannam@62: #   as well use the two-party protocol, because the confined app is intentionally prevented from
cannam@62: #   talking to any other vat anyway.  Any external resources will be proxied through the supervisor,
cannam@62: #   and so to the contained app will appear as if they were hosted by the supervisor itself.
cannam@62: #
cannam@62: # Since there are only two vats in this network, there is never a need for three-way introductions,
cannam@62: # so level 3 is free.  Moreover, because it is never necessary to form new connections, the
cannam@62: # two-party protocol can be used easily anywhere where a two-way byte stream exists, without regard
cannam@62: # to where that byte stream goes or how it was initiated.  This makes the two-party runtime library
cannam@62: # highly reusable.
cannam@62: #
cannam@62: # Joins (level 4) _could_ be needed in cases where one or both vats are participating in other
cannam@62: # networks that use joins.  For instance, if Alice and Bob are speaking through the two-party
cannam@62: # protocol, and Bob is also participating on another network, Bob may send Alice two or more
cannam@62: # proxied capabilities which, unbeknownst to Bob at the time, are in fact pointing at the same
cannam@62: # remote object.  Alice may then request to join these capabilities, at which point Bob will have
cannam@62: # to forward the join to the other network.  Note, however, that if Alice is _not_ participating on
cannam@62: # any other network, then Alice will never need to _receive_ a Join, because Alice would always
cannam@62: # know when two locally-hosted capabilities are the same and would never export a redundant alias
cannam@62: # to Bob.  So, Alice can respond to all incoming joins with an error, and only needs to implement
cannam@62: # outgoing joins if she herself desires to use this feature.  Also, outgoing joins are relatively
cannam@62: # easy to implement in this scenario.
cannam@62: #
cannam@62: # What all this means is that a level 4 implementation of the confined network is barely more
cannam@62: # complicated than a level 2 implementation.  However, such an implementation allows the "client"
cannam@62: # or "confined" app to access the server's/supervisor's network with equal functionality to any
cannam@62: # native participant.  In other words, an application which implements only the two-party protocol
cannam@62: # can be paired with a proxy app in order to participate in any network.
cannam@62: #
cannam@62: # So, when implementing Cap'n Proto in a new language, it makes sense to implement only the
cannam@62: # two-party protocol initially, and then pair applications with an appropriate proxy written in
cannam@62: # C++, rather than implement other parameterizations of the RPC protocol directly.
cannam@62: 
cannam@62: using Cxx = import "/capnp/c++.capnp";
cannam@62: $Cxx.namespace("capnp::rpc::twoparty");
cannam@62: 
cannam@62: # Note: SturdyRef is not specified here. It is up to the application to define semantics of
cannam@62: # SturdyRefs if desired.
cannam@62: 
cannam@62: enum Side {
cannam@62:   server @0;
cannam@62:   # The object lives on the "server" or "supervisor" end of the connection. Only the
cannam@62:   # server/supervisor knows how to interpret the ref; to the client, it is opaque.
cannam@62:   #
cannam@62:   # Note that containers intending to implement strong confinement should rewrite SturdyRefs
cannam@62:   # received from the external network before passing them on to the confined app. The confined
cannam@62:   # app thus does not ever receive the raw bits of the SturdyRef (which it could perhaps
cannam@62:   # maliciously leak), but instead receives only a thing that it can pass back to the container
cannam@62:   # later to restore the ref. See:
cannam@62:   # http://www.erights.org/elib/capability/dist-confine.html
cannam@62: 
cannam@62:   client @1;
cannam@62:   # The object lives on the "client" or "confined app" end of the connection. Only the client
cannam@62:   # knows how to interpret the ref; to the server/supervisor, it is opaque. Most clients do not
cannam@62:   # actually know how to persist capabilities at all, so use of this is unusual.
cannam@62: }
cannam@62: 
cannam@62: struct VatId {
cannam@62:   side @0 :Side;
cannam@62: }
cannam@62: 
cannam@62: struct ProvisionId {
cannam@62:   # Only used for joins, since three-way introductions never happen on a two-party network.
cannam@62: 
cannam@62:   joinId @0 :UInt32;
cannam@62:   # The ID from `JoinKeyPart`.
cannam@62: }
cannam@62: 
cannam@62: struct RecipientId {}
cannam@62: # Never used, because there are only two parties.
cannam@62: 
cannam@62: struct ThirdPartyCapId {}
cannam@62: # Never used, because there is no third party.
cannam@62: 
cannam@62: struct JoinKeyPart {
cannam@62:   # Joins in the two-party case are simplified by a few observations.
cannam@62:   #
cannam@62:   # First, on a two-party network, a Join only ever makes sense if the receiving end is also
cannam@62:   # connected to other networks.  A vat which is not connected to any other network can safely
cannam@62:   # reject all joins.
cannam@62:   #
cannam@62:   # Second, since a two-party connection bisects the network -- there can be no other connections
cannam@62:   # between the networks at either end of the connection -- if one part of a join crosses the
cannam@62:   # connection, then _all_ parts must cross it.  Therefore, a vat which is receiving a Join request
cannam@62:   # off some other network which needs to be forwarded across the two-party connection can
cannam@62:   # collect all the parts on its end and only forward them across the two-party connection when all
cannam@62:   # have been received.
cannam@62:   #
cannam@62:   # For example, imagine that Alice and Bob are vats connected over a two-party connection, and
cannam@62:   # each is also connected to other networks.  At some point, Alice receives one part of a Join
cannam@62:   # request off her network.  The request is addressed to a capability that Alice received from
cannam@62:   # Bob and is proxying to her other network.  Alice goes ahead and responds to the Join part as
cannam@62:   # if she hosted the capability locally (this is important so that if not all the Join parts end
cannam@62:   # up at Alice, the original sender can detect the failed Join without hanging).  As other parts
cannam@62:   # trickle in, Alice verifies that each part is addressed to a capability from Bob and continues
cannam@62:   # to respond to each one.  Once the complete set of join parts is received, Alice checks if they
cannam@62:   # were all for the exact same capability.  If so, she doesn't need to send anything to Bob at
cannam@62:   # all.  Otherwise, she collects the set of capabilities (from Bob) to which the join parts were
cannam@62:   # addressed and essentially initiates a _new_ Join request on those capabilities to Bob.  Alice
cannam@62:   # does not forward the Join parts she received herself, but essentially forwards the Join as a
cannam@62:   # whole.
cannam@62:   #
cannam@62:   # On Bob's end, since he knows that Alice will always send all parts of a Join together, he
cannam@62:   # simply waits until he's received them all, then performs a join on the respective capabilities
cannam@62:   # as if it had been requested locally.
cannam@62: 
cannam@62:   joinId @0 :UInt32;
cannam@62:   # A number identifying this join, chosen by the sender.  May be reused once `Finish` messages are
cannam@62:   # sent corresponding to all of the `Join` messages.
cannam@62: 
cannam@62:   partCount @1 :UInt16;
cannam@62:   # The number of capabilities to be joined.
cannam@62: 
cannam@62:   partNum @2 :UInt16;
cannam@62:   # Which part this request targets -- a number in the range [0, partCount).
cannam@62: }
cannam@62: 
cannam@62: struct JoinResult {
cannam@62:   joinId @0 :UInt32;
cannam@62:   # Matches `JoinKeyPart`.
cannam@62: 
cannam@62:   succeeded @1 :Bool;
cannam@62:   # All JoinResults in the set will have the same value for `succeeded`.  The receiver actually
cannam@62:   # implements the join by waiting for all the `JoinKeyParts` and then performing its own join on
cannam@62:   # them, then going back and answering all the join requests afterwards.
cannam@62: 
cannam@62:   cap @2 :AnyPointer;
cannam@62:   # One of the JoinResults will have a non-null `cap` which is the joined capability.
cannam@62:   #
cannam@62:   # TODO(cleanup):  Change `AnyPointer` to `Capability` when that is supported.
cannam@62: }