SignalR gives you events when users connect, disconnect, and reconnect, however the only identifying piece of information you have at this point is their connection ID. Unfortunately it’s not very practical to identify all your connected users strictly off their connectionIDs – usually you have some other identifier in your application (userID, email, etc).
If you are using ASP.NET MVC3, you can access this information from the hub context via
Context.User, but if you aren’t using mvc3 (like a .net to .net client) a good workflow is to have your client identify themselves on connect. They can call a known
Register method on the hub and give you the identifying information of who they are.
At this point you have your unique identifier along with their connectionID, but you have to manage all their disconnections, reconnections, and multiple connections of the same client yourself. This post will go through … Read more
This article was originally published at tech.blinemedical.com
SignalR does a great job of dealing with reconnecting to a host when either the client disconnects or the server disconnects. This is pretty handy since it handles all the intricacies of a persistent http connection for you. But what it doesn’t deal with is the initial negotiation to a server. If that fails you are stuck retrying yourself. I wrote a simple reconnection function that leverages the scheduling functionality of Rx to continuously try to reconnect to the server.
For our SignalR usage (version 0.5.2), I’m using the exposed Hub functionality, not the persistent connections since I liked the encapsulation that Hub’s gave us. In the following example, we have a local member variable called
Connection which is a
HubConnection type created with this code.
HubConnection Connection = new HubConnection(Url);
HubConnection has a Start method that you use to initialize connections to … Read more