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 literature on IIS/ASP.NET regarding "concurrent Websocket connections" and how to tweak the various values - 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?
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?
It seems SignalR hubs are probably overkill, I don't need fallbacks for clients that dont support websockets and I only need to maintain a handle on the each clients connection, such that when my system "decides" to send a message to a particular client, it can route it appropriately.
Docs I'm referencing:
- https://github.com/SignalR/SignalR/wiki/Performance
- http://www.asp.net/signalr/overview/performance/scaleout-in-signalr
Thanks
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 :)
