Archive for category WebSockets

SignalR : know your transport

I just recently started using SignalR. I had the time to explore this new framework in the last couple of months and use it in a recent work engagement for a proof of concept.There has been a wide acceptance for SignalR – not without a reason.It’s very easy to set up and code, supports WebSockets if Client and Server both support the transport. This has made real-time programming easy and fun, plus in this new age of rich internet applications this can be almost in any context.

Secondly ,the SignalR support is tremendous – it’s open sourced and supported by Microsoft. The MS developers of the product do a tremendous job of answering questions on premier .net QA forums like Stack Overflow. There are several examples on the web available on how to set up and get SignalR working with your project including GitHub where SignalR is hosted. However I would like bring in some observations where I had some in-claritythe beginning. SignalR basically supports four transports, employs graceful degradation based on the negotiation between the client and the server. The four transports are:

  1. WebSockets
  2. Server Sent Events
  3. Forever Frame
  4. Long polling

The WebSockets transport is the most sought after transport for real-time programming because it offers a bi-directional communication as opposed to other transports giving you the maximum performance. Although SignalR can be made to work with .net framework 4.0, however WebSockets will not get used as a transport if you are using a web server version lower than IIS 8.0 .This is an important aspect to realize considering certain browsers like Chrome support WebSockets. It’s good to run Fiddler and see what happens in order to understand if SignalR negotiated a WebSockets transport or not.

GET http://localhost:2592/signalr/hubs 200 OK (application/x-javascript)GET http://localhost:2592/signalr/negotiate?_=1359546909252 200 OK (application/json)

GET http://localhost:2592/signalr/connect?transport=serverSentEvents&connectionId=d66299e6-196f-4f17-a11f-191c8dfd84d1&connectionData=%5B%7B%22name%22%3A%22stocktickerhub%22%7D%5D&tid=9

200 OK (text/event-stream)

POST http://localhost:2592/signalr/send?transport=serverSentEvents&connectionId=d66299e6-196f-4f17-a11f-191c8dfd84d1

200 OK (application/json)

Here I am running this application from Visual studio 2010, .net framework 4.0 and Chrome release 24.0.1312.56 m as a browser which does support WebSockets transport. So the point is,  it is not sufficient if the browser supports WebSockets , the server needs to have support for it as well. As of now , in order to run SignalR in production with IIS , at minimal you must have IIS 8.0 and .net framework 4.5 . ASP.NET 4.5 and IIS 8 include low-level WebSockets support and not the previous versions.

In a second experiment there is a request going into IIS 6.0 , on the local network where SignalR is hosted with .net framework 4.0 and Chrome as the browser –

GET 200 OK (application/json)

GET 200 OK (application/json)

200 OK (application/json)

200 OK (application/json)

Well , now long polling got negotiated because the request is considered Cross domain , as of now neither WebSockets nor ServerSentEvents are supported under Cross domain.

Any of the above 4 transports could work depending on the context of your application. However it’s important that you run Fiddler or some other similar tool to know what transport got negotiated and whether client and server both support it.

Thanks to this question by Hemang Dave on Stack Overflow, helped me arrive at some conclusions.

Happy SignalR programming !