[SignalR] Stateful reconnect

[BrennanConroy]

Allows the server to retain the send buffer while the client is reconnecting and preserve connection state (Context.Items, connection ID, etc.).

Thoughts:

• Would need to be opt-in and supported by both client and server. Because client needs to change to try to reconnect with the same connection ID as its previous connection.
• Need an option to configure how long to keep the connection state on the server
• Skip negotiate doesn't play well in a multi-server environment when sticky-sessions aren't enabled
• How does it work with Azure SignalR Service
• Does the client need a new event to say "doing stateful reconnect"? What's the interaction with the current automatic reconnect feature?
• If client connects with different auth credentials, do we replace the User?

Needs work:

• Configurable buffer limit(s), total bytes count and maybe total message count too
• Versioning, probably increment HubProtocol and add "ack protocol"
• Try to push feature fully into SignalR layer, i.e. get new ConnectionContext from lower layer and map onto existing connection
  • Replace IReconnectFeature with IExistingConnectionFeature or something, that contains the previous ID on the new ConnectionContext (because client will send old id via query string)
  • Need timeout logic in SignalR layer then
  • And pause the read loop waiting for a new connection
  • Figure out what happens when a seamless reconnect takes too long, do we just kill the connection attempt, or keep it as a new connection (since the ConnectionContext is completely new) and send the new ID back to the client somehow?
  • Potentially send a CloseMessage from clients to have a guaranteed way of knowing the connection close is graceful
• If not, finalize IReconnectFeature API
• Fix StopAsync race in WebSocketsTransport (Running task being overwritten), it might be delaying reconnect fallback logic
• Pool buffers in MessageBuffer
• Finalize options for enabling the feature, both client and server side
  • And disallowing the feature from server side
• Retry policy for seamless reconnect attempts, separate from current reconnect policies
• Fix many TODOs in current code

[johnkattenhorn]

Hey @BrennanConroy, we've seen the pull request and the proposal, we think this will be a great feature for our use-case of mobile gaming which we've been working with @kevinguo305 on. We are working on a plan to put a reference architecture to illustrate how to use signalR in gaming.

@kevinguo305 - do you know if the team who built the UnityClient are aware of this work going on this feature ?

[BrennanConroy]

Glad to hear it! Are you in a position to be able to try out .NET previews? We're planning on getting the initial implementation into 8.0-preview5 and would love to find folks to try it out and make sure it works well.

[johnkattenhorn]

Yep - we would be happy to try it out.

[BrennanConroy]

@johnkattenhorn preview 5 is out.
To try this out you have to use the .NET client with WebSockets and enable the feature option:

var hubConnection = new HubConnectionBuilder()
    .WithUrl("<hub url>",
             options =>
             {
                options.UseAcks = true;
             })
    .Build();

[TimChen44]

This capability is too important for Blazor Server, and I hope that in the future, Blazor Server will not cause the entire program to crash due to network reasons.

[Webreaper]

Glad to hear it! Are you in a position to be able to try out .NET previews?

I'd love to try/test this, but for some reason .Net 8 previews still aren't supported by VS for Mac. Maybe in preview 6?

[m33p]

I wanted to give my feedback and this feature.
This feature is amazing and a must have. I've been engaging with our VPN team with connection issues to our Blazor application. One of our VPN or firewall is dropping the websocket connection. After testing with this feature turned on the issue isn't even noticeable. Please ship this with .NET 8.

[adityamandaleeka]

That's great to hear @m33p. @johnkattenhorn Have you had a chance to try it as well?

As you've seen, we got the initial implementation out in preview 5 and plan to make some improvements in preview 7. I'm moving the milestone on this issue to reflect that.