SignalR / Websockets connection limitations and best practices

Question

I\'m trying to understand how to best design an IIS/ASP.NET based websocket application, specifically regarding concurrency limitations.

I\'ve read all the literatur

Answer 1

however, when speaking about websockets, what is the definition of "concurrent"? If I have opened a websocket and its sitting idle, is that "using" a connection? Do idle websockets count towards connection usage totals, or does it only count when a message is being sent/received?

Right, a open connection sitting idle does not consume much resources beyond TCP keep-alives and maybe protocol and/or application level ping/pongs if your server supports them. More importantly, as Websockets are connection oriented you may be holding some state associated with the connection as well (an user object, user data, etc...)

I expect to have a very high (100s of thousands) number of websockets open at any one time, however there will be very few messages sent, perhaps a few per minute and they will always be server->client (and to a single, specific client, not a broadcast). Does/should this arrangement lead me down any particular implementation route?

Yes, to the route of not using SignalR: SignalR Scale-out (check the limitations section). Use WebSockets directly and implement your own messaging back-end with a framework that allows smart routing like RabbitMQ for example. You don´t want to use a backplane that is basically doing "fan-out" to all nodes, especially if the data is per user.

SignalR is a polyfill, a transient framework until the day WebSockets are broadly supported... and that already happened. Also forgot to mention that WebSockets are available from Windows server 2012 onwards :)