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

Get Connection State #205

Open
mihai1voicescu opened this issue Jan 20, 2022 · 2 comments
Open

Get Connection State #205

mihai1voicescu opened this issue Jan 20, 2022 · 2 comments

Comments

@mihai1voicescu
Copy link

It would be great if we could listen to the current connection state.

Motivation

Viewing the current connection state is important, especially when using the reconnect feature. This will enable a bunch of new use cases without the need to create a hacky workaround.

Example use case:

  • Client side: Displaying a disconnected message in a chat app
  • Server side: Marking the worker disconnected and not sending any more work to it.
  • Logging so we can debug the rest of the application

Desired solution

Add the possible states and expose them via a StateFlow.

I am open to do a PR if you would like, but I would like a list of possible states 😄 .

As an example:

  • Connecting - Connecting for the first time
  • Connected
  • Disconnected - Has disconnected
  • Reconnecting - Attempting to reconnect, will only be emitted for reconnect version
  • Failed - Closed with an error
  • Closed - Closed normally
@olme04
Copy link
Contributor

olme04 commented Jan 21, 2022

Hey, thanks for an idea!

As for Client side:
We already have something similar internally to support reconnect feature. There are 3 states there: Connecting, Connected and Failed. Im all for providing some public API for it, but we also need to think about resume feature, that will come soon, and as so provide more info about state (f.e. Resuming, Resume Failed and may be something else).

As for Server side:
On current moment, with reconnect feature only, server can know only that client disconnected, this is already there, you can call ConnectionAcceptorContext.requester.coroutineContext.job.invokeOnCompletion { callback }. But with resume this can be improved, so server will know, that client may resume in near future.

I like the proposal, but on current moment I'm in progress with polishing (and breaking :) ) Public API and implementing new features like resume and lease, so I'm not sure, that it's not the best time to add such a feature.

But!
For Client side, this can be implemented externally for now.
You can look at https://github.com/rsocket/rsocket-kotlin/blob/master/rsocket-core/src/commonMain/kotlin/io/rsocket/kotlin/internal/ReconnectableRSocket.kt. This file have full logic for reconnect implementation, and if you need state preserved, you can just copy it and change return type from RSocket to ReconnectableRSocket with exposed state as some sealed class! Don't forget then not to use out-of-the-box reconnect feature.

@mihai1voicescu
Copy link
Author

For the moment I went for another route on the client, since I need just Connected and Disconnected and use the retry feature I just created a StateFlow(Disconnected) and:

  • Each time the Acceptor handler finishes state goes to Connected
  • Each time the shouldRetry callback is called state goes to Disconnected

@whyoleg whyoleg added this to the 0.16.0 milestone Oct 5, 2022
@whyoleg whyoleg modified the milestone: 0.17.0 - Lease and Resume support, configuration API rework Nov 24, 2022
@whyoleg whyoleg removed this from the 0.17.0 - Lease and Resume support, configuration API rework milestone May 3, 2023
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

3 participants