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.
