theChrisWalker.net

I only found out about these at the Future of Web Design on Tuesday. I knew they existed in the spec but had never really investigated what they were or how they worked. Now I know I am excited. It seems they are to web apps what the XMLHTTPRequest was when it started to get used for AJAX. So let’s look at what they are, and then why they can be so beneficial to web development. It’s also worth pointing out at this stage that only Chrome 4+ (I think that version, I’m writing from memory) supports WebSockets natively although apparently Mozilla want to implement them in the next iteration of Firefox (they are already available with an add-on), so don’t expect to be using them in any non-specialist projects just yet.

What are WebSockets?

WebSockets are a connection that the browser makes to a server. Unlike a normal HTTP request, this is not a simple “send request”, “receive response” connection. This is a persistent and full-duplex connection. They can run over port 80 (or 443 for a WebSocket over TLS/SSL) and so have little difficulty with firewalls. There are some concerns over their interaction with proxies, particularly transparent ones. Once the browser sets up the WebSocket, you can send UTF8 text over it, and receive text data from the server. All this sending and receiving over data requires no more headers and only a 2 byte overhead per message.

Why are they going to be so useful?

It’s really the last sentence of that last paragraph that is important. The problem is trying to get data from the server when it’s available. Web apps using AJAX (or similar techniques), have to ask for data and then get a response, i.e. polling for updates or using Comet-like long polling techniques – where the request is made and the connection opened but the response is delayed until the server decides it has something useful to say. The Comet technique allows much better real-time updates from the server, but there’s still the overhead of the HTTP request headers and then the response headers/content.

WebSockets aim to alleviate both issues. Once the socket is open, data can flow from the server to the client whenever the server decides it wants to. Also the client can send information to the server without have to send any extra headers, any info it receives from the server is also header free and therefore the process is very efficient. HTTP headers tend to bulk up with Cookies and remain the same size irrespective of the payload sent.

Do you have an example I can actually use?

I do, but it’s not exactly ready for distribution yet. I built a very basic chat client that uses WebSockets as a demo for myself. The hardest bit was writing a socket server in PHP that could handle multiple clients and manage the broadcasting of data to them. I will post all the code in part 2 — watch this space! (in the mean time a search for “websocket” on Google Code will find you some examples (it’s what I based my code on…)