Hi Michi, I think that design makes sense for Ice, but with Cap'n Proto being capability-based, it's trickier. If the connection has any live capabilities, it's similar to having outstanding calls -- we can't reconnect transparently. But typically a Cap'n Proto connection will always have live capabilities, since the first thing you usually do after connecting is to request the root capability. Unlike calls, capabilities tend to be long-lived.
If TCP connections are too unreliable, it could make sense to develop a session layer which lives under the Cap'n Proto RPC system but above the network, and which transparently restarts connections when they drop. This could be done without modifying the Cap'n Proto library, since the transport layer is abstracted. Of course, there's no such thing as a completely reliable network transport and the right trade-offs depend on the application. -Kenton On Sat, May 6, 2017 at 8:59 PM, Michi Henning <[email protected]> wrote: > 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]> > wrote: > >> >> Hi, >> I have another question in evaluating Cap'n Proto against the following >> middle requirement: >> >> >> >> *Idempotent Connect and ReconnectComponents 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. >> > > > -- > 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. > -- 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.
