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:
Thanks
With at least 30 GiB RAM you can handle 1 million concurrent sockets.
SignalR uses Web socket technology to send data. WebSocket is a new HTML5 API that enables bidirectional communication between the browser and server but if it is not available then SignalR can use other technologies like long polling.
The default keepalive timeout period is currently 20 seconds. If your client code tries to call a Hub method while SignalR is in reconnecting mode, SignalR will try to send the command. Most of the time, such attempts will fail, but in some circumstances they might succeed.
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 :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With