The World Wide Web has been with us for the past 20 years and has become a fundamental part of our lives. Its distributed architecture has proven to be efficient and scalable. Thanks to it, nowadays, an incredible amount of information and services is available to all of us. We just have to connect, look for what we need, and pull it onto our devices to use it. However, it's also true that many scenarios would be more efficient if services themselves were able to determine the information that we need and then push it towards us at the right time. The contrast between these two ways of distributing content is clear and important, and according to the specific goals, there might be a clear advantage in using one or the other.

We already have several networking and application technologies that are ideal to build push systems, but the World Wide Web and its enabling protocol, HTTP, were not born for that. Traditional applications based on HTTP offer a request/response model where it's always the client's responsibility to initiate a connection, and it's always the client who has to ask the server for something. The server will send back the appropriate response on the same connection opened by the client to perform the request, and then, it will terminate the connection. According to this model, there is usually no natural way for the server to send any piece of information without a previous specific incoming request. Nevertheless, it would be a shame to miss the opportunity to leverage such a ubiquitous protocol in order to enable push scenarios for all its users.

This is how the Web has lately started to move towards enabling push scenarios, first with a series of technology tricks (Long Polling, Forever Frame, and Server-Sent Events) applied over the traditional HTTP/HTML stack, and then with the rise of a proper technology that introduces a way to establish persistent connections between clients and servers, which can then be used for fully bidirectional communications: WebSocket. Modern browsers and web servers bring full support to the latter option, while older systems can recur to the former tricks. So, now we have several ways to deliver a solution, but also the problem of having to decide which technology to use, or maybe the need to replicate our solution using all these techniques together to reach every potential user.

Enter SignalR! SignalR is a very interesting library that leverages all the strategies that we previously mentioned to deliver a real-time push platform. It enables a two-way communication model between the client and the server, and it achieves this goal simply by leveraging what HTTP and HTML5 have to offer. SignalR looks like magic because it transparently adapts itself to the available environment (the HTTP server and the web browser) and transforms a normally transient HTTP connection into a virtually persistent connection. The messaging API offered by SignalR succeeds in abstracting the low-level networking strategies, chosen according to what's supported by the involved counterparts, and offers us a simple and generic way to write code that remains unaware of the underlying complexity.

We briefly mentioned what SignalR does and how it does it, but the actual goal of this book is not to dig deep into the mechanics SignalR is built on top of. This is a practical, hands-on guide that provides you with a number of clear, step-by-step recipes that will gradually enable you to add SignalR as an innovative, effective, and useful item in your toolbox. It will move from simple examples down to complex use cases, going through a comprehensive overview of the library.

Although most of the recipes will give some information on how SignalR works behind the scenes to enable the proposed solution, these explanations shall not be too detailed. You should not expect otherwise from this book. The book will not go into deep architectural details. It will just provide you with a decent level of explanations to help the reader understand what is going on, while keeping the focus on bringing practical and synthetic solutions to specific questions.

In each recipe, we will be picking a problem and showing you a SignalR-based solution, or, if you prefer, we'll be choosing a specific feature from SignalR and matching it to the class of scenarios it helps tackle. This way you will gradually learn how to perform a set of common tasks, which the last chapter will combine to build complex applications.

At the time of writing this book, SignalR reached Version 2, and this is the one that we'll be using for our discussion. If you need to use Version 1, this book could still be used as a general reference. However, there are some differences that you would have to take care of, especially in areas related to hosting and bootstrapping a SignalR-based application. That said, these differences will not be treated throughout the text, and no particular attention will be paid to the older version.

You might also have to pay attention to the fast evolution of the minor version number of SignalR and of all its dependencies. SignalR is available on NuGet. It's constantly updated, and the same happens to the components that it depends on, such as jQuery or Newtonsoft. Json. This means that the actual version numbers that you might reference while writing your code are likely to be different from the ones you will find listed here. The recipes have been constantly revised, and have been updated to what's available at the time of the final technical reviews (February, 2014). You will have to take care of any further update that might be released later and act manually to fix any mismatch. This will probably result in having to change some JavaScript reference to a later version, or to add some assemblyRedirect directive in your configuration files to remap an older version of a required assembly to a newer one. Once done with that, the code will still be valid and fully working.

It's worth mentioning that SignalR is an open source project whose source code can be found at https://github.com/SignalR/SignalR.

Whenever there's anything unclear and you really need to shed some light on it, you can inspect its code and find the answers by yourself. It's a very clean and well-organized code base, and you should not get scared by the idea of going through it. The official documentation can be found at http://www.asp.net/signalr.