ASP.NET SignalR is a new library for ASP.NET developers that simplifies the process of adding real-time web functionality to your applications. Real-time web functionality is the ability to have server-side code push content to connected clients instantly as it becomes available. You may have heard of the HTML5 WebSocket API that enables efficient bidirectional communication between the browser and server. SignalR uses Websockets when it is supported by the browser and the server, and gracefully falls back to other techniques and technologies when it is not. Either way, your application code stays the same. SignalR provides a simple ASP.NET API for creating server-to-client remote procedure calls (RPC) that call JavaScript functions in client browsers from server-side .NET code. SignalR also includes API for connection management (for instance, connect and disconnect events), grouping connections, and authorization.
In this post I will review the protocol SignalR implements and see what data is sent at the various
stages.
1. Negotiate
2. Connect
2.1. Connect Phase Data
2.1.1. Client to Server
2.1.2. Server to Client
1. Negotiation:
One of SignalR best qualities is its ability to support various communication techniques without its API user have to change his/her code. Therefore both client and server needs to “negotiate” their communication capabilities.
Image may be NSFW.
Clik here to view.
The browser requests the URL of /SignalR/negotiate with a number in the query-string parameter and gets a JSON response, lets have a look at some of its members:
Image may be NSFW.
Clik here to view.
ConnectionId: | A unique ID for the signalR client, will be used at further requests. |
ProtocolVersion: | A SignalR protocol version. (If you’re running RC2 you’ll get 1.1 on its value) |
TryWebSocket: | A boolean value, if true – the client can try use WebSocket (because the server supports that, otherwise false. |
KeepAlive: | The time in seconds for the server to send empty message to the client to see if it is stile “alive”. |
Url: | The base Url for all SignalR requests. It will be relative to the SignalR hosting site Url. |
WebSocketServerUrl: | Deprecated, and always bee null. |
2. Connect:
After negotiating with the server, both parties have agreed on the underlying communication technique, then the client sends a “connect” request with two query string parameters:
Image may be NSFW.
Clik here to view.
Transport: | The communication technique used WebSocket, ServerSentEvents, |
ConnectionId: | The unique id given for this client at the negotiation phase. |
Update for the released version (1.0)
After the negotiation, the server returns also a longer string of ConnectionToken, this string replaces the connection id at the connect phase request.
2.1 Connect phase data
Apart from query string, the client can call the server and vice versa. These messages will look like the following:
2.1.1 Client –> Server :
Image may be NSFW.
Clik here to view.
{H: “hubName”, “M”: “MethodName”, “A”: [arguments] , “I” :, messageNumber }
That’s a JSON message sent to the server with the following parameters:
H: | Hub name, the hub activated on the server |
M: | The method to operate on the hub |
A: | the methods arguments |
I: | Message index, where each client has its own counting |
Afterwards, the server will respond (if no error will occur) with {I: messageIndex} where the message index is the same as the one received from the client.
Image may be NSFW.
Clik here to view.
2.1.2 Server –> Client
Image may be NSFW.
Clik here to view.
In here we’ll see the same structure inside some larger message, starting with the letter C,
then after the first letter M you can see the same structure only the method name is the
method should be run on client side.
{"C":"B,6|O,0|P,0|Q,0","M":[{"H":"hubMane","M":"clientMethod","A":[arguments]}]}
Note: Both server and client doesn’t send any parameter names, but sending the
argument in an array. Therefore, with signalR there shouldn’t be any overloading
of methods.