[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?