Saving SignalR connection state with scaleout servers

1
votes

Using SignalR 2.2.0, I would like some validation of observations concerning clients executing hub methods in a multi-server scale out setup.

I have SignalR running in a multi server model, using the SQL Server scaleout message bus.

When a client connects, the OnConnected method of the Hub is called, as expected. I save the Context.ConnectionId in static dictionary.

When the client later calls a method of the hub, it seems that another server in the farm is executing the hub method and not the server that originally ran the OnConnected method. The Context.ConnectionId value in the hub method is correct, but it does not exist in the dictionary.

Is this the expected behaviour in the scale out model? If so, then I assume that I should be saving connection state data in database so that all Hub on all the servers will be able to look up the connection state based on the ConnectionId.

1
c#asp.netsignalrsignalr-hubsignalr-backplane
Generally, storing shared information in a shared db is a way to go with scaleout model. But I don't see why you need to store connection state, the servers in signalR should care only about its local state, this information does not need to be shared. All we need is a backplane to transfer messages between servers. Do you have any specific requirements that need to share this information? – Khanh TO
Let's say we have 3 users (1,2,3) connected to server1, 3 users (4,5,6) connected to server2. When the user 4 sends a message to user 1, the message goes from the user 4 => server 2 => backplane => server 1 => user 1. This also works if the user 1 connects to both servers (on different devices), in this case, both server1 and server2 respond to user 1 with different connection Ids which represent different devices or different browser tabs,.....without any problem. – Khanh TO

1 Answers

1
votes

Is this the expected behaviour in the scale out model? If so, then I assume that I should be saving connection state data in database so that all Hub on all the servers will be able to look up the connection state based on the ConnectionId.

Yes this is expected behaviour, you should use shared resource like database or cache. But connectionIds will be not enough by itself. Because a client will get different connectionIds on different servers or on refreshes. So you should map connectionId and client. When a disconnect occurs find client with connectionId and check this client has another connectionId.

In here I have answered more detail based on question.