The future of illusively responsive web apps is here. Actually since December 2009 when Google released their version of Chrome, WebSockets have been available to play around with. Connecting and communicating with a server from a regular web page is now as easy as:

This opens a bi-directional connection to a server, allowing messages to be sent between a client (i.e. the web page) and a WebSocket server (this example) without the overhead introduced by opening a new connection for every single call. Up until now, this kind of behavior could only be achieved by Ajax requests combined with various tricks. This in order to keep a session open and not close immediately after a message has been sent and received.

The result of this is blazingly fast communication between a server and one or many connected clients. Here’s a video I recorded where two audio clients, i.e. web pages with websockets, are connected to an audio server which is using the Spotify library to stream music. Look at how they’re really in sync! And remember that each command produced by moving the slider is sent to the server, parsed and then sent back to the other client. This almost without any noticeable lag:

There are already some projects out there that attempts to provide a server solution. Many of them exists merely to illustrate the concept, but we’ll definitely see some real implementations popping up very soon. The aim with this post was to do as little as possible in order to get a message sent from Chrome to pass through a Python socket setup and bounce back to the browser.

To get this working we need some background details to get the implementation right. Firstly, there is the WebSocket API Draft. This is what has been implemented in Chrome and specifies how to connect to the socket via Javascript on our web page:

Secondly there is the Websocket Protocol which is currently at the draft stage but has gone through 74 iterations as we’re speaking. The protocol tells us how to wrap and extract messages sent to and from our server. In the protocol it is stated that a header like the following raw text shall be sent from the client, in this case Chrome. So this is what we’ll recieve at the server socket:

GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample

Our server shall then consume this text, validate it, and answer by sending the following back to the client:

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol: sample

If this so called handshake doesn’t look right to the client, it will close the connection. So it’s important that WebSocket-Origin and WebSocket-Location is copied from the first message exactly as stated. Otherwise Chrome will suspect that something is fishy and cut the cord.

And the code for out Python server looks like this:

As you might notice, I make use of the low-level socket library in Python. A message sent from a client is stripped from surrounding tags (00 and ff), and sent back with the same padding. Several messages can be read in the same 128 byte chunk and split into the correct amount of validated messages. The remaining bytes are saved until the next read.

This implementation is rather useless by itself. However, it demonstrates the Websocket which really has the potential to revolutionize future web apps. Hopefully by not getting more advanced than this, some basic understanding about the communication flow can be learned.

To get more inspiration for your Websocket implementation there are some nice code out there which will get you up and running with both Python and Node.js as backend