SignalR / Websockets connection limitations and best practices

19
votes

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

1
websocketsignalr
I'm pretty sure web sockets use a TCP/IP connection when idle - that's so they can push data back to the client. Can you provide a reference to the documentation about concurrent Websocket connections please? – Daniel James Bryars
What protocol will you use? UDP or TCP? – Thomas Wagenaar
@ThomasWagenaar Websockets are TCP only, aren't they? I wonder if WebRTC has any application here... – Andrew Bullock

1 Answers

13
votes

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 :)