SignalR 1.01 hubs in ASP.Net: storing group information across pages [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I am currently building a SignalR application (using ASP.Net MVC4, on IIS7 with SQL Server 2008 R2 Express), where users enter a lobby and are placed into groups and then interact on different pages.

Html5 LocalStorage is a requirement for any participant, so I can store group information on the client side.

I have two questions about the application design related to SignalR group memberships:

1. What is the best way to store group membership on the server? a singleton variable, a database with group and connection IDs or something different? Would a database be a problem with SQL Server Express and about 100-200 users?

2. What will change and fire during page changes? Do I have to renew group memberships manually, do the disconnect/reconnect fire and if yes can I distinguish this type of disconnect from users leaving for good?

Answer 1

(1) If you intend to persist the group information only for a session, you should consider using static variables in the Hub/Persistent Connection class to store information about the groups (memory requirements permitting). For instance, a dictionary/map between connection ids and groups. It's important to note that statics will not be persisted in cases such as when the app domain restarts or in web farms.

To avoid this, you can simply store the group information in a database and not be concerned about losing it during app domain restarts.

You should also see the Chat sample in the SignalR solution - it uses static variables to keep information about which chat rooms different users are in.

(2) If you establish a new connection from another page in the same app, then the connection id will be different. When you refresh a page, the disconnect event will fire and you will be connected again with a different id. In these cases, you will need to manually use the session management mechanism in your app to map the new connection ids to users.

Answer 2

1. I use msopentech.redis for that. A very fast cache that also persists your data. (lots of info found on google) You could use booksleeve (signalr team also uses that) or servicestack.redis to access it. This way you won't have to put it in static vars or slow database calls.

2. With every page changes on the same site you'll receive a disconnect and a connect. The connectionID will be different, so you should map connectionid's to the logged in user with some mechanism and persist that. That is if you want to be able to send individual messages instead of broadcasting.