All communication between clients/servers and dashboards are done via SignalR. Understanding SignalR is therefore key in understanding how StifleR works.
A single StifleR server is designed to support at least a 100k clients. The real number of course is dependant on hardware limits. See the hardware requirements.
ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.
ASP.NET SignalR is a library for ASP.NET developers that simplifies the process of adding real-time web functionality to applications. Real-time web functionality is the ability to have server code push content to connected clients instantly as it becomes available, rather than having the server wait for a client to request new data.
SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. While chat is often used as an example, you can do a whole lot more. Any time a user refreshes a web page to see new data, or the page implements long polling to retrieve new data, it is a candidate for using SignalR. Examples include dashboards and monitoring applications, collaborative applications (such as simultaneous editing of documents), job progress updates, and real-time forms.
SignalR also enables completely new types of web applications that require high frequency updates from the server, for example, real-time gaming.
For a great example of this, see the ShootR game.
SignalR handles connection management automatically, and lets you broadcast messages to all connected clients simultaneously, like a chat room. You can also send messages to specific clients. The connection between the client and server is persistent, unlike a classic HTTP connection, which is re-established for each communication.
SignalR supports "server push" functionality, in which server code can call out to client code in the browser using Remote Procedure Calls (RPC), rather than the request-response model common on the web today.
SignalR applications can scale out to thousands of clients using Service Bus, SQL Server or Redis.
SignalR is open-source, accessible through GitHub.
SignalR uses the new WebSocket transport where available, and falls back to older transports where necessary. While you could certainly write your application using WebSocket directly, using SignalR means that a lot of the extra functionality you would need to implement will already have been done for you. Most importantly, this means that you can code your application to take advantage of WebSocket without having to worry about creating a separate code path for older clients. SignalR also shields you from having to worry about updates to WebSocket, since SignalR will continue to be updated to support changes in the underlying transport, providing your application a consistent interface across versions of WebSocket.
While you could certainly create a solution using WebSocket alone, SignalR provides all of the functionality you would need to write yourself, such as fallback to other transports and revising your application for updates to WebSocket implementations.
SignalR is an abstraction over some of the transports that are required to do real-time work between client and server. A SignalR connection starts as HTTP, and is then promoted to a WebSocket connection if it is available. WebSocket is the ideal transport for SignalR, since it makes the most efficient use of server memory, has the lowest latency, and has the most underlying features (such as full duplex communication between client and server), but it also has the most stringent requirements: WebSocket requires the server to be using Windows Server 2012 or Windows 8, and .NET Framework 4.5. If these requirements are not met, SignalR will attempt to use other transports to make its connections.
These transports depend on support for HTML 5. If the client browser does not support the HTML 5 standard, older transports will be used.
The following transports are based on the Comet web application model, in which a browser or other client maintains a long-held HTTP request, which the server can use to push data to the client without the client specifically requesting it.
For more information on what transports are supported under which configurations, see Supported Platforms.
Just to understand a little bit the power of websockets, wbesocket.org did an experiment, and for one use case, there were 100, 000 clients polling through http requests every one second, the total network throughput was 665 Mb per second. When the same number of clients was receiving one message from the server every second through websockets, the total network throughput was 1.526 Mb per second! Pretty amazing, you can find the link here: http://www.websocket.org/quantum.html.
Following is a figure from the same link representing a "comparison of the unnecessary network throughput overhead between the polling and the WebSocket applications":
In the sample built by Microsoft, the server will broadcast the updates of each stock one at a time, we will do it in a list, that is the server will broadcast the whole list of stocks updated, and the clients will digest these updates. We will also change the color of the stocks updated according to their change.
The same scalability rules applies to StifleR, and this give you an idea of why we build StifleR on SignalR. The R in StifleR is to honor the awesomeness in SignalR.