We’ve already seen HTML5 killing few technologies on the presentation side – Adobe Just killed Flash for Mobile, and Microsoft ‘Positioned’ Silverlight as a tool for LOB apps and Phone apps instead of a cross platform presentation layer.
As most organizations are now focusing on HTML5 as part of their next gen strategy for what ever reasons (mainly cross platform), it is pretty obvious that there is going to be wide spread adoption from all major user agents – and more importantly, a lot more tooling and frameworks will evolve for developing HTML5 applications (You might have already explored previews like Expression Blend for HTML5 if you are in the Microsoft World, along with improved support for HTML5 in VS). The evolution of HTML5 will definitely bring in a radical shift in the way we develop web applications as we have already seen – and a nice little part of the parcel is Web sockets - which allows you to implement full duplex TCP based communication between the user agent (browser) and the server.
The problem with HTTP and existing server stacks
Here is a short description of HTTP from W3C
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP works in a request/response way – The client should always initiate a request to obtain the data, and in other words, the server can never push data real time to client. A common work around is to use HTTP long polling, where the client makes a request, and the server holds the request till some data is available, and pass it back to the client. I believe from Http 1.1 onwards, persistent connections are the default behavior of the HTTP connection anyway – though the response/request HTTP model don’t allow the server to do real-time pushes.
HTML5 draft specification includes Websockets - http://dev.w3.org/html5/websockets/
WebSocket is a technology providing for bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket. It is designed to be implemented in web browsers and web servers but it can be used by any client or server application. The WebSocket API is being standardized by the W3C and the WebSocket protocol is being standardized by the IETF.
This is very interesting, because it opens up lot of possibilities. For example, I did a quick prototype for desktop windows streaming over web sockets here. Most importantly, with Web Sockets, web applications can be real time and can even have custom RPC implementations.
With web sockets, which are fully duplex, you have some thing state full, which will allow you to build web applications which can satisfy real time requirements. This means better user experience, better speed, and overall better productivity. We’ll see a new range of web applications emerging, including more sophisticated games and better real collaboration tools. We’ll definitely see more matured and domain specific light weight RPC frameworks for servers and clients (As of now, I think frameworks like NowJs/Socket.IO on top of Node and SignalR on to of IIS already has this in their implementation/roadmap in a general way - to wrap web sockets and has a fall back strategy on HTTP long polling if the client is not supporting web sockets yet).
According the Web Socket API spec, when a web socket connection is made,
The headers to send appropriate cookies must be a
Cookieheader whose value is the cookie-string computed from the user's cookie store and the URL url; for these purposes this is not a "non-HTTP" API.
Anyway, most of the current server stacks and related programming models, including LAMP, IIS/ASP.NET etc is modeled around the normal request/response HTTP stack -and once the focus on Web sockets increases, they need to optimize themselves to handle concurrent connections simultaneously with out affecting the performance. A new age web server may be almost like a re-labeled IRC server which can handle a number of real time connections simultaneously (On contrary, you may also argue that HTML5 web sockets may make IRC servers obsolete as well).
Web Socket API specifications are not yet finalized. And as of now, based on http://caniuse.com – the following client side platforms are supporting Web Sockets specs. Between, I use http://caniuse.com often to see the platform adoption of HTML5 APIs and Semantics.
I think, to some extent, this means a radical shift in the way we write web applications which need real time features. More importantly, you can bend the web in a better way – because you’ve access to a transport layer protocol (TCP) on top of which you can build your own custom/domain centric protocols, instead of getting constrained with the application level HTTP protocol. Also, I am pretty sure that most of the client side agents other than web browsers will also start supporting web sockets in no time.
A Quick word on Server Side Events
As you read this far, it might be interesting to note that HTML5 specifications has another API named server side events (SSE), which allows you to Push data from server to client via an HTTP channel.
This specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.
Anyway, Web Sockets are getting more attraction because it provides more control as it is on top of TCP, and more importantly, it is bidirectional. And what ever you can do with SSE can be implemented using Web Sockets, with a bit of custom code.
Here are few links to follow.
- Checkout this example of Web Sockets - This is a quick example that shows how I’m streaming WPF windows over web sockets to a browser, to draw it in a canvas
- The Web Socket API – From W3C
- A nice post from Michael and Related Discussion – About Long polling vs Streaming approaches.
- NowJs/Socket.IO on top of Node and Signal If you are .NET developer
- Here is one of my previous posts on getting Node working on IIS on Windows
Happy Coding, but beware, HTML5 is just near your door. Chances are that, pretty soon, almost half of the things you do today with classic HTTP stack will be replaced with wrapper implementations like NowJs or SignalR.