Chapter One introduction to ASP. SIGNALR

1.1 Overview:The ASP. NET SIGNALR is a new class library developed by Microsoft to help the ASP to easily develop real-time network functionality. SIGNALR allows two-way communication between the server and the client. The server side can now connect to the client and push the content instantaneously, rather than a client constantly requesting the server to get new data (not by polling the server-side data, but by actively pushing the data to the client by the server). SIGNALR supports Web sockets sockets and automatically uses relevant and compatible technologies when using legacy browsers. SIGNALR includes its API interface for decoupling of connection management (e.g., connection and disconnection events), group connection interface and authorization interface, etc.SIGNALR can add a variety of "live" Web features to your ASP. The most common examples are chat rooms, but when you use SIGNALR, we can do much better than this. In the past, users needed to refresh their web pages to see new data, or to retrieve new data (and display it) on a page by implementing long polling, which became easier to implement and use after using SIGNALR. For example: dashboards and monitoring applications, collaborative applications (such as multi-person simultaneous editing of documents), job progress updates and timely presentation of forms.

SIGNALR also supports new types of Web applications that require high-frequency updates from the server, such as real-time games. For a good example of this, see Shootr game.

SIGNALR provides a simple API for creating a server-to-Client remote procedure Call (RPC), which invokes JavaScript functions from the client's browser (and other client platforms) from the server-side. NET code. SIGNALR also includes for connection management APIs (for example, connect and disconnect events), group connection and authorization, and so on. (In simple terms, the server-side API call and the client's JS event are provided)

SIGNALR can automatically manage connections and let you send broadcast messages to all connected clients at the same time, just like a chat room chat. Of course, you can also choose to send a message to a specific user (client). The connection between the client and the server is persistent, which is what we call a long connection, rather than a typical HTTP connection, where each communication is re-established.
SIGNALR supports the server push feature, where server code can invoke client code in the browser by using remote procedure call (RPC) instead of fetching data in the form of a common request-response model on a Web site.
SIGNALR applications are extended to tens of thousands of clients by using service bus, SQL Server, or Redis.
SIGNALR is open source and is accessed via GitHub to view the source code.

SIGNALR in a browser that supports HTML5, the websocket is usually used to communicate with the client on the server. If the browser does not support WebSocket then he will automatically switch to other technologies that support the browser (such as HTTP long connections). Whichever technique is used, the same result will be achieved in the end. Of course, you can also use Webstocket to write your application directly, but using SIGNALR means you will have more extra features without having to reinvent the wheel yourself (people have written the interface, it's not better to use it, why build your own wheels again). Most importantly, you can focus your time and attention on your business implementation without having to consider writing compatibility codes for older clients (IE9, and so on). SIGNALR also allows you to avoid worrying about webstocket updates, as SIGNALR will continue to update and support the underlying transfer of change, providing a consistent provider for applications across different versions of Webstocket.

Of course, you can create a solution that uses only webstocket transport, and SIGNALR provides all the features you might need to write your own code, such as fallback to other transports and webstocket for updates to modify your application.

2.1 Transfer and Negotiation conversions (fallbacks):
SIGNALR is an abstraction of the transfer technology needed to implement real-time functionality between the client and the server. SIGNALR starts the connection using HTTP first, and checks if the WebSocket connection is available, and automatically transitions to the Webstocket connection if available. WebSocket is the ideal transmission for SIGNALR because it can most effectively utilize server memory, has the lowest latency, and has the most basic functionality (such as "two-way communication" between the client and the server for full-duplex communication). But it also has the most stringent requirements: WebSocket requires the server to use Windows Server2012 or WINDOWS8, and NET Framework 4.5. If these requirements are not met, SIGNALR will attempt to connect using a different transport mode.

2.1.1 HTML5 transmission mode: (we recommend using Google Chrome as the master browser)
Any transfer using SIGNALR depends on whether the client browser supports HTML 5, and if the client's browser does not support HTML5, the old transfer method will be used.
1) WebSocket (if both the server and the browser support WebSocket): WebSocket the only way to establish a true and persistent bidirectional connection on the client and server side. However, WebSocket also has the strictest requirements, supported only in the latest version of MicrosoftInternet Explorer, Google Chrome and Mozillafirefox browser, Other browsers, such as opera and Safari, are only partially implemented (2014 the latest versions of opera and Safari are not clear and are expected to be supported, which is the direction of future development).
2) Server Send event: Also known as EventSource (if the browser supports the event sent by the server, this feature is basically supported by browsers other than IE. ）

2.1.2 Comet transmission mode:
The following transport types are based on the Cometweb application model, and the browser or client will maintain a long connection request for HTTP, and the server can push the data to the client without an explicit request from the client.
1) Forever frame (ie browser only): Forever frame creates a hidden iframe and then sends a request to the server that will not complete. The server then continuously sends the script to the client, and the script executes immediately by the client, establishing a one-way real-time connection from the server to the client. The connection from the client to the server uses a different connection than the connection. Like a standard HTML request, a new connection is created for each time the data is sent.
2) Ajax long polling: Long polling does not create a persistent connection, but instead polls the client continuously by making requests to the server side. Each time the connection is made, it waits for a response from the server to close the connection, and then makes a new request immediately (you can also define a time interval before sending a new request). Of course, this approach will cause a delay between the connection shutdown and reconnection.

See Supported Platforms (SUPPORTEDPLATFORMS) For more information on the modes of transport supported by the various configurations.

2.1.3. Transfer Mode selection process:
The following list shows how SIGNALR decides to transfer using that type of transport:
1. If the browser is a version of Internet Explorer 8 or earlier, use long polling.
2. If JSONP is configured (that is, the JSONP parameter is set to True when connected), long polling is used.
3. If you are using a cross-domain connection (that is, the SIGNALR endpoint and the page are not in the same domain), use websocket if all of the following conditions are true:

1) The client supports cors (cross-domain resource sharing). For more information, see Corsat caniuse.com.
2) WebSocket supported by this client
3) WebSocket supported by this server
If the above three conditions, as long as one is not satisfied, then use long polling. For more information about cross-domain connections, see how to establish a cross-domain connection.
4. If you are not configured to use JSONP and the connection is not cross-domain, use websocket, of course, if both the client and server side support Webstocket

5. If the client or server does not support WebSocket, use the server to send events (EventSource).
7. If the server send event is not available, try using Foreverframe.
8. If forever frame is not available, long polling is used.

(that is, the priority used by default: 1.) Webstocket;2. Eventsource;3. Forever Frame; 4. Long polling)

2.1.4 Monitoring transmission:

You can enable logging by enabling hub logging and see which transport your application uses in the browser's console, and if you want to enable log logging, first add the following command to the client application:

$ connection.hub.logging= true;

· In Internet Explorer, press F12 to open the Developer tool and click the Console tab.

· In the Chrome browser, press CTRL+SHIFT+J. Open Console

By observing the log records in the console, you can see the mode of transmission that SIGNALR is using.

2.1.5 Specify the transport protocol and the fallback (Negotiate transform) mechanism:
Negotiation transfer Mode is a time and resource for clients and servers. If the client's environment (browser type version, etc.) is known, you can increase performance by specifying the transfer mode when you start the connection. The following code snippet shows that if a known client does not support any other transport protocol, use Ajax's long polling as a transmission directly when the connection is started:

Connection.start ({transport: ' longpolling '});

If you want a client to negotiate conversions in a specific order, you can specify the order in which the conversions are negotiated. The following code snippet demonstrates the priority attempt to use the WebSocket, and if not supported, uses long polling.

Connection.start ({transport: [' webSockets ', ' longpolling ']});

The string constants used to specify the transport are defined as follows

1)webSockets

2)forverFrame

3)serverSentEvent

4)longPolling

2.1.6. Staying power Connection (Persistentconnection) and hub (Hubs)
The SIGNALR API consists of two modes for communication between the client and the server: long connections and hubs.
1) Staying power connection (Persistentconnection): Represents a simple node from a terminal to a single, grouped, or mass broadcast message. The Staying power connection API, represented by the Persistentconnection class. Code encapsulated in net), giving developers direct access to SIGNALR's underlying communication protocols. Using the communication mode of the staying power connection, and the invocation of its API, is as simple as being familiar with invoking the API developed by WCF (like WebService).

2) Hub (Hubs): is an API-based but higher-level communication pipeline that allows clients and servers to call methods directly to each other. SIGNALR can skillfully handle cross-machine scheduling, making it easy for clients to invoke methods on the server side as if they were local methods, and vice versa. For developers who have used. NET remoting, it is easy to use the hub communication mode to remotely invoke the server or client API. With hubs, you can also use strongly typed parameters in your methods and bind to your model class.

3) Architecture diagram: Shows the relationship between a hub, a staying power connection, and the underlying technology for transmission.

2.1.7. How a Hub (Hubs) works:
When the server-side code calls the client's method, the server side sends a packet containing the name and parameters of the method to be called (when an object is serialized as a method parameter, which is sent as JSON), and pushes the client forward. The client then checks to receive the method name, performs a matching lookup in the client-defined method, executes the method if the match succeeds, and uses the deserialized object as the method parameter.
You can use tools such as Fiddler to monitor the execution of a method's calls. Shows a method that is fetched from the SIGNALR server to the Web browser client in the Fiddler log. The method to initiate the call from the hub is: Moveshapehub, called by: Updateshape.

Obviously, in this example, the M:[{xxxxxxxxx}]json number, "H" corresponds to the server-side method name, "M" corresponds to the client's method name, "A" is the parameter we want to transfer

2.1.8 Staying Power Connection (Persistentconnection) and Hub (Hubs) selection (communication mode selection):

1) Most applications should use a hub (Hubs) API.

2) The Staying Power connection (persistentconnection) API can be used in the following situations:
A) You need to specify the format of the messages that are actually sent. (self-Customizing the JSON format of the message).
b) Developers prefer the way WCF (Webservice) calls, not the. netremoting.
c). Existing programs already use the WCF (Webservice) method of the program, and plan to move to SIGNALR.

Chapter One introduction to ASP. SIGNALR