The second session of my day at DDD Southwest was a talk by Chris Alcock of The Morning Brew about Web Sockets, a new web standard for real-time communications between a web server and a page on a client browser, and SignalR, an open source library that make use of web sockets.

N.B. The section of Chris’ talk on Web Sockets and how they work is better fleshed out here on DeveloperFusion than the notes below.

Q: What do we mean by real-time web applications?
A: Time-dependent applications such as the stock market and weather.

Q: What do we mean by interactive web applications?
A: Applications such as chat and auctions (which are also real-time) which work only with users communicating with each other.

Q: How do we handle these communications?
A: Currently we use periodic refreshes from the browser client to update what a user sees but it takes place at the page's\user’s discretion which is a bit rubbish. Long polling works a bit better. Flash is also a possibility.

Web Sockets? What? When? How?

A new option in real-time web communication has appeared called Web Sockets. A Web Socket connects two computers - client and server.

  • It is a web standard – RFC6455
  • W3C defines the WebSocket API as a draft standard and part of the wider HTML5 standard.
  • Currently there is limited support for it. The RFC version (there were 12 pervious versions) is only supported in a few recent browser versions. IE10, FF11, Chrome16, Opera

How do they work?

  • Over normal web requests, so firewall friendly. Port 80, 443 using ws:\\ and wss:\\ respectively.
  • Request includes the upgrade header to notify this is a web socket request.
  • Coms are two-way a la traditional sockets & can stream data.
  • Supports cross-domain requests.

After the initial handshake, the socket is left open for communication. Your proxy server will need to understand this.

Web Socket Client API

The Web sockets API has a straightforward set of functions

  • new WebSocket(url)
  • onopen
  • onclose
  • onerror
  • onmessage
  • close
  • send
  • readystate (enum - Connecting, Open, Closing, Closed)

Web Socket Server Support

  • Many implementations are available
  • For .net developers, web sockets are only supported in IIS8 on Windows 8 (they require lots of changes to HTTP stack). NB IIS8 Express on Windows 8 does not support it.
  • .net 4.5 adds two new important members to the HttpContext class
    • HttpContext.IsWebSocketRequest
    • HttpContext.AcceptWebSocket
  • nuGet Microsoft.WebSockets package for ease of development.

When to use Web Sockets...

  • Only modern browsers support Web Sockets as a client API. “Polyfills for ws” such as do exist however.
  • Windows 8 is required to act as a web sockets server.
  • You won’t be able to host a Web Socket server in the Azure cloud until after Windows 8 has been deployed to the cloud.
  • Performance is good though - you control the messages sent.

SignalR. What? When? How?

SignalR is an async library for .net to help build real-time, multi-user interactive web apps

  • on github, v0.5
  • It is not an official MS project. Damian Edwards and David Fowler team leads (both from ASP.NET team)
  • Available on nuGet
  • Runs on Mono
  • Requires .net 4.0+
  • Uses Dynamic typing, TPL, jQuery and more.
  • Two types of connection (persistent like web sockets and hub)
  • Supports multiple methods of connecting (long polling, websockets, forever frame (IE only), server sent events
  • More than just one connection (seamless)

SignalR supports persistent connections with a similar API to WebSockets (see docs on github)

It also supports a more interesting Hub API

  • The Hub API is a RPC-like implementation.
  • It allows you to make method calls from server on the client and vice versa
  • It allows you to share variables between the two
  • Server implementation uses hub base class
  • Dynamic types are used for proxy
  • SignalR Clients vary how API is presented.


  • Methods are dynamic so intellisense is not available.
  • SignalR requires two scripts - jquery.signalr.js is the base library. signalr/hubs/ is where we implement the hub connections.
  • SignalR deals with calling pascal-cased methods on the server (e.g. Reflect) with camel-cased methods on the client (e.g. reflect)
  • Don't use a folder called signalr in you own app as SignalR reserves that folder for its own use and things won't work.

Notes on Implementing A Hub

  • You must wire up your client side code before connecting .
  • A new hub instance is required on each request so you can't store hub member variables to store state.
  • Transports can timeout and thus disconnect - makes for odd debugging experiences
  • Server has lots of concurrent connections so it will need optimizing. See github docs for a guide.

There are several SignalR clients - five are included with SignalR and there are several third party ones.

SignalR Hosting Options

  • Win/Mono
  • ASP.NET, Self Host, OWIN
  • It can scale out to Webfarms (Redis, Azure Queues)

WebSockets is an available transport for SignalR, but only on Win8 for reasons noted earlier. Also note that currently SignalR on Web Sockets is broken in the v0.5 build but there is a workaround available on the github site.

The slides for this presentation are available at