As briefly mentioned a couple of times in this book, when a connection is started, SignalR chooses a transport strategy to provide the logical persistent connection on top of which every feature we described is made available. SignalR decides which strategy to use according to the environment it runs on. The connection process starts with a traditional HTTP connection, and from there the available options are checked in sequence until the best available option is determined and used.
The first two strategies checked are based on HTML5 and are as follows:
WebSocket: This is an HTML5-related protocol that provides full duplex communication channels over a single TCP connection. It provides the most complete set of features and the best performance, but has strict requirements. This option is available in modern web browsers only, and requires Windows Server 2012 or Windows 8, and .NET Framework 4.5. For more details about WebSocket, you can refer to http://www.websocket.org.
Server Sent Events: This strategy is based on
EventsSourceHTML5 support, which allows a server to stream messages to connected clients. AnEventSourceinstance can be created from JavaScript, making it target a remote endpoint that can then stream messages on the opened connection. Event handlers can be defined on theEventSourceinstance to receive the messages pushed by the server. For more details, you can check out http://www.w3.org/TR/eventsource.
When HTML5 is not available, two more strategies, commonly known as Comet, are checked. More details about the Comet web application model are available at http://en.wikipedia.org/wiki/Comet_(programming). The two strategies are as follows:
Forever Frame: This is a strategy based on the use of a hidden iframe where the Chunked Encoding HTTP feature is used to send an indefinitely long stream of bytes. It allows a server to start sending a response before knowing its total length, therefore supporting incremental delivery of content.
Long Polling: This is a basic technique that involves opening a connection and keeping it artificially alive to create the illusion of a persistent connection. Asynchronous requests are initiated and kept open until data is available to be sent to the client, or a timeout occurs. In both cases, a new connection is immediately opened when the previous one ends; that's why the term polling can be used to describe this technique. This is a generic description, but there are actually several ways to implement this strategy.
In Chapter 3, Using the JavaScript Hubs Client API, and Chapter 4, Using the .NET Hubs Client API, we illustrated the fact that developers can alter the probing sequence, making it possible to have SignalR make different choices. That said, most of the times this is not the recommended approach because the sequence is already optimized to guarantee the best features and performance available for a given environment. What's important here is to actually understand how and why a specific strategy is chosen, and then how such a strategy works so that you might be able to diagnose and fix issues you might find in specific scenarios.
More details about connection management in general, and about how that relates to specific transport strategies, can be found at http://www.asp.net/signalr/overview/signalr-20/hubs-api/handling-connection-lifetime-events.