How to maintain SignalR Groups and Connections after SignalR server restart?

Question

My system is composed of

1. SignalR server
2. Multiple C# clients connecting to said SignalR server.

As I understand, once connected each of these clients would have its own associated ConnectionId .

Now, I want to implement a resiliency strategy where after the SignalR server is restarted, it should still retain the Groups and Connections it used to have in the Hub.

I was thinking of achieving this by storing the Groups and ConnectionIds in an external storage (eg database), and restore it when the application starts up.

When the server goes down, the clients' connection might have dropped. But this can be mitigated somewhat by making the client always attempt to reconnect on disconnection. Once the server is up, the client would reconnect.

However, this solution feels rather flaky. In particular, I'm not sure whether once the client reconnects it will retain the same ConnectionId .

Does this approach make sense? Is there a better way to do it?

Answer 1

Yes, client-reconnects ALWAYS happen with the same connectionID.
The connectionID is renewed ONLY in case:

1. the connection.stop() method is called from the client,
2. the server has detected client disconnection and does a disconnect on the server + sends a disconnect message to clients that happen to reconnect too late. Then those clients will close connection. So client-server are synced again.

If the client is connected to a server that is about to reboot , the clients will notice upon disconnection and try to reconnect to the server with the same connectionID, all within a given timeframe, defined by the connection-timeout .
If the server, then, reboots within the connection timeout frame, the client reconnects to the server, with the existing ID. In this case the Reconnect() event is fired on the server, without the OnConnected() event is happened. This is an exceptional signalr case.
Code your Reconnect() events very defensively.

link to official documentation explaining this issue
chapter: Server disconnection scenarios