Pro ASP.NET SignalR: Real-Time Communication in .NET with SignalR 2.1 (2014)
Chapter 1. Introduction to the Real-Time Web and ASP.NET SignalR
The Internet is one of the most important inventions in history, and it has changed our lives for the better in many ways. For social creatures such as humans, nothing could be better than a fast method of communication with the world that enables multimedia content delivery with almost no delay.
In its few decades of existence, the Internet has evolved from a basic set of network clusters with simple operations to the foundation of almost everything in our world, providing opportunities to make billions of dollars.
Our mission in this book is to walk you (and other Microsoft web developers with a good background in ASP.NET and JavaScript) through a very recent technology called ASP.NET SignalR. It enables the creation of real-time, asynchronous web applications that are the most modern type of infrastructure for building sites to deliver content from servers to clients in real time and remove any latency. Clients sit on a page on your site and receive the newest updates in real time with no need to click anything or refresh the page. For example, on Facebook when somebody leaves a comment or likes one of your photos, you do not need to refresh the page to see the notification pop up and the red counter being updated. ASP.NET SignalR provides the foundation to develop such features.
This chapter gives you some background information on SignalR and how it can help you build modern web sites. The following are the major topics covered in this chapter:
· How the Internet has evolved to where it is today
· Why client-side experience is more important than ever
· Definition of real–time web application development
· Some examples of real–time web application development
· Historical overview of ASP.NET SignalR
· Introduction to ASP.NET SignalR and some of its characteristics
· ASP.NET SignalR architecture
· Overview of different transport options in ASP.NET SignalR
· Main challenges for real–time web development
Evolution of the Internet
The Internet started as a simple set of clusters with some computers connected to perform basic operations. It quickly became a very sophisticated network of servers all around the world that serve hundreds of millions (even billions) of clients.
There have been different kinds of changes on this worldwide network in different domains. In one area, Internet connections became faster and more reliable, enabling users to download and upload larger content so that it is now possible for users to download and upload high–quality multimedia content (e.g., videos) from their mobile Internet connections. It has also opened new doors for content providers and consumers.
In another area, Internet browsers evolved to be very sophisticated, and enabled features to facilitate the creation and delivery of content in more user-friendly ways. For at least a decade, the use of Asynchronous JavaScript and XML (AJAX) technologies has given a smoother user experience to end users, for example.
In a third area, server technologies have evolved to also accommodate browser and connection advancements. New programming languages and platforms have been introduced, along with many libraries that help simplify the process of web application creation for web developers. One of these recent advancements is the support for WebSockets.
All the different trends on the Internet focused on providing a better user experience. We have moved from serving static HTML web pages to dynamic pages that can be updated based on users’ actions. We can then use client-side languages (mostly JavaScript) to process certain things on the browser and reduce the need to refresh a web page to get the new content. Currently, there is a more modern approach: real-time delivery of content from servers to clients that is possible by applying server-side technologies in conjunction with JavaScript. This is the area in which SignalR comes into play.
Why the Client-Side Experience Is More Important than Ever
The concept of user has become the most important concept in today’s Internet. Almost all businesses, regardless of their size, know how important the user experience can be. They have moved their focus to making products, technologies, and software that is intuitive and simple enough to attract almost any user regardless of age, gender, cultural background, and so on.
An important part of the user experience is the speed of delivering content. Traditionally, the Internet was a set of web pages served on servers and received by clients. These pages included many static pages that could not react dynamically to users’ actions and dynamic pages that could render a dynamic content based on the inputs provided by users. Users had to send their actions to servers or request a particular Uniform Resource Locator (URL) from the server to receive HTML content. This was a very simple model and lacked the sophistication seen in modern web sites.
As the user experience became more important, web designers and developers came up with the idea of using JavaScript and XML in conjunction with partial content rendering on the servers to take advantage of the concept of AJAX. It would provide a smoother experience to users and deliver content to these users more quickly.
In the past few years, however, this approach wasn’t good enough for the modern needs of the Internet. Even with AJAX, there was often a wait for users’ actions to update a portion of the page and deliver the content, so the speed of content delivery was very dependent on the speed of the users’ interactions.
This issue led web developers and designers to start thinking about sending the content from servers to clients as it arrives in real time, or at least invent mechanisms that simulate such a behavior. This process is called real–time web application development.
Real–Time Web Application Development
The term real-time software refers to the type of software that is subject to a soft or hard time constraint. By the nature of its business domain, this type of software must complete its processing within a particular timeframe. This time constraint can be strict to make it hard real-time software or flexible to make it soft real-time software. For example, aerospace software can be hard real-time software because it must finish its execution within a defined time interval; otherwise, operations might fail, and people’s lives can be in danger. In contrast, video players can be soft real-time software because it is not mission-critical if the processing does not finish on time (although it is important to process the videos in time to display them to users).
Although real-time software and real-time computing have been around for a long time, the term real-time web is relatively new. This concept, which was introduced in the past few years, focuses on real-time delivery of content to clients as soon as it is available.
The real-time web is similar to soft real-time software because the delivery of content from the information source to consumers should occur in a short period of time to be considered real time (from a few milliseconds up to 1 second).
The real-time web was embraced by social networks and their need to update users with frequent status updates and content changes by friends and peers. Facebook and Twitter were among the first major sites on the Internet that pioneered in this area and implemented real-time web features.
Although the real-time web is primarily applied to soft and small updates to clients with short status updates, news headlines, and similar content, it is now also used for other purposes, such as real-time searching (more details to come in the next section). Google incorporated such features to provide real-time updates to its search results as they become available.
Examples of Real–Time Web Application Development
This section focuses on showcasing a few common examples of the real-time web to describe it and the applications it can have. One common misbelief about real–time web development technologies including SignalR is that they are designed mainly for building chat applications. The examples shown here correct this by describing different practical applications for these technologies.
The real–time notification feature on Facebook (see Figure 1-1) is one of the best examples of the real-time web, and Facebook is a pioneer in this area. If you have a Facebook account, you have noticed the red color counter of new notifications being increased in real time while a toast appears in the bottom-left corner of new actions.
Figure 1-1. Facebook’s use of the real-time web
Whenever there is a new like, comment, post, or other type of notification associated with your account, you see a notification toast in the bottom that appears and disappears after a few seconds. At the same time, the counter of new notifications in red is updated.
Facebook is using a combination of WebSockets and long polling to implement this feature. (These approaches are discussed in more detail later in this chapter.)
Note that Facebook uses a similar asynchronous mechanism to implement its chat system (in fact, Facebook chat and real-time notifications were rolled out together in early 2008). Facebook later enhanced its real-time features to include real-time updates to different parts of the site, such as new comments added to posts that appear in real time to users.
Such a sophisticated and reliable real–time web implementation for Facebook has an important value for its business. With the large number of users and high demand for the huge content provided by hundreds of millions of active users, the user experience is significantly improved by integrating such a real–time web ecosystem.
Technology-wise, Facebook has employed a very sophisticated custom implementation to achieve its unique business goals for the real-time web that relies on pushing the content from servers to clients. Facebook had to consider several factors, such as the large number of active publishers as well as consumers, along with keeping its data centers in sync and reducing the latency for users who are scattered throughout the world.
Another popular social network using quick status updates is Twitter, which receives frequent updates from its users. Each user can then have many followers who want the most recent updates from that user and other users they are following. The speed of delivering these short status updates to clients is of vital importance for Twitter’s business because it can improve the user experience significantly. Just imagine how frustrated Twitter users would be if they had to refresh their Twitter feed every time they wanted a new update.
Twitter employs a real–time web infrastructure to display the most recent updates to users in real time (see Figure 1-2). This implementation is Twitter’s custom implementation that fits its needs. As new updates arrive in the user’s feed or search results, the user interface is updated with the counter of new updates that ask the user to click the counter link to fetch the most recent updates with an AJAX call (rather than refreshing the whole page).
Figure 1-2. Twitter’s use of the real-time web
Google Search
With the very fast pace of content production on the Internet, especially for trending topics, new articles and news items become available very quickly. Google uses its powerful indexing tools to capture these updates quickly. With the traditional user interface structure, after a user searched for a particular keyword, the results were presented from the original state of content repository in the Google database. To provide a better user experience, Google offered real–time search result updates in which search results were updated as new items became available, and users could see the most recent items.
Although Google was using its own real–time web implementation for real–time search results, it closed this feature in 2011 because the deal with Twitter expired for displaying the latest tweets in real time.
Google Docs
Another great example of the power of the real-time web and its impact is Google Docs, in which users have access to an online version of document-editing software for word processing, spreadsheets, and slides. Not only can users edit their own documents with the great features provided but they also can share their documents with others. The real power of the real-time web shines here: the updates made by one user are reflected in other users’ displays in real time, so multiple parties from different locations are allowed to collaborate on writing and editing documents (seeFigure 1-3).
Figure 1-3. Google Docs relies on the real-time web for its unique collaboration features
Google Docs is a good example of how the real-time web can change the game for Internet web sites. Google Docs uses a custom and sophisticated Google implementation to achieve its goals. It treats documents as a collection of change sets instead of the traditional monolithic view. Google engineers can distribute these change sets to individual users in real time.
JabbR
Now that you have seen some famous examples of the real-time web, you should also know about some ASP.NET SignalR examples. One of the best known SignalR web sites on the Internet is JabbR (see Figure 1-4). This online chat room and discussion service is implemented by the same developers as those who founded SignalR. It has become a very prominent location for software developers to host their group chats and discuss various topics, such as live coverage of their opinions on developer conferences and similar events.
Figure 1-4. JabbR is a prominent SignalR chatroom application
JabbR, which is available at http://jabbr.net, is fully implemented with the Microsoft stack of technologies, including ASP.NET MVC and ASP.NET SignalR. The good news is that it is an open-source project, and its source code is available on GitHub athttp://github.com/JabbR. Developers contribute to this project on a daily basis to make it more mature.
JabbR employs a modern and responsive web design to render well on all the desktop and mobile devices, and it can be hosted on its own or in the cloud on Windows Azure or AppHarbor.
JabbR uses SignalR to deliver the chat and related multimedia content from servers to clients in real time. The chat system’s application is the most basic and common example of the real-time web that can be mistakenly treated as the only application of the real-time web. In fact, if you perform a quick search on Google or Bing for ASP.NET SignalR examples, the majority of results are chat applications. This book even uses some chat application examples because they are a good and way to illustrate the concepts of the real-time web and ASP.NET SignalR.
ShootR
We conclude our examples with another ASP.NET SignalR web site that is a little different from other examples because it is an online collaborative game. ShootR (shown in Figure 1-5) is the name of an online game available at http://shootr.signalr.net. It is an open-source project; its source code is available on GitHub as well (https://github.com/ntaylormullen/shootr).
Figure 1-5. ShootR is an online spaceship game powered by ASP.NET SignalR
ShootR uses modern HTML, CSS, and JavaScript elements with ASP.NET SignalR to provide a real–time spaceship game. The role of ASP.NET SignalR is to deliver the location and status of the game canvas for the automated computer user and other human users’ spaceships to the current player (and other players) in real time. Reliable delivery of content and a good experience for game players are the goals of this game.
History of ASP.NET SignalR
There was an increasing need for real–time web development features for web developers, especially Microsoft ASP.NET developers. Damian Edwards (a program manager on the Microsoft ASP.NET team) was motivated to build a solution for this common problem on Microsoft technologies. SignalR was the answer that started as an open-source project and attracted some other developers as well. Later on, David Fowler (software developer on the Microsoft ASP.NET team) took a serious role in developing this project and has continued to do so.
Although SignalR started as an open-source project, it had good community support from Microsoft, and this support was completed when Microsoft decided to bundle this open-source project as part of its ASP.NET stack and call it ASP.NET SignalR.
ASP.NET SignalR is still truly open source and is licensed under an Apache 2.0 license. You can download the source code for ASP.NET SignalR from GitHub at http://github.com/SignalR/SignalR and also contribute to this project. ASP.NET SignalR also has its own official home page on the Microsoft ASP.NET web site at http://www.asp.net/signalr. Like many other libraries and products available to Microsoft developers, ASP.NET SignalR is also available through NuGet athttp://nuget.org/packages/Microsoft.AspNet.SignalR.
SignalR has had a very active life in its short existence, and several minor and major versions have been released. Version 2.1 is now available, and this book is based on it. ASP.NET SignalR has matured significantly in these versions and is now in a very stable and practical state.
With each release, ASP.NET SignalR has been through major and minor changes in features as well as bug fixes and better integration with latest additions to the .NET Framework, resulting in progressive integration with OWIN and a better error-handling and diagnosis mechanism. One of the most useful major changes in versions 2.x is the capability to target a particular user for sending messages to clients.
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.
Although its name might imply that SignalR is available only in the context of web applications, you can self-host SignalR servers and consume the server data in the context of a Windows desktop application or a native mobile application (as discussed later). However, most people use SignalR in the context of web applications, and that topic is the focus of most chapters of this book. (Chapter 6 is dedicated to using SignalR outside the web context for different types of clients.) The good news is that the client-side uses of server components in ASP.NET SignalR are very similar to each other, so knowing the JavaScript concepts makes it relatively easy to adopt any other type of client.
To summarize, ASP.NET SignalR is a set of libraries for the .NET Framework, JavaScript/jQuery, iOS, and other platforms. It provides server and client implementations for building real–time web applications. SignalR simplifies real-time development by hiding implementation details and the supporting infrastructure. It is also efficient and extensible, ready to be used for a wide range of applications in industry and enterprise.
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 (see Chapter 3), 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 (see Chapter 4) 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 (see Chapter 7).
· 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 (see Chapter 8).
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 (see Chapter 5). Likewise, SignalR is easy to configure and secure to use (see Chapter 8). Cloud hosting is a hot topic in today’s software, and Windows Azure is the popular option for Microsoft developers for cloud hosting (see Chapter 10).
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 (see Figure 1-6).
Figure 1-6. High-level view of ASP.NET SignalR as a technology
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 chapter.
But the server side of the SignalR library consists of a stacked architecture (Figure 1-7) 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.
Figure 1-7. ASP.NET SignalR server architecture
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.
Transport Options
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
This famous Comet approach is one of the most common ways to achieve real–time web development in today’s Internet. It relies on using JavaScript (or other technologies and techniques) to make a lightweight HTTP connection to a server and keep it open for a period of time (e.g., 30 seconds). In this interval, if new data becomes available on the server, it puts the data in the currently open HTTP connection and then closes it. The client receives this data and opens a new long poll connection immediately. If there is no data in that period of time, the client establishes a new long poll connection and continues this as long as the page is open and active in a web browser.
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.
Forever Frame
Another Comet approach that is less common than long polling is Forever Frame (also known as hidden iframe), which is an approach specific to Internet Explorer. In this approach, a hidden iframe element is attached to each web page that is kept open for the whole duration of the request (the period of time that a user stays on the page). As data becomes available on the server, it is filled with JavaScript codes in a stacked manner, and because browsers execute these scripts in order, they can provide the desired behavior needed.
Server-Sent Event
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.
WebSockets
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
The ASP.NET SignalR JavaScript library has a built-in mechanism that switches between approaches in priority based on their availability. Unless you specify one or more transport options to be used, the following order of options is considered:
1. WebSockets
2. Server-sent event
3. Forever Frame
4. Long polling
Summary
This chapter was a quick introduction to real–time web development and SignalR. You saw how SignalR fits into the big picture of rich user experience and real-time applications in general, and you had a brief look at its architecture and the challenges it faces.
In the next chapter, you get your feet wet by implementing a basic example with ASP.NET SignalR to become familiar with fundamental concepts and the development process.