It has been quite a while since the release of ASP.NET SignalR. Even during its beta version, this amazing open-source technology attracted a large number of geeks who wanted to test it. But now that SignalR is part of the ASP.NET family, it has become even bigger and better. In this article, which is the first in a SignalR series, I provide an overview of SignalR and its communication protocols.
Related: SignalR in ASP.NET Applications
ASP.NET SignalR is a communication framework that lets developers create applications that provide real-time information. (The Chat application and the StockTicker app are the most common examples.) SignalR is based on the famous server push or push technology. As soon as any information or updates are available on the server, the information is pushed to the connected clients—which makes the operation appear to take place in real time. SignalR not only covers web applications but also caters to applications such as Windows Phone apps, Windows 8/Store/Desktop apps, Console applications, and more.
To install SignalR, you can use NuGet or the Package Manager Console. SignalR is available in packages that let you install components per your organization's requirements. For more information about SignalR packages, see the SignalR Package Overview page on GitHub.
Communication Protocols
Before we dig further into SignalR and its communication protocols, let's shift our focus to some techniques that were used prior to SignalR. Two of the most common and famous technologies are Comet and WebSockets—which is actually one of SignalR's communication protocols.
Comet. The technology behind Comet came into existence in the early 2000s. It's used to push data from the server to the client by opening a single persistent connection between them. Internally, Comet uses hidden iframes (also known as forever frames) or the XMLHttpRequest (XHR) object to send data.
The biggest drawback of Comet is that it must open a persistent connection for a long period of time. Keeping a connection open for a long period of time introduces high latency issues. In addition, Comet uses two HTTP connections for bi-directional communication. Handling those two connections can be a burden for a developer.
WebSockets. WebSockets was introduced in HTML5 and is one of the best communication protocols. Its technique of using a single (full-duplex) bi-directional connection to both pull and push data makes it more reliable than Comet. However, WebSockets does have its drawbacks. Although it's one of the best and fastest protocols for fetching real-time updates, it doesn't support all clients—most notably, Internet Explorer.
Benefits of SignalR
The beauty of SignalR is that it's built on top of communication protocols, which provides an abstraction layer over its transport techniques. This abstraction layer helps developers focus on the business logic rather than spend time building communication logic. Internally, SignalR uses four different communication protocols and gradually reverts to the one that's best suited to its connected client.
SignalR's supported communication protocols include WebSockets, server sent events, forever frames, and long polling.
- WebSockets. SignalR uses the WebSockets protocol as its first approach for communication because it's the best way to fetch real-time updates. The full-duplex persistent connection results in less overhead to manage the connection; in addition, data transfers at a faster rate. However, Internet Explorer doesn't support this protocol.
- Server sent events. If the client doesn't accept WebSockets, SignalR uses server sent events as a secondary approach. This protocol uses a JavaScript API called EventSource to provide a one-way connection in which it sends data in a continuous stream to its connected clients. Like WebSockets, Internet Explorer doesn't support this protocol.
- Forever frames. The forever frames communication protocol uses iframes, which are hidden on the web page. As soon as the server sends any data (e.g., HTML elements, scripts), the iframes fill up with the data. This protocol is completely supported by all browsers, including Internet Explorer.
- Long polling. Long polling is the last approach that SignalR uses for communication. Unlike all the other protocols, this approach doesn't use a persistent connection. This technique uses polling, in which the client sends requests to the server at particular intervals. Long polling is supported by all types of clients.
SignalR uses these different protocols for communication, while focusing on the client's capabilities. In a subsequent article, I'll focus on hubs, persistent connection, scalability, and extensibility—with appropriate code samples.
