Skip to content

Differences with SignalR

vtortola edited this page May 13, 2014 · 1 revision

SignalR is a push communication framework that offers four different transports:

  • Long Polling : A cyclic HTTP request that the server holds till there is something to communicate or timeouts. Basically, it continuously issue HTTP requests to the server.
  • Forever Frame: An IE only crazy thing with iframes.
  • Server Sent Events: A persistent connection server-2-client only that is implemented in all major browsers, but IE.
  • WebSokets: A full duplex persistent connection capable of transmitting UTF8 text and binary data. Unfortunately, only works if your server operating system is Windows 8 or Windows 2012.

Fallback

SignalR can fallback to a more supported transport if the client does not support for example WebSockets. In practice:

  • WebSockets can be used only if your server is Windows 8 or Windows 2012.
  • SSE can be used only if your client is not Internet Explorer.
  • Forever Frame can be used only if your client is Internet Explorer
  • Long Polling is always supported.

Current WebSocket support is very good. If your client´s browser does not support WebSockets, it does not support other HTML5 features either. The main problem are users stuck on Windows Vista and earlier, that can only update to IE9, that does not support WebSockets (among other things). Basically Microsoft abandon them, remember that when you schedule your resources to support those browsers. However, they can install latest versions of Chrome or Firefox.

Before deciding if you need fallback or not, study what your user base is using, and study how that fallback scales out.

There are polyfills for WebSockets done in Flash.

Scaling out

SignalR scale out is not very promising. Long Polling and WebSockets are very different animals, in order to support both seamlessly and scale out you have to use something called SignalR backplane to interconnect all the servers. Every message, is forwarded to the rest of servers. Their own documentation states that it is not suitable for real time scenarios, and can be a bottle neck for things that are not general broadcasting.

Hosting

SignalR and System.Net.WebSockets applications can be hosted in IIS, which is very convenient. Basically, thanks to the new features of http.sys in Windows 8/2012, a web request can be converted in a WebSocket channel. This allows to use the WebSockets as part of your web applications, without running an external process.

Main differences

  • WebSocketListener does not have any fallback transport.
  • WebSocketListener works in any operating system running .NET/Mono 4.5 or higher.
  • WebSocketListener does not define a method for scaling out, it is just an endpoint.
  • WebSocketListener cannot be hosted in IIS. You will need to run it as an external service, in a different port.