1

According to the wisdom of StackOverflow, there's no way to list or check the number of connected clients. However, the reply is a bit aged and I wonder if it's still valid.

Is it the only option for the server to log all connections and disconnections? Is there at least some functionality that helps us with detecting disconnections?

Community
  • 1
  • 1
Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438

1 Answers1

3

Absolutely there is a way.

A lot of people handle this by creating a singleton class that contains a concurrent dictionary of any custom user object you define. If you add your custom user objects to this dictionary on connection and remove them on disconnection, you'll be able to query your dictionary for a count of active users. Please keep in mind that it may not be up to the second accurate, because there is roughly a 30 second "abort" window that may still be active, even if the client no longer is because they closed their browser.

Now, is there any real "hardbaked" functionality in SignalR to do this for you? Not that I'm aware, but I haven't looked into 2.0 too exhaustively yet. As for detecting disconnections, it is fairly robust and if a connection is not detected, it will remove the connection as mentioned, allowing you to keep on top of the disconnections.

There is an excellent tutorial describing this approach here:

http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/tutorial-server-broadcast-with-signalr-20

David L
  • 32,885
  • 8
  • 62
  • 93
  • So more or less the way described in the link I've shown, right? I guess it suffice. But I was hoping for something more robust. Is there a recommended, specialized class for handling the clients or should is preferable to write one myself? – Konrad Viltersten May 20 '14 at 20:09
  • Unfortunately yes, all of my own research has never revealed any built-in tool that could be utilized directly from the library. The tutorial I linked is probably one of the more standard approaches, utilizing a singleton pattern to preserve your dictionary instance. I've used it myself in production and it holds up quite well. The ConcurrentDictionary keeps things threadsafe as well – David L May 20 '14 at 20:40