At the Forge - Communication in HTML5

One of the greatest contributions of UCB (Berkeley) to the UNIX
operating system was the introduction of sockets. Sockets allowed
programmers to open a connection to another
computer easily and quickly. Once opened, the socket operated something like a
point-to-point file handle, allowing you to ignore the fact that data
in the socket was being transmitted through dozens or hundreds of
other computers. A large number of Internet services, from SMTP to
FTP to HTTP, use sockets. I personally have used them for nearly 20
years to implement everything from my undergraduate thesis, to Web
browsers and servers, to various Internet-enabled applications.

HTML5 brings socket-like connections to the browser, using a
technology called WebSockets. WebSockets are similar in principle
to UNIX sockets, in that you can open a connection to an arbitrary
other point on the Internet, and send and receive data reliably without
even considering the numerous hops or connections along the way.

Now, if you are an experienced Web developer, you might be
wondering what the big deal is. After all, Ajax calls allow you to
open HTTP connections and send and receive data. And xhr (the
XmlHttpRequest function) has been around for a few years, and it works
quite well. The difference is WebSockets will allow you to open
one or more connections to anywhere on the Internet, not just to
servers with the same origin as the current page. Moreover,
WebSockets use their own protocol that is admittedly quite similar to
HTTP, but it has a great deal less overhead. Finally, WebSockets
remain open as long as the sides agree to do so—as opposed to HTTP,
which is meant to be stateless and to be closed after a single
request-response transaction. For all these reasons, communication
using WebSockets generally is going to be far more efficient. A
number of articles describing WebSockets have done the math and show
just how much more efficient WebSockets are than HTTP—and the
difference is staggering.

Working with WebSockets is remarkably simple. You open a WebSocket
with some JavaScript code, often (presumably) fired either when a user
performs an action (such as pressing a button) or when a certain event
takes place (for example, a certain amount of time has elapsed). No matter
what, you open a new WebSocket by specifying the URI to which you want
to connect, starting with a protocol name (either ws or wss, for
unencrypted or encrypted, respectively), continuing with the hostname,
and then ending with a resource name.

Once the WebSocket is open, you can attach callbacks to it, indicating
what should happen when the socket is opened, closed or receives a
message. (Each time the WebSocket receives data from the remote host,
it will invoke the “onmessage” callback function.)

For example, here's a simple WebSocket that retrieves data from a
hypothetical weather server:

Finally, you can send messages by invoking the send() method—yes,
the same method that you saw above, but without the second parameter
indicating the origin.

Notice that although you write directly to the WebSocket using send, you
don't read a result directly from it or via a return value to send().
Rather, you will get the data when it is sent to you, via the execution
of your method at weatherSocket.onmessage().

One piece is missing from this description, namely a server to
which the WebSocket connects. You cannot connect to just any old
server on the other end, and especially not to an HTTP server.
Fortunately, a growing number of packages (in various open-source
languages) can handle the server side of WebSockets. One such package
is the em-websocket gem for Ruby, based on the well-known
eventmachine gem. WebSocket server libraries already exist for
PHP and Python, as well as a number of other languages. Over time, I
expect to see a number of WebSocket-compatible servers
emerge.

How can you use WebSockets? As with interwindow communication, I
expect the best applications and ideas haven't been
developed yet. But once your Web browser can connect to any host on the
Internet using a specialized high-performance protocol, you can
imagine that the sky is the limit. Suddenly, Web-based chat servers no
longer need to use kludges or hacks in order to allow for real-time
chat. You can create mashups on the client, rather than the server.
Combined with the new geolocation facilities in HTML5, you can have a
map that updates your location in real time, using nothing more than
HTML and JavaScript. It does mean that on the server side, Web
applications now will require more than just installing Apache, but
that has been true for a while now, as applications have become more
sophisticated, so I don't think you need to worry about that too much.

Sponsored by:

Geek Guides

Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.