Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic reconnection #79

Open
ecorm opened this issue Sep 4, 2015 · 3 comments
Open

Automatic reconnection #79

ecorm opened this issue Sep 4, 2015 · 3 comments

Comments

@ecorm
Copy link
Owner

ecorm commented Sep 4, 2015

Provide automatic reconnection facilities. If a connection is dropped unexpectedly, CppWAMP would re-establish the session using the list of connector objects. It should also re-register RPCs and re-subscribe to events.

@michaelaeriksen
Copy link

Any updates on this? Any pointers to where to implement the fix?

@ecorm
Copy link
Owner Author

ecorm commented Sep 7, 2016

Like I said for your other comment: Sorry, I haven't yet put any thought in how I'd implement this. It's not an urgent feature for my project because Crossbar is hosted on the same device as my C++ program.

@ecorm
Copy link
Owner Author

ecorm commented May 21, 2022

Session state change callbacks (#78) are now implemented in 637589d. This should allow the user to implement their own reconnection logic.

I'm not sure yet what would be a sensible policy for an automatic reconnection feature provided by CppWAMP. Things to consider:

  • Lengthening the intervals between reconnection attempts when the first attempt fails
  • Number of retries before giving up

Another thing to consider is that Registration and Subscription objects become invalidated when a new session is established.

The current design with internal::Client objects being created for every Session connection operation admittedly makes things complicated. The rationale was to avoid virtual function calls when using the TCodec bound to the Client instance. In hindsight, the resulting complexity is not worth the potential performance gains, which I never even measured.

I'm therefore placing this feature on the back burner considering that the user now has a means to react to session disconnection/failure events. I'll take a look at it again if I get the chance to refactor the current design to favor runtime polymorphism over compile-time (i.e. template) polymorphism.

I'll take this opportunity to make a note to myself to keep an eye on the proposed Session Resumption WAMP protocol feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants