In Ice, the default behavior when a connection is lost in the middle of an RPC is to report the error to the caller. That’s because Ice provides an “at most once” guarantee. If the connection goes down while the response to a request is outstanding, there is no way to know on the client side whether the connection went down just before the request was received by the server (and never acted upon), or just after (meaning the operation was dispatched into the server application code). Therefore, the run time is conservative and will not retry such a failed request.
It’s possible to mark an operation as idempotent at the interface definition level. If so, the Ice run time will retry the operation after disconnection even if that might lead to a request being received (and acted upon) twice by the server. That’s useful especially when a server can be reached via more than one endpoint, or if there are multiple servers for the same object identity. If a connection is lost while no RPCs are outstanding on that connection, the run time tries to transparently re-establish the connection. As far as the logical view of the client and server application are concerned, connections don’t exist. They can be transparently established and torn down by the run time. Personally, I’m not that fond of schemes that allow the application to monitor connection state; I don’t think it is generally useful to use connections to implement a session concept; the two mechanisms are too different. Cheers, Michi. > On 7 May 2017, at 13:33 , 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] > <mailto:[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 <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] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/capnproto > <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] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/capnproto > <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.
