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

Server-side: handle reconnection, potentially to different server #5562

Open
chris-ray opened this Issue Jul 28, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@chris-ray
Copy link
Contributor

chris-ray commented Jul 28, 2018

If after a delay, or a lost network connection the websocket disconnects. It seems it will never reconnect.

image

@SteveSandersonMS

This comment has been minimized.

Copy link
Member

SteveSandersonMS commented Aug 6, 2018

Yes, this is correct. In fact there are a wide range of cases where recovery behavior is needed (e.g., server goes down and user needs to be transferred to a different server within the load balancing group).

We've been considering these scenarios in detail. However I don't think we have a tracking issue for them yet, so I'm going to change the issue title for this one and use it as the tracking issue.

@SteveSandersonMS SteveSandersonMS changed the title Server-side blazor needs to handle reconnection of websocket Server-side: handle reconnection, potentially to different server Aug 6, 2018

@SteveSandersonMS

This comment has been minimized.

Copy link
Member

SteveSandersonMS commented Aug 6, 2018

Note that the expected solution for this is going to involve the app developer making their per-user state serializable so that it's transferrable between servers and doesn't have to be kept live in the server's memory forever. When a user disconnects, we don't know if that's because they are finished, or if it's because there was a network issue and they will attempt to reconnect and resume shortly. So the server doesn't know to keep their state in memory, and even if it does, that wouldn't guarantee the user reconnects to the same server.

In summary, a robust solution will involve the app developer doing some work and accounting for it in their app architecture. We intend to provide patterns to make this straightforward and robust, but it will still require the app developer to be aware of them and fit in with those patterns.

@wanton7

This comment has been minimized.

Copy link

wanton7 commented Sep 18, 2018

Our company would use server side Blazor for some of our internal tools if there was even simple reconnect support. That would only supports single server and keeping state in memory with timeout.

@TheFanatr

This comment has been minimized.

Copy link

TheFanatr commented Oct 3, 2018

Assuming that something similar to what is detailed below has already been drafted by the Blazor team internally, this is being submitted here just it in case it helps gets any extra thoughts moving about how the structure of a session control system could work.

Essentially, I am proposing that a new API be created called Session, containing static methods for terminating, resetting, transferring, temporarily (based on a predicate and an auxiliary timeout value) extending the timeout for, or restarting a session. It should also contain a property for the current session, as well as a configuration struct for settings regarding the session's timeout and disconnection settings, providing a settable default instance as well. Session should also have instance events for disconnection, timeout, and reconnection, as well as a settable state object that could be used for identification and data serialization upon disconnection or whenever.

It could also be structured similarly to IJSInterop, with ISession and an implementation called ServerSideBlazorSession or something.

Hope I could provide something useful.

@aspnet-hello aspnet-hello transferred this issue from aspnet/Blazor Dec 17, 2018

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