I have had the opportunity to work with SignalR over the last 6 months and I really like how easy it was to set up and get working. It has opened my eyes to a lot of possibilities for web projects. I’ll do my best to explain the technology as I’ve been exposed to it.
What is SignalR?
First, SignalR is open-source, accessible through GitHub (+10 cool points).
SignalR is a library for .NET developers that makes adding real-time web functionality to applications easy. Now you can 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. This will make your site seem more “alive.”
SignalR can be used to add any sort of “real-time” web functionality to your ASP.NET application. 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 (i.e. dashboards, monitoring applications, collaborative applications, job progress updates, and real-time forms).
SignalR provides a simple API for creating server-to-client remote procedure calls (RPC) that call JavaScript functions in client browsers (and other client platforms) from server-side .NET code. SignalR also includes API for connection management (for instance, connect and disconnect events), and grouping connections.
SignalR handles connection management for you. You can broadcast messages to all connected clients simultaneously or target specific clients. The connection between the client and server is persistent, unlike a classic HTTP connection, which is re-established for each communication.
SignalR uses (RPC) Remote Procedure Calls rather than request-response model to allow the server code to call out to client code in the browser.
SignalR applications can be scaled out to thousands of clients using Service Bus, SQL Server or Redis
SignalR and WebSocket
SignalR uses the new WebSocket transport if possible. By using SignalR instead of writing your own code for WebSocket directly you save a lot of time not reinventing the wheel, specifically when it comes to supporting older clients. SignalR will also continue to be updated to support changes with WebSocket, meaning less of your code to maintain.
Transports and Fallbacks
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).
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 HTML5. If the client browser does not support the HTML 5 standard, older transports will be used.
Some transports include WebSocket, Server Sent Events, Forever Frame and AJAX long polling.
If you are in an environment where the client capabilities are known then you can specify a transport. This will save time and resources vs automatically determining the correct transport.
The following would be an example of starting a connection specifying Long Polling Transport.
connection.start({ transport: 'longPolling' });
This following would be an example of starting a connection specifying a fallback order in case one is not supported.
connection.start({ transport: ['webSockets','longPolling'] });
Connections and Hubs
The SignalR API contains two models for communicating between clients and servers: Persistent Connections and Hubs.
A Connection represents a simple endpoint for sending messages. These messages could be sent to a single client, a group of clients or broadcast to all. The Persistent Connection API gives the developer access to the low-level communication protocol that SignalR exposes. Using the Connections communication model will be familiar to developers who have used connection-based APIs such as Windows Communication Foundation (WCF).
A Hub is more of a high-level object built on the Connection API that allows your client and server to call methods on each other directly. The Hub allows clients to call methods on the server as easily as local methods, and vice versa. Using the Hubs communication model should be a lot like .NET Remoting for those who have used it. Using a Hub also allows you to pass strongly typed parameters to methods, enabling model binding.
When server-side code calls a method on the client, a packet is sent across the active transport that contains the name and parameters of the method to be called. The client then matches the method name to methods defined in client-side code. If there is a match, the client method will be executed using the deserialized parameter data.
Summary
That’s SignalR in a nutshell, but there is so much more that could be discussed. If this interests you at all, check it out online as there are plenty of good examples and tutorials.
– Brad Trebilcock, asktheteam@keyholesoftware.com
