Page 56 - MSDN Magazine, May 2018

a protocol upgrade request. More precisely, a protocol upgrade is a normal HTTP request (a GET but it can also be a POST) with two ad hoc headers. One is the Connection header, which must be set to Upgrade. The other is Upgrade, which must be set to the name of the required protocol—in this case, WebSockets. If the proto- col upgrade is accepted, the server returns an HTTP 101 Switching Protocols response (as shown in Figure 1).
The client can force the connection to take place over a specific protocol.
Transport Protocols
SignalR can employ various transport protocols. The client can force the connection to take place over a specific protocol, but by default the protocol is automatically determined. To request a specific transport, simply add an extra parameter to the JavaScript code (or client code if a non-Web client is used). Here’s an example:
var progressConnection = new signalR.HubConnection( "/progressDemo",
{transport : signalR.TransportType.WebSocket});
Note that by passing an array instead of a direct name, you can restrict the choice to one of a few specified protocols. Of course, transport protocols differ in a few aspects. Figure 2 lists the main characteristics of each protocol.
If the communication between the Web client and the server is cross-domain, then the server must be CORS-enabled. In this case,
Figure 2 Supported Transport Protocols
you can use any available protocol (note that JSONP isn’t supported in ASP.NET Core SignalR):
public void ConfigureServices(IServiceCollection services) {
services.AddCors();
}
The browser adds the Origin header to the AJAX and WebSockets calls of ASP.NET Core SignalR. In addition, you need to have the CORS middleware configured in your SignalR application to ensure that the browser allows the requests.
Message Protocols
SignalR in ASP.NET always serialized exchanged messages using the text-based JSON format. The newest ASP.NET Core SignalR adds a binary message protocol based on the MessagePack format. This binary serialization format lets you exchange data in a lan- guage-agnostic way, much the way JSON does.
MessagePack is both more compact and faster to transfer than JSON, and features packet sizes that are even more compact than Binary JSON (BSON)—the MongoDB-optimized flavor of JSON. With MessagePack, both small integers and NULL values consume just one byte of data. By comparison, JSON Nulls consumes 4 bytes. For more information about the protocol, check out msgpack.org.
To use MessagePack from an ASP.NET Core SignalR Web client, you just add one more parameter to the JavaScript code that sets up the connection, as shown here:
var protocol = new signalR.protocols.msgpack.MessagePackHubProtocol(); var progressConnection = new signalR.HubConnection(
"/progressDemo", {
transport : signalR.TransportType.WebSocket, protocol : protocol
} );
Note that in the case of a Web client willing to use MessagePack, you also must include a separate JavaScript file (signalr-msgpack- protocol.min.js) that you find in the @aspnet/signalr NPM package. MessagePack also requires the ASP.NET Core server to be con- figured, like so:
public void ConfigureServices(IServiceCollection services) {
// SignalR already configured. Just add this:
services.AddMessagePackProtocol(); }
If you use a non-Web client, all you need to do to enable MessagePack is an extra call in the client application. Specifically, you place a call to the extension method WithMessagePackProtocol defined on the class HubConnectionBuilder.
Non-Web Clients
The most interesting aspect of the .NET Standard specification is that you can consume the same library from within a vari- ety of client applications as long as API compatibility exists. The ASP.NET Core SignalR client library, being based on the .NET Standard 2.0, can be used from within any client applications compiled for a variety of compatible platforms, including the Microsoft .NET Framework 4.6.1 and newer. This means that, say, a Windows Forms application compiled against versions of the .NET Framework newer than 4.6 can happily consume the ser- vices of an ASP.NET Core SignalR hub.
Protocol
Description
WebSockets
Based on a one-to-one connection between the client and server. Both client and server write on a shared pipe so that the flow of the data is bidirectional. The protocol cannot be used everywhere and is limited by the browser and server being used for the connection. On the client, a modern browser is required. The latest versions of all common browsers usually work, with the exception of Internet Explorer prior to version 10. On the server side, when using IIS or HttpSysServer, Windows 8 or newer is required on the client.
ServerSentEvents
Based on EventSource object active on the server. The object represents a pipe connecting the server to the client. Once the connection is established, the server can continuously send events while the client can communicate only via plain AJAX calls. The protocol dates back to the early days of Netscape and isn’t supported on the Internet Explorer or Edge browsers.
LongPolling
The protocol works by opening a connection with the server to use for future responses. The connection remains pending until a response is sent or the request times out. In any case, once the connection is closed, the client immediately re-establishes it so that polling is continuous but traffic is limited to what’s strictly necessary. This protocol works with all versions of all browsers and is considered a fallback solution.
52 msdn magazine
Cutting Edge