-
Notifications
You must be signed in to change notification settings - Fork 10.3k
[release/8.0-preview5] [SignalR] Seamless Reconnect #48427
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
[release/8.0-preview5] [SignalR] Seamless Reconnect #48427
Conversation
Hi @github-actions[bot]. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed. |
Approved in email |
@github-actions[bot], this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work! Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers. This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement. Thanks! |
Backport of #48338 to release/8.0-preview5
/cc @BrennanConroy
[SignalR] Seamless Reconnect
Description
New feature to improve resilience of SignalR connections. Without this feature, developers would need to rehydrate connection state when the connection goes down temporarily (e.g. driving through a tunnel) which could be expensive and non-trivial.
Initial implementation of feature #46691
Customer Impact
More resilient connections means writing less app logic to keep the app working smoothly in unstable network conditions.
Games are a great use case for this feature. You might be playing chess and are ok with the player disconnecting for 30 seconds due to network conditions, but want them to be able to resume as if they never left on reconnect. Without this feature the app would need to add some identification to the connection, keep track of it when it disconnects and reconnects, rehydrate the state on reconnect, and have a timer to cleanup state if the connection takes too long. Turning the feature on means most of that logic goes away and the app code can assume there will be an exception from SignalR to notify them when the connection is gone for too long.
Regression?
Risk
New opt-in feature, doesn't affect current apps
Verification
Packaging changes reviewed?