Signalr-Getting Started

1. What is SIGNALR:

ASP. NET SIGNALR is a class library that is provided to simplify the development of real-time web content to the application process by the developer developer. Real-time web functionality refers to having the server code actively push content to the client at any time, rather than having the server wait for the client's request (to return content).
All "live" kinds of web features can be added to your ASP. NET application using SIGNALR. The most common examples are chat rooms, but we can do much more than that. Consider the following: Users need to constantly refresh the page to see the latest data, or on the page by implementing long polling to retrieve new data (and display), then you can consider using SIGNALR to achieve. For example: dashboards and monitoring applications, collaborative applications (such as simultaneous editing of documents by multiple people), job progress updates and real-time rendering of forms, etc.
SIGNALR is also suitable for new types of Web applications that require high-frequency updates from the server, such as live games. Here's a good example: Shoorr.
SIGNALR provides a simple API user to create a server-to-Client remote procedure Call (RPC) that can be conveniently from the server side. NET code to invoke the JS function in the client browser and other client platforms. SIGNALR also includes for managing connections (for example, connection and disconnection events) and connection grouping.

The SIGNALR can be automatically managed by the connection. And let you send a broadcast message to all connected clients, just like a chat room. Of course, in addition to mass, you can also send messages to a specific client. The connection between the client and the server is persistent and does not require the HTTP protocol of the connection to be re-established like the traditional every communication.
SIGNALR supports the server push feature, which means that server code can invoke client code in the browser by using remote procedure call (RPC) instead of the current request that is commonly used on the web-the corresponding processing model.
SIGNALR applications can be extended to thousands of clients using service bus, SQL Server, or Redis.
SIGNALR is open source and can be accessed via GitHub.

2.SignalR and WebSocket

IGNALR uses WebSocket transfer mode--where possible. and will automatically switch to the old transfer mode (such as an HTTP long connection). You can certainly write your application directly using WebSocket, but using SIGNALR means you will have more additional features without having to reinvent the wheel. Most importantly, you can focus on the business implementation without having to consider creating compatible code separately for the old client. SIGNALR also allows you to avoid worrying about websocket updates, as SIGNALR will continue to update to support the changing underlying transport, providing a consistent provider for applications across different versions of WebSocket.
Of course, you can create a solution that uses only websocket transport, and SIGNALR provides all the features you might need to write your own code, such as fallback to other transports and modifying your application for the updated WebSocket implementation.

3. Transportation and fallback

SIGNALR is an abstraction of the transfer technology needed to implement real-time functionality between the client and the server. SIGNALR first begins the connection in HTTP and checks if the WebSocket is available-if determined, the connection to the WebSocket is upgraded. WebSocket is the ideal transmission for SIGNALR because it can most effectively utilize the server's memory, has the lowest latency and comprehensive underlying functionality (such as full-duplex communication between the client and server), but it also has the most stringent requirements: The server must use Windows Server 2012 or Windows 8 operating system, at the same time. NET Framework version 4.5 and above. If these requirements are not met, SIGNALR will attempt to use a different transport mode for the connection.

4.HTML5 Transport

The type of transport used depends on whether the client browser supports HTML5, otherwise the old transfer method will be used.
WebSocket (if both the server and the browser support WebSocket). WebSocket is the only way to establish a true and persistent bidirectional connection on the client and server side. Of course, WebSocket also has the most stringent requirements: only in the latest version of Ie,chrome and FF support, other browsers such as opera in Safari is only partially implemented.

The server sends events, also known as EventSource (if the browser supports the server to send events, it is basically supported in browsers other than IE).

5.Comet Transmission

The following transport types are based on the Comet Web 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.
Forever frame (ie only) Forever frame creates a hidden iframe and sends a request to the server that does not complete. The server then continuously sends the script to the client and is executed immediately by the client, which is to establish 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. A standard HTML request, for example, creates a new connection for each time the data is sent.
Ajax long polling does not create a persistent connection, but instead polls the server repeatedly by making a request to it. Wait for the server to respond and close the connection on each connection, and then make a new request immediately. Of course this will cause some delay when the connection is reset and reconnected.
See supported platforms for the transport modes supported by the various configurations. (ie requires more than 8, other browsers are current version-1)
Transfer Mode selection process
The following list shows how SIGNALR determines which type to use for transmission.
IE8 and earlier versions, use long polling.
If JSONP is configured (that is, the JSONP parameter is set to True when connected), long polling is used.
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 the following conditions are true:
Clients support cross-domain resource sharing (cors), for more information, see CORS at
Client Support WebSocket
Server Support WebSocket
If any of the above conditions are not met, a long polling is used. For more information about cross-domain connections, see how to establish a cross-domain connection.
If you are not configured to use JSONP and the connection is not cross-domain, use websocket, of course, if both the client and the server support WebSocket.
If the client or server does not support WebSocket, use the server to send events.
If the server sends an event that is not available, use forever Frame.
If forever frame is not available, use long polling.
Monitor transmission
You can enable hub logging and see in the browser's console what kind of transport the application is using.
To enable logging, add the following command to the client application:
Nnection.hub.logging = true;

6. Inspection of Transportation:

You can enable hub logging and see in the browser's console what kind of transport the application is using. To enable logging, add the following command to the client application:
Nnection.hub.logging = true;

$.connection.hub.logging = true;

In IE, press F12 to open the developer tools and click the Console tab.

In Chrome, press CTRL+SHIFT+J to open the console

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

7. Designated Transport:

Negotiating a transfer requires a certain amount of time and resources for the server/customer order. If the client environment is known, you can improve performance by specifying the transport mode when you start the connection. The following code shows that if a known client does not support any other protocol, use Ajax's long polling directly when the connection starts:
Connection.start ({transport: ' longpolling '});
If you want a client to negotiate the transfer in a specific order, you can specify the order in which the negotiation is attempted. The following code shows how to first try to use WebSocket and use long polling directly after a failure.
Connection.start ({transport: [' webSockets ', ' longpolling ']});
The string constants for the user-specified transport are defined as follows:
WebSockets
Forverframe
Serversentevents
Longpolling

8. Connection and Hubs

The SignalR API contains two models of client-server communication: Persistent connections and hubs (Hubs).
A connection represents a simple endpoint that sends a single, grouped, or broadcast message. The persistent connection API, represented in. NET code by the Persistentconnection class, gives developers direct access to the underlying communication protocols of SIGNALR. Developers who have used a connection-based API such as WCF will be more familiar with the connectivity communication model.
A hub is an API-based but higher-level communication pipeline that allows methods to be called directly to each other on the client and server. SIGNALR can wonderfully handle scheduling across machines, making it easy for clients to invoke methods on the server as if they were local methods, and vice versa. Developers who have used remote invoke-based AIP such as. Net remoting will be more familiar with the hub model. With hubs, you can also pass strongly typed parameters to a method and bind to the model.

Architecture diagram: The following diagram shows the relationships between hubs, persistent connections, and the underlying technologies used for transport.

9. How a Hub works:

When the server code calls the client, the server sends a packet that contains the calling method and parameters (which are serialized as JSON when the object is used as a method parameter) to be pushed to the client. The client then checks the received method name and makes a matching lookup in the client-defined method, executes the method and uses the deserialized object as the method parameter if the match succeeds.
You can use tools such as Fiddler to monitor the execution of calls to methods. Shows a method that is fetched from the SIGNALR server to the Web browser client in the Fiddler log. The method that initiates the call from the hub is Moveshapehub, and the method being called is Updateshape.

In this example, the name of the hub is identified with the parameter "H", the method name is identified by the parameter "M", and the parameter object that is sent to the method uses the parameter "A". The application that generated the message was implemented in the high-frequency real-time communication tutorial.

Select the communication model:

Most applications use the Hub's API, which can be used in the following scenarios:
You need to specify the format for sending messages.
Developers prefer to use messaging and scheduling models rather than a remote call model
The messaging model is being used in existing applications and is scheduled to be ported to SIGNALR.

Signalr-Getting Started