Most of the WebSocket discussion I’ve read has been highly technical: people who love protocols discussing how to upgrade HTTP to a fully-interactive messaging system. But the technical discussion may be obscuring how potentially transformative WebSockets might be. While I never understood the Web 2.0 hype, WebSockets has the potential to be a legitimate Web 3.0 technology.
In one sense, that capability isn’t new: online interactive games like World-of-Warcraft are far beyond a simple game of pong. Yet, browsers are still limited to HTTP request response, and hacks like AJAX and Comet. It’s like browsers are still using decades-old technology. Now, I’m not quite suggesting turning the browser into a universal game engine, but the current browsers are still crippled by the inadequate request-response client/server model of HTTP. It’s past time to break those limitations.
WebSockets essentially does three things: it improves interactivity by acting on messages instantly - not waiting for a poll, it elevates clients as fully capable of responding to events - clients become actors, and it improves responsiveness by eliminating wasteful housekeeping bandwidth.
To make the game of Pong work, both the browsers and the servers need to upgrade to handle WebSockets. On the server side, Resin provides a Java API to handle messages from clients as soon as they’re available, and forward or process the messages to other clients. The Pong application on the Resin server would act like the referee, handling the ball bounces, and keeping score.
When the California Pong player moves the Pong paddle up, the browser needs to send a message to the Resin server, updating the referee and the game physics. Resin will then process the request, update the ball motion, and send any game updates to the California and New York players. The messages need to happen as quickly as possible so people can immerse themselves in the game. This isn’t play-by-mail chess.
Server and client applications could become more critical and interesting than with HTTP apps, because the demand for each user is greater. Instead of simple GET requests every few seconds returning formatted text pages, each micro-request is a tiny action message telling another actor to do something: move a paddle, bounce a ball, update a score. The web becomes active: not semi-passive as it is today.
Today, the engineers who love the plumbing at the base of the web see the possibility and excitement that WebSocket may bring to the web. And now we’re beginning to see clients like Chrome and servers like Resin bringing the new capabilities to life. The best part is when creative engineers take WebSockets and write the messaging and application code to show the non-engineering world what can be created with a few new low-level technical powers.