Yeah, Cap'n Proto is focused exclusively on communications between actors, while remaining agnostic to how actors represent state internally.
Distributed state is a very complicated problem with lots of different solutions providing trade-offs appropriate for different kinds of applications. E.g. do you need distributed consensus a la Paxos or Raft (really hard!), or do you only need one-way replication (easy), or would it make sense to go with an eventually-consistent approach using CRDT or operational transforms (somewhere in the middle)? Different apps need different things so it would be a bad idea for Cap'n Proto to insist on anything in particular. Of course, you can build any of these things on top of Cap'n Proto, and you can probably integrate existing libraries that do these things with Cap'n Proto as the communications layer. I would argue that capabilities make it easier to express efficient stateful interactions, since an actor can hold a reference to a remote object which it is operating upon and receive notification if that reference is lost. A lot of synchronization complexity that, in a stateless protocol, must be performed on every single operation, in a capability protocol only needs to be performed when initially obtaining the capability, after which subsequent operations can reuse that already-prepared context. FWIW I am interested in designing an operational transform framework on top of Cap'n Proto at some point... but have no specific plans. -Kenton On Sun, May 7, 2017 at 12:09 AM, Hedge Hog <[email protected]> wrote: > Hi Kenton, > Thanks for the clarification. > > I'm striving to think of ways to keep matters **simple**, and also use > pre-baked components. > It sounds like we could rely on CP to tell the client and server when > there have been disconnects. > > It seems to me that it is state synchronization that is thorny - my > experience has been with MPI/MPICH, and a few other home made apps > running across 400+ PCs, but that was on windows and nearly 15 years > ago. If I understand correctly these sorts of issues are out of the > scope of CP? > > I'm wondering what you think of synchronization issues being managed > by being delegated to something like keepalived, heartbeat, corosync. > That way we get features like quorum, fencing mgt etc out of the box. > > Plus by handling all these issues outside of CP we kinda force the > users to keep all of this logic out of the client that is using CP. > Like you said reconnect and try again, or start from an agreed > checkpoint is perfectly reasonable. > > Best wishes > > > On Sun, May 7, 2017 at 1:33 PM, Kenton Varda <[email protected]> wrote: > > Hi, > > > > Cap'n Proto hasn't implemented level 3 yet, but I don't think the > > requirement you quote is actually looking for it. "Level 3" refers to > > automated three-party handoff, a feature that almost no other protocol > out > > there has in the first place. I suspect 3PH will be very useful it IoT > > scenarios, but it's probably not what the requirement is asking for. > > > > Cap'n Proto's C++ library does indeed have a few mechanisms for detecting > > disconnects. Calls that are in-flight when a disconnect occurs will > throw an > > exception of the "DISCONNECTED" type. Additionally, you can register a > > callback to be called on disconnect. It is up to the application to > decide > > what to do once a disconnection is detected, though "reconnect and try > > again" is often a fine answer. > > > > -Kenton > > > > On Thu, May 4, 2017 at 5:18 PM, Hedge Hog <[email protected]> > wrote: > >> > >> > >> Hi, > >> I have another question in evaluating Cap'n Proto against the following > >> middle requirement: > >> > >> Idempotent Connect and Reconnect > >> Components shall be able to connect and reconnect to a running system > >> without requiring a full restart of the real-time stack. This > requirement > >> supposes that the transport stack provides measures to detect > disconnects > >> and connects to nodes to allow state synchronization of components if > >> necessary. > >> > >> From reading [1], sections 'Handling disconnects' and 'RPC Protocol', my > >> understanding is that level-3 of the CP protocol would go some way to > >> meeting this requirement. The 3rd-party client side code (in this case > >> Machinekit) would be responsible for synchronization - correct? > >> > >> What level of this RPC protocol is implemented in Cap'n Proto v0.6? > >> > >> [1]: https://capnproto.org/rpc.html > >> > >> Appreciate any other insight you can share. > >> > >> Best wishes > >> Hedge > >> > >> -- > >> 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 [email protected]. > >> Visit this group at https://groups.google.com/group/capnproto. > > > > > > > > -- > πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα > [The fox knows many things, but the hedgehog knows one big thing.] > Archilochus, Greek poet (c. 680 BC – c. 645 BC) > http://hedgehogshiatus.com > > -- > 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 [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- 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 [email protected]. Visit this group at https://groups.google.com/group/capnproto.
