Hesam Seyed Mousavi, June 28, 2015
ASP.NET SignalR Architecture
As discussed in the last section, ASP.NET SignalR is a set of different libraries for different platforms. Although the server side of SignalR is bound to the .NET Framework or Mono (the open-source Linux implementation of the .NET Framework), the client libraries are very independent and can be implemented for any platform. At a high level, ASP.NET SignalR as a technology consists of a server implementation that serves a set of various types of clients hosted on different platforms.
With this background, when we talk about architecture, we refer to the architecture of the server side of ASP.NET SignalR because the general high-level architecture for the whole SignalR technology is a server-client architecture. Client libraries would not have a unified architecture per se, although all these clients need to have some kind of support for transports to connect to the server-side transports discussed later in this article. But the server side of the SignalR library consists of a stacked architecture that uses one of the four common transport options discussed in the next section. Depending on the network infrastructure and availability, one of these four transports is used in order of priority. If hub APIs are used, they are the points of connection for clients to simplify the logic and call the underlying persistent connection APIs in SignalR.
If persistent connection APIs are used directly, developers need to take care of receiving the raw data from clients and extracting metadata to respond to these requests.
With this background, when we talk about architecture, we refer to the architecture of the server side of ASP.NET SignalR because the general high-level architecture for the whole SignalR technology is a server-client architecture. Client libraries would not have a unified architecture per se, although all these clients need to have some kind of support for transports to connect to the server-side transports discussed later in this article.
But the server side of the SignalR library consists of a stacked architecture that uses one of the four common transport options discussed in the next section. Depending on the network infrastructure and availability, one of these four transports is used in order of priority. If hub APIs are used, they are the points of connection for clients to simplify the logic and call the underlying persistent connection APIs in SignalR. If persistent connection APIs are used directly, developers need to take care of receiving the raw data from clients and extracting metadata to respond to these requests.
What Is ASP.NET SignalR?
So what is ASP.NET SignalR after all? Actually, it is nothing but a library on top of the .NET Framework and jQuery (or other client-side technologies). In other words, ASP.NET SignalR is work done by some developers to facilitate a job to create real–time web applications by providing application programming interfaces (APIs) that are ready to be used out of the box.
You can write your own implementation for real–time web development on top of the .NET Framework based on your needs and call it SignalR Prime, KeyvanR, or APressR, but SignalR is a mature library that is designed to address almost any common scenario in real–time web development. Therefore, it is more economical, efficient, and risk free to apply SignalR for your real–time web applications than it is to reinvent the wheel.
With SignalR, you can build real–time web applications that consist of server and client sides. ASP.NET SignalR provides both parts out of the box by offering libraries that can be integrated into your projects.
SignalR comes with three main characteristics:
- SignalR is flexible: It provides different layers of tools to allow developers to build their custom applications. On one hand, ASP.NET SignalR offers hubs, which are a simple and quick way to build a real–time web application and hide some of the details to facilitate the job of web developers. On the other hand, persistent connections are a more fundamental tool for building applications that give more flexibility and power to developers, yet require more effort to handle certain things that are taken care of by hubs.
- SignalR is extensible: Many components in ASP.NET SignalR are designed to be easily replaced by a custom implementation if necessary. ASP.NET SignalR has integrated dependency injection into its internal structure to offer such a good level of extensibility. You usually do not need to replace these components, but it is a straightforward task if you do.
- SignalR is scalable: ASP.NET SignalR provides some built-in mechanisms to enable web developers to scale it up and out easily. Hosting a SignalR server application on multiple servers can introduce a set of common challenges, but these challenges are addressed by providing a set of extensible features in SignalR.
Besides these main characteristics, ASP.NET SignalR provides a set of features for common problems that might show up for any Microsoft ASP.NET developer. SignalR offers a good set of debugging and tracing features. Likewise, SignalR is easy to configure and secure to use. Cloud hosting is a hot topic in today’s software, and Windows Azure is the popular option for Microsoft developers for cloud hosting.
Main Challenges for Real–Time Web Development
HTTP is a stateless protocol that does not provide any callback mechanism for servers and clients. This is the main challenge for real–time web development when we want to push information from servers to clients whenever it arrives. Most efforts of building real–time web development frameworks are dedicated to tackling this challenge. To solve this problem, different techniques are used to put the content from server(s) on client(s).
These techniques can be categorized into two groups:
- Traditional approaches: Rely mostly on using hacks and tricks to achieve this goal. These approaches are built based on the concept of long-held HTTP connections between servers and clients that are also known as Comet.
- Modern approaches: Rely on new features introduced in HTML5. Four transport options that fall into these two categories are discussed in the next section: long polling, forever frame, server-sent events, and WebSockets. The other related challenge for real–time web development is the resource use caused by traditional approaches (i.e., Comet) because long-held HTTP connections can drain the battery power on mobile devices and consume other resources on the client and server. Therefore, the implementations of Comet approaches are critical for maximum efficiency.
Although such a challenge exists for traditional Comet approaches, newer approaches based on HTML5 also have limitations with the current state of the Internet. For example, the use of WebSockets is dependent on hardware and software support between client and server. So the whole network infrastructure between client and server must support WebSockets, and the software infrastructure in the hosting operating system must also support them at the same time. Currently, WebSockets is a supported feature only in Windows Server 2012.
The last challenge for real–time web development is to implement hard real time. Assuming that all these challenges are resolved, content from server to client has to be delivered in a very short period of time (usually less than 1 second) to imply a real-time behavior. Such a constraint mandates developers to build lightweight and efficient implementations.
As discussed in the previous sections, ASP.NET SignalR relies on transport layers to make communication possible between client(s) and server(s). These four transport layers are categorized in two groups: Comet approaches and modern HTML5 approaches. Each transport option is discussed in turn, followed by a discussion of how SignalR implements these transport layers.
Long polling follows this simple model and reduces the overhead of opening several connections to servers that could be introduced by an interval polling approach. Interval polling is the traditional approach in which the server is checked at regular intervals (e.g., every 10 seconds) for new content. This approach is not efficient; opening and closing HTTP connections to web servers create overhead. Long polling tries to reduce this overhead.
This approach is a modern HTML5 transport that enables web browsers to receive events from servers through an HTTP connection.
The main limitation of server-sent events (like any other approach based on HTML5) is browser support. Although the most recent versions of common browsers support server-sent events, Internet Explorer does not support them, which leaves a big gap for those interested in using these events for real–time web development.
The other HTML5 approach that has better browser support is WebSockets, which provides two-way communication channels over a TCP connection. WebSockets is not limited to HTTP, although it can also be used in that context. The use of WebSockets is dependent on the support by the underlying operating system (among Microsoft server technologies, only Windows Server 2012 supports them, although it is also available on Windows 8 and 8.1) and the whole network infrastructure between the client and server. Of course, browser support is also needed to take advantage of WebSockets, and recent versions of most common web browsers support it.
How ASP.NET SignalR Uses Transports
- Server-sent event
- Forever Frame
- Long polling