February 2013 - Posts
Debugging your signalR application on both client and server
can consume time. To save time we might go to Fiddler, or
use the Network tab on our browser’s developer tools.
signalR offers simple logging mechanism for javascript clients.
in this post I’ll briefly show how to enable this log, what it
writes when enable, and how to add some custom log records.
Enable logging
To enable logging you simply need to add the following
$.connection.hub.logging = true;
After enabling the log you’ll see what client events were
triggered by the server.
For example, when you call in your Hub code (server side) you
call Clients.All.sendMessage, this is what you’ll see on your
console tab (taken from Chrome console)
[12:02:21 GMT+0200 (Jerusalem Standard Time)] SignalR: Triggering client hub event 'sendMessage' on hub 'chatHub'.
Custom logging
Apart from simply using the console.log() function, you
can use the $.connection.hub.log() function provided
by signalR. This function won’t do anything if logging
is disabled, end write to the console log if enabled.
Let’s see an example:
In the following code example we call sever side’s chat method
and log our call write away.
sendMessage : function () {
viewModel.hub.server.chat(this.message());
$.connection.hub.log("Sending " + this.message() + " to the server");
this.message("");
}
And this is what we’ll see on our console:
[12:59:08 GMT+0200 (Jerusalem Standard Time)] SignalR: Sending Hi fellows to the server
Summary
signalR logging is simple yet very handy tool to monitor our application
at development time. You may find it useful and all you have to do
when going to production is to disable the log.
First signalR eBook was published yesterday. The book was
authored by Jose M. Aguilar, Microsoft ASP.NET MVP.
The book is free of charge along with code samples.
Click here to download.
SignalR Protocol
After showing how to get started with SignalR, how to use it with .Net client and how
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.
About embedded & external resource files
Recently I was asked by a colleague of mine to help him with a problem.
He had tried numerous times to work with resource files on a web project
and got many errors until he had moved the files build action from content
to embedded resource.
What’s the difference?
Embedded resources are files that are put inside the compiled assembly when compiling it.
However, when a resource file build action is content, only the .designer.cs file that
comes with it is compiled (you can see that its build action is compile) and the .resx file
is copied as is when publishing the application.
However, when adding resource (.resx) file into another application or class library, its
default build action will be Embedded Resource instead of Content . The .designer.cs
file will have the same build action, Compile (as every code file).
You may see it from both screenshots below:
Please note another two different values on the CustomTool property. The CustomTool
is the component in charge of creating the code in the .designer.cs file. This property is
overlooked. The Embedded Resource has ResXFileCodeGenerator custom tool while
the other one has GlobalResourceproxyGenerator custom tool.
And what is the difference between the two custom tools?
The main difference is in the .designer.cs . This file contains class with static properties
where each property uses ResourceManager.GetString method in its getter, to return
the value.
Here’s the code (on both generated files)
internal static string MyResource {
get {
return ResourceManager.GetString("MyResource", resourceCulture);
}
}
However, the ResourceManager property is created differently. Let’s have a look on how it
is created in the with the file generated with ResXFileCodeGenerator custom tool
(Embedded resource).
internal static global::System.Resources.ResourceManager ResourceManager {
get {
if (object.ReferenceEquals(resourceMan, null)) {
global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("MyClassLibrary.ClassLibraryResource", typeof(ClassLibraryResource).Assembly);
resourceMan = temp;
}
return resourceMan;
}
}
And the one generated by GlobalResourceproxyGenerator (in use in web applications,
Content buld action).
internal static global::System.Resources.ResourceManager ResourceManager {
get {
if (object.ReferenceEquals(resourceMan, null)) {
global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("Resources.MyWebResource", global::System.Reflection.Assembly.Load("App_GlobalResources"));
resourceMan = temp;
}
return resourceMan;
}
}
The difference is the Assembly of the resources. While the first code snippet goes to
the assembly holds the class inside the .designer.cs file (which is the class library
compiled DLL), the web application code loads assembly by reflection.
And what is the assembly it loads?
Well, the aspnet compiler generates assemblies from all markup code, where each
folder is compiled into different assembly. Therefore the actual resources are
located in different assembly than the code behind (which compiled by the
aspnet compiler as al content files) and therefore published as is to the target
server where our web application runs.
Summary:
Although looks the same and has very similar code, when having resource file
on ASP.NET applicationis by default not embedded resource.
To have the resource outside of the ASP.NET application’s
assembly we must have the right custom tool chosen.
