In the last post we discussed how digital multiplayer games have evolved, various strategies for getting different game clients to keep their games in sync, and why the core HTTP request/response architecture of the web was fundamentally flawed when it came to multiplayer games. In this post, we’ll dig into the HTML5 solution to this problem and how to use it in desktop or mobile web applications.
At the lowest levels, WebSockets do piggyback on top of the World Wide Web infrastructure (hence the name). They follow a URL scheme, similar to the ubiquitous HTTP definition. Since the underlying protocol is different from HTTP, however, the URL scheme begins instead with a new label: ‘ws‘ (for unencrypted streams) and ‘wss‘ (for encrypted streams). For example:
If you’re running your own web servers, you’ll need to have a program running on the backend to handle WebSocket requests such as these. Apache’s ActiveMQ project is one example of WebSocket-aware server software. A full discussion of the pros and cons of various server configurations and software packages to handle WebSockets is beyond the scope of this post.
If you are running in an environment that supports WebSockets, interacting with one on the client side is delightfully simple. Read more…
Yes, Universe, you’re absolutely right. We should consider Android devices as well.
The world works in mysterious ways. Literally as I was in the middle of writing up that last post, my Google+ feed exploded with the news that Google has released a version of Chrome for Android. This is supergreat news for HTML5 development on Android and I’m thrilled. Really. I’m not at all upset that I probably need to go get myself an Android phone now, and neither is my wallet. More to come, this is a pretty major development for HTML5 mobile apps, seriously.
[UPDATE] Mashable is pointing out that only about 1% of Android devices have Android 4.0 on them and thus can support (this release of) Chrome. At least that makes the device testing simpler, doesn’t it?