1. What is SignalR:
ASP.NET SignalR is a library of classes provided to simplify the process of adding live web content to applications by development developers. Real-time web functionality refers to allowing server code to actively push content to clients at any time, rather than having the server wait for a request from the client (before returning content).
All "live" kinds of web functionality can be added to your ASP.NET application using SignalR. The most commonly used example is chat rooms, but we can do much more than that. Consider the following situations: users need to constantly refresh the web page to see the latest data; Or retrieve (and display) new data on the page by implementing long polling, then you can consider using SignalR to do so. For example: dashboards and monitoring applications; Collaborative applications (e.g., multiple people editing documents at the same time); Job progress updates and real-time presentation forms, etc.
SignalR is also suitable for newer types of web applications that require high-frequency updates from the server, such as real-time gaming. Here's a good example: ShoorR.
SignalR provides a simple API for users to create server-to-client remote procedure calls (RPCs) that can be easily accessed from server-side . Net code. SignalR also includes connections (e.g., connection and disconnect events) and connection grouping.
SignalR can automatically manage connections. And lets you send broadcast messages to all connected clients, just like a chat room. Of course, in addition to mass sending, you can also send messages to specific clients. The connection between the client and the server is persistent, unlike the traditional HTTP protocol, which requires re-establishing the connection for each communication.
SignalR supports the "server push" feature, where server code can call client code in the browser by using remote procedure calls (RPC) instead of requests currently 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 the WebSocket transport method - where possible. And automatically switch to the old transport method (e.g. HTTP long connection). You can certainly write your application directly with WebSockets, but using SignalR means you'll have more extra functionality without having to reinvent the wheel. Most importantly, you can focus on the business implementation without thinking about creating compatible code separately for the old client. SignalR also allows you to avoid having to worry about WebSocket updates, as SignalR will continue to be updated to support changing underlying transport methods to provide a consistent access interface for applications across different versions of WebSockets.
Of course, you can create a solution that only uses WebSocket transport, and SignalR provides all the features you may need to write your own code, such as falling back to other transport methods and modifying your application for newer WebSocket implementations.
3. Transportation and return
SignalR is an abstraction of the transport technology required to implement real-time functions between clients and servers. SignalR first starts the connection with HTTP and checks if the WebSocket is available - if sure, upgrade to the WebSocket's connection. WebSocket is the most ideal transmission method for SignalR because it makes the most efficient use of server memory, has the lowest latency and comprehensive underlying functions (such as full-duplex communication between client and server), but it also has the strictest requirements: the server must use Windows Server 2012 or Windows 8 operating system, and at the same time. .NET framework version 4.5 and above. If these requirements are not met, SignalR will try to use an alternative transmission method to connect.
4. HTML5 shipping
The transport method used depends on whether the client browser supports HTML5, otherwise the old transport method will be used.
WebSocket (if both the server and the browser support WebSocket). WebSocket is the only way to establish a true and durable two-way connection on both the client and server sides. Of course, WebSocket also has the strictest requirements: it is only supported in the latest versions of IE, Chrome and FF, and is only partially implemented in other browsers such as Opera and Safari.
Server sends events, also known as EventSource (if the browser supports server-sending events, basically all browsers except IE support this feature).
5.Comet transmission
The following transport types are based on the Comet web application model, where the browser or client will maintain a long HTTP connection request, and the server can push data to the client without an explicit request from the client.
Forever Frame (IE only) Forever Frame will create a hidden IFrame that sends a request to the server that will not be completed. The server then continuously sends scripts to the client and is executed immediately by the client, i.e. a one-way real-time connection from the server to the client. The client-to-server connection uses a different connection than that connection. For example, a standard HTML request creates a new connection for each data sent.
Ajax long polling does not create a persistent connection, but rather polls by constantly making requests to the server. Wait for the server to respond and close this connection on each connection, and then immediately make a new request. Of course, this will cause some delay when the connection is reset and reconnected.
For information about the transport methods supported by various configurations, see Supported Platforms. (IE requires 8 or above, other browsers are the current version -1)
Transfer method selection process
The following list shows how SignalR decides which type to use for transmission.
IE8 and earlier, use long polling.
If JSONP is configured (i.e. the jsonp parameter is set to true when connecting), use long polling.
If you are using a cross-domain connection (i.e., the SignalR endpoint and the page are not in the same domain), then use WebSockets if the following conditions are met:
The client supports Cross-Domain Resource Sharing (CORS), see CORS at for details
The client supports WebSocket
The server supports WebSocket
If any of the above conditions are not met, a long poll is used. For more information about cross-domain connections, see How to establish cross-domain connections.
If you don't configure the use of JSONP and the connection is not cross-domain, use WebSocket, of course, provided that both the client and the server support WebSocket.
If the client or server does not support WebSockets, use the server to send events.
If the server sends an event is not available, use a Forever Frame.
If Forever Frame is not available, use long polling.
Monitor transmission
You can see what transport method your application uses by enabling Hub logging and in your browser's console.
To enable logging, add the following command to the client application:
nnection.hub.logging = true;
6. Inspection and transportation:
You can see what transport method your application uses by enabling Hub logging and in your browser's console. 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 on the Console tab.
In Chrome, press Ctrl+Shift+J to open the console
By observing the logging in the console, you can see the transmission method that SignalR is using.
7. Designated Shipping:
Negotiating the transmission method requires a certain amount of time and the resources of the server/client. If the client environment is known, then the transport method can be specified when the connection is initiated to improve performance. The following code demonstrates using Ajax's long polling directly at connection initiation if the client is known to support any other protocol:
connection.start({ transport: 'longPolling' });
If you want a client to negotiate the transport in a specific order, you can specify the order in which the negotiation is attempted. The code below shows how to try using WebSockets first and use long polling directly after failure.
connection.start({ transport: ['webSockets','longPolling'] });
The string constants that are specified by the user are defined as follows:
webSockets
forverFrame
serverSentEvents
longPolling
8. Connections and Hubs The SignalR API includes two client-server communication models: persistent connections and hubs.
A connection represents a simple endpoint for sending a single, grouped, or broadcast message. The PersistentConnection API (represented by the PersistentConnection class in .NET code) gives developers direct access to SignalR's underlying communication protocol. Developers who have used connection-based APIs such as WCF will be more familiar with the connection communication model.
Hubs are API-based but higher-level communication pipelines that allow clients and servers to call methods directly to each other. SignalR does a wonderful job of handling cross-machine scheduling, allowing clients to easily call methods on the server as if they were calling local methods, and vice versa. Developers who have used remote call-based AIPs such as .Net Remoting will be more familiar with the hub model. Using the hub, you can also pass strongly typed parameters to methods and bind them to the model.
Architecture diagram: The diagram below shows the relationship between the hub, the continuous connection, and the underlying technology used for transport.
9. How the hub works:
When the server code calls the client, the server will send a packet containing the calling method and parameters (when the object is used as a method parameter, it will be serialized as JSON to be sent) to the client. The client then checks the received method name and performs a match lookup in the client-defined method, and if the match is successful, the method is executed and the deserialized object is used as the method parameter.
You can use tools like Fiddler to monitor method call execution. The following image shows a method captured from Fiddler's logs to be sent from the SignalR server to the web browser client. The method initiated from the hub is called MoveShapeHub, and the method called is updateShape.
In this example, the name of the hub is identified with the parameter "H", the method name is identified with the parameter "M", and the parameter object sent to the method is identified with the parameter "A". The application that generated the message was implemented in the high-frequency real-time communication tutorial.
Choose a communication model:
Most applications use the hub's API, which can be used in the following situations:
You need to specify the format in which the message is sent.
Developers prefer to use a messaging and scheduling model rather than a remote call model
The messaging model is being used in existing applications and is planned to be ported to SignalR.
|
Posted on 7/5/2017 10:21:40 AM
|
|
|
|
Landlord