ASP. NET SignalR 2.0 Getting Started Guide

Introduction to SignalR

ASP. NET SignalR is a library for ASP. NET developers. It simplifies the process of adding real-time web functions to applications. The real-time Web function makes it possible for the server to push content to a link to the client and apply the content immediately without waiting for the client to request data.

SignalR can be used to add real-time Web functions to ASP.. NET application. The chat room is a common example. You can refresh the Web page to obtain new data, or use a long polling to retrieve data on the page, this is a scenario where SignalR can be used. For example, dashboards and monitoring systems, and real-time games.

SignalR allows you to use a simple API to create a Javascript method for remotely calling the client from the server to the client. SignalR also includes APIs for connection management and group connections.

SignalR automatically processes connection management and allows you to broadcast messages to all connected clients at the same time as a chat room. You can also send messages to specific clients, the connection between the client and the server is persistent and does not need to be rebuilt like a traditional HTTP connection.

SignalR supports the server push function. In the server, client code in the browser can be called, instead of the "request-response" mode.

SignalR can be expanded to thousands of clients through the service bus, while SignalR is open-source and can be accessed through Github.

SignalR and WebSocket

SignalR preferentially uses the new WebSocket transmission when WebSocket is available, and is also compatible with the old-fashioned transmission. Although you can use WebSocket to write your application immediately, using SignalR means that you can obtain many extension methods that you need to implement by yourself. The most important thing is that, you can directly use SignalR to write code using WebSocket without worrying about providing support for the old client. At the same time, you do not have to worry about WebSocket updates, because SignalR will continuously update to support basic transmission protocols and provide unified interface support for different versions of WebSocket.

Although you can use WebSocket alone to create your solution, SignalR supports all the methods you need to write on your own, such as supporting the functions of other revisions.

Transmission and rollback

SignalR abstracts the real-time cooperative transmission between some servers and clients. A SignalR connection starts as an HTTP, but WebSocket is available. WebSocket is an ideal transmission method for SignalR. It can efficiently use server-side storage with minimal latency and basic functions (such as full-duplex communication ), however, WebSocket must require the Server to use Windows Server 2012 or windows 8.. NET Framework 4.5 Framework. If these conditions are not met, SignalR tries to use another transmission to create a connection.

HTML5 transmission protocol

These transmissions depend on HTML5 support. If the client does not support the HTML5 standard, the old transmission protocol is used:

WebSocket: (if both the client and server support WebSocket ). WebSocket is the only transmission protocol that establishes a real persistent duplex between the client and the server, but WebSocket also has strict requirements, it is only supported in the latest version of IE, chrome, and FireFox, and is implemented in some browsers such as Opera and Safari.

The server sends an event, also known as an event source. Besides IE, event sources are supported.

Comet transports

The following transmission protocols are based on the Comet web application model. The client browser or other clients maintain a persistent HTTP request, and the server uses it to push data without separate requests from the client.

Forever Frame: (IE only) a hidden IFrame is created for a persistent Frame to create a request that does not end at the server endpoint, the server can continuously send scripts to the client to execute a one-way real-time connection from the server to the client. This link uses a different connection from the client request server, like a standard HTTP request, to create a new connection for each data to be sent.

AJAX long polling (Ajax long polling) does not create persistent connections. Instead

When the other end of the server sends a request to the Open Server, a new link needs to be established immediately.

 

Transfer protocol selection process

The following list shows the transfer protocol selection process for SignalR:

1. If the browser is IE8 or an older version, use long polling;

2. If JSONP is configured (the jsonp parameter is set to true when the connection starts), long polling is used;

3. If a cross-origin connection is being created (if the SignalR endpoint is not the same as the address on the page), WebSocket is used if the following conditions are met:

• The client supports CORS (click here for details)
• The client supports WebSocket
• The server supports WebSocket

4. If JSONP is not configured and the connection is not cross-origin, if both the client and server support WebSocket, WebSocket is used;

5. If the client and server do not support WebSocket, use the event source whenever possible;

6. If the server does not support event sources, use a persistent framework;

7. If the persistent framework also fails, use long polling.

Monitoring Transmission

You can decide whether to enable logging on the bus and open the console window of the browser.

To start your bus event in the browser, add the following command to the client application:

In IE, press F12 to open the developer tool and click the "console" tab.

In Chrome, press Ctrl + Shift + J to open the console.

Transmission Protocol

It takes a certain amount of time to negotiate the transmission protocol with the server client resources. If the client can predict, the transmission protocol can be specified at the beginning of the connection, the following code uses a short example to start a connection that uses AJAX long polling. If it is known that the client does not support any other protocol:

 

connection.start({ transport: 'longPolling' });

You can also specify a callback order for the client to try to specify the transmission protocol:

connection.start({ transport: ['webSockets','longPolling'] });

The following is a defined string used to specify the transport protocol:

• webSockets

• foreverFrame

• serverSentEvents

• longPolling

Connection and bus

The SignalR API consists of two Communication Models: persistent connection and bus.

A connection indicates a simple endpoint for sending a single recipient, group, or broadcast message. The persistent connection API allows programmers to directly access the underlying communication protocol provided by SignalR. Using a connection communication model is similar to using a connection-based API like WCF.

A bus is a more advanced pipeline built on a connection-based API that allows clients and servers to directly call each other. The magical processing of SignalR is scheduling across machines, so that the client can call the server code as easily as calling a local method, and vice versa. Using the bus communication model is similar to using a remote call API such as. NET Remoting. Using the bus model allows you to pass strong parameters to methods for model binding.

Architecture Diagram

The following diagram shows the relationships between the bus, persistent connections, and the basic technologies used for transmission:

 

Address: http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/introduction-to-signalr