SignalR Protocol

17 בFebruary 2013

one comment

SignalR Protocol

 

After showing how to get started with SignalR, how to use it with .Net client and how SignalR Logo
to self host it, I wish to show what SignalR does on the network level. In this post
I will review the protocol SignalR implements and see what data is sent at the various
stages.

 

Negotiation phase:

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.

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:

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.

Connect phase:

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:

Transport: The communication technique used (WebSocket, ServerSentEvents,
ForeverFrames or LongPolling)

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.

 

Connect phase data

Apart from query string, the client can call the server and vice versa. These
messages will look like the following:

Client –> Server :

{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.

Server –> Client 
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.  

If you wish to see the actual frame while running your application

you may see it on Chrome development tools, or by fiddler. You may

read more about using fiddler with SignalR.

 

Summary:

This was a short glance at the network transport used by SignalR, It

can help us better understanding and more easily debugging our applications.

 

Shout it

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

one comment

  1. Pingback: Simple .net client and server SignalR with PersistentConnection (no hubs) and the client’s memory usage - The Activity Designer - Site Home - MSDN Blogs