Please go to this address. It ought to work on mobile devices as well. I'll wait a second. And then either: 1. It looks like people are connecting, or 2. This is a complete failure, why did I try to do this?!
Let's Try WebSockets
Or Will the Wireless Fail Us Now?
Gratuitous Chat Application
Every article or presentation about WebSockets has got to mention chat applications, so I thought we'd get an example out of the way from the start. If you went to that link, then you ought see a form field where you can send a message up here onto the screen. Be nice.
Now that that is out of the way.
What just happened?
Or should have happened. ;-)
When the presentation slides changed a message gets sent to this big black cloud that then broadcasts it to your browser.
Then you sent message to the big black cloud and it forwarded them all on to my slides and displayed them on the big screen. So what's in the big black cloud?
A WebSocket serving running node.js and socket.io. I'll show you how simple that is in a bit. Let's talk about WebSockets.
But before we talk about the problem that WebSockets tries to solve, we really need to talk about HTTP.
HTTP is a request-response protocol. The communication always starts on the client side. Traffic can only flow in one direction. The server cannot send a message to the client without the client making the request.
So what are some solutions to these limitations?
There's polling, where the browser client makes request after request just in case there might be something on the server that's new. With basic polling this can mean opening up one connection after another until there's new data. But there's that polling interval.
With Long Polling the client makes a request and the server just holds open the connection open for as long as it can. If new data becomes available then the server responds. When the client gets some data, then the client fires off a new request. And the process continues over and over.
The time a message has to wait in the server before it can be delivered to the client.
The problem with both of these approaches is queuing latency. Even though this latency might not be much it is still present and depending on the application can really matter.
There's a lesser known API known as Server Sent Events where after the initial handshake creates a persistent connection, the server can continue to stream text to the client whenever it wants. The client can't use the same channel, but it can always just use regular AJAX. Some of what I've done here can probably be done with Server Sent Events which might be easier for you to get started with in some environments.
WebSockets are a standardised cross browser solution to real-time bi-directional communication between a server and a client.
After the initial handshake where the connection is upgraded, the client or server and send data whenever they want over a persistent connection. They can even send data at the same time.
This ends any latency that happens because of having to reopen a connection.
So it is a real full-duplex method of communication. Doge-approved.
WebSockets Message Payload
UTF-8 encoded text
It is possible to implement subprotocols over WebSockets if you need to.
You can send text or binary. So anything you want.
WebSockets sound great! Why not use WebSockets for everything?!
When you use WebSockets you lose caching, state management, and other services that XHR and HTTP in the browser give you for free. WebSockets force you to make decisions about how to handle these things.
Use the right protocol for the job.
What are WebSockets good for?
Social networking apps
Anything that needs to be real-time on the Web
Anything like collaborative editing and HTML5 games where everything needs to be real-time.