An application that combines Internet, asynchrony, and multiple users cooperating and interacting at the same time always deserves a “wow!”. At some point, we have all doubtlessly been amazed by the interactivity that some modern web systems can offer, such as Facebook, Twitter, Gmail, Google Docs, Office Web Apps, or many others, where we receive updates almost in real time without having to reload the page.

For example, when we are editing a document online using Office Web Apps and another user also accesses it, we can see that they have entered the document and follow the changes that they are making. Even in a more everyday scenario such as a simple web chat, the messages being typed by our friend just appear, as if by magic. Both systems use the same type of solution: asynchronous data transfer between the server and the clients in real time.

We developers who have had some experience in the world of the web are accustomed to the traditional approach proposed by the protocols that govern this environment—that is, the client is the active agent who makes requests asking for information, and the server merely answers. This is a probable reason for why we are so excited at the prospect of applications where the client side is directly updated by the server—for example, due to a new user having entered to edit the document or because our chat room buddy has written a new message in the chat. Pure magic.

The world is undoubtedly demanding this immediacy: users need to know right away what is happening in their environment, the documents they are working on, their social networks, their online games, and an increasing number of areas of their daily life. Instead of having to seek information as they used to do just a few years ago, now they want the information to come to them as soon as it is generated.

These needs have been evident at web protocol level for some time, because the long-standing HTTP, as defined in its day, cannot meet them efficiently. In fact, the organizations that define web standards and protocols, and also browser developers, are aware of this and have been working for years on new mechanisms for communication between the client and the server in opposite direction to the conventional one—that is, allowing the server to take the initiative in communications.

This has materialized into new protocols that can be used with a degree of reliability, although they are still rather far from universal solutions. The great diversity of client and server platforms, and even of network infrastructures, makes the adoption of these new mechanisms difficult and slow. Later on, we will delve in detail into these aspects.

However, these are not the only issues that have to be addressed when developing real-time multiuser applications. Communications, as we know, constitute unstable and unpredictable variables, which make management and distribution of messages to users quite complicated. For example, in a chat room application, we could have users with very different bandwidths connected to the same room, and those bandwidths might even fluctuate throughout the chat session. To prevent the loss of messages in this scenario, the server should be capable of storing them temporarily, sending them to their recipients, and monitoring which users have received them already, always taking into account the conditions of communication with each user and the potential breakdowns that might occur during delivery, sending data again if necessary. In a sense, this is very similar to the features that we can find in traditional SMTP servers, but with the added requirement of the immediacy needed by real-time systems. It is easy to picture the complexity and difficulty associated with the implementation of a system such as the one described.

Until recently, there was no component or framework in the area of .NET technologies provided by Microsoft that was capable of providing a complete solution to the problems of implementing this type of application. Certainly, there are many technologies capable of offering connected and disconnected services, such as the familiar Web Services, WCF, or the more recent Web API. However, none of them was specifically designed for asynchronous environments with real-time collaboration between multiple users. In fact, although it was possible to create this type of system with such platforms, it was not a trivial task even for the most experienced developers, and it frequently produced very inefficient systems with many performance problems and limited scalability.

Throughout these pages, we will learn how to implement impressive features of this kind using SignalR, a remarkable framework—powerful, flexible, and scalable—which will facilitate our task to the point of making it trivial.

For this purpose, we will first present a brief review of the problems that we find when developing real-time multiuser applications, some of which we have already mentioned. We will quickly look at HTTP operation and its limitations for supporting these types of systems, and we will introduce the push concept. We will also describe the standards that are currently in the process of being defined by W3C and IETF, as well as techniques that we can currently use for implementing push on HTTP. This will allow us to achieve a deep understanding of the scenario in which we are working and the challenges surrounding the development of applications boasting the immediacy and interactivity that we have described. In turn, this will help us gain a better understanding of how SignalR works and the basis on which it rests.

Next, we will formally introduce SignalR, describing its main features, its position within the stack of Microsoft technologies for web development, and the different levels of abstraction that it allows over the underlying protocols and which will help us remain separated from lower-level details so that we can just focus on creating spectacular features for our users. We will also take this chance to speak about OWIN and Katana, two new agents which are becoming increasingly prominent in various technologies, SignalR included.

We will study in depth the various techniques and abstractions provided by this framework to create interactive multiuser real-time applications, both on the client and server sides, and we will learn to make use of their power and flexibility. Naturally, for this we will provide different code examples that will help us understand its basis in a practical way and thus illustrate how we can use this framework in real-life projects.

We will also describe how SignalR is independent of web environments: although they might seem to constitute its natural environment, this framework goes far beyond them, allowing the provision of real-time services from any type of application and, likewise, their consumption from practically any type of system. We will see several examples of this.

Another aspect of great importance, to which we will devote several pages, is reviewing the deployment and scalability of SignalR applications. We will study the “out-of-the-box” tools that come with this platform and point to other possible solutions when addressing scenarios where such tools are not powerful enough. Additionally, we will look at different techniques designed to monitor the status of our servers and improve their performance in high-concurrency environments.

Finally, we will go into advanced aspects of programming with SignalR, which will give us deeper insight as to how the framework works, including security, creating decoupled components using dependency injection, SignalR extensibility, unit testing, and other aspects of interest.

Welcome to multiuser real-time asynchronous applications. Welcome to SignalR!