Today I’d like to give you an overview of a new ASP.NET technology called SignalR, a library for creating real-time communication between servers and web browsers.
SignalR is an abstraction over the new WebSocket transport. WebSocket is a very powerful, efficient system for sending messages between web browsers and servers. There are two issues with using WebSocket that SignalR was created to address:
- WebSocket is a low-level transport that is very cumbersome to use directly. SignalR reduces the complexity of WebSocket to the point that a connection can be opened and used with just a few lines of code.
- WebSocket has very stringent system requirements. Like being the first of your friends to own a telephone, you have access to a powerful communication tool, but you’ll have to wait for your friends to get one before you can call them. WebSockets requires Windows 8 and .NET Framework 4.5. If WebSocket isn’t available for a connection, SignalR will fail over to other transports, namely Server- Sent Events, Forever Frame, and AJAX Long Polling. I’ll be talking about the four transports that SignalR supports in a later post.
In addition to providing a simple way to access WebSockets, SignalR offers two ways for a server and a client to communicate:
- Connections: The low-level Connections API uses a Messaging model, in which individual messages are sent between clients and servers, which are then processed and acted upon. The Connections API will be familiar to developers who have used messaging APIs like DirectPlay.
- Hubs: The high-level Hubs API uses a Marshalling model, in which servers and clients call methods on each other directly using proxies and endpoints. The Hubs API will be familiar to developers who have used remote method invocation systems like .NET Remoting.
To get started with SignalR, visit the SignalR website at http://www.asp.net/signalr.