Saturday 19 December 2009

WebSocket, js.io and replacing Comet

The prototype of my web-based game client uses Comet for the client-server communication. Recently, I have encountered more and more articles about WebSocket. As it is a cleaner and simpler way of doing what Comet does, I decided to look into the feasibility of adopting it now.

The options

Using WebSockets is not an option at this time. They are not supported to a level which makes them a viable solution, and only bleeding edge versions of the major browsers currently have the required support.

However, there is another possibility. That is, to use a solution which emulates the WebSocket interface as a layer over Comet. I've stumbled across two candidates in my browsing, the first being Kaazing Gateway, and the second js.io. I imagined that adopting one of these, or something similar, would enable me to write cleaner, simpler code that was future proof.

Possible solutions

I can write off Kaazing Gateway immediately. As a commercial product with a large download, the cost of adopting it is immediately higher than I am willing to pay. While it may suit the needs it was designed for, for my needs, there is no reason that the code required should not be lightweight and minimal.

js.io sounded much more promising. However, as a project, it is in a state where its usage is opaque and unclear to interested parties like myself. There is no documentation and the web site refers the user to the source code. It turns out that it both does and does not provides what I am looking for, but the latter aspect was also partly based on my lack of comprehension about the full range of functionality provided by WebSockets.

Researching js.io

Ideally, I wanted a client-side script that simply wrapped the Comet functionality, and allowed it to be used through a WebSocket interface. At least until using WebSocket itself became a viable option. Despite descriptions I had read of js.io painting it as something resembling this, I was unable to find anything within the existing browsable source code which looked suitable.

However, one of the many web searches I did found an older obsoleted script. It turns out that the earlier version of js.io provides exactly what I am looking for. Well, almost.

The earlier version of js.io layers on top of other solutions which provide a required TCPSocket object, specifically Lightstreamer and Sprocket. The default implementation of TCPSocket, which js.io falls back on looking for, is the one provided by Orbited. Unfortunately, these solutions are servers and frameworks, which are too heavyweight to be suitable for my needs.

What next?

Gutting Orbited is one option, but then I am effectively forking it, and the onus is on me to keep an eye on fixes and changes its maintainers make. Probably the best choice at this stage is to stick with Comet.

6 comments:

  1. I've been using web-socket-js on my project. It makes the WebSocket object available in Javascript on any client that supports Flash (since Flash can already handle sockets). Definitely worth a look: http://github.com/gimite/web-socket-js

    ReplyDelete
  2. Unfortunately for me, I find Flash to be an unacceptable solution. Most things I use written in it (I do not play games) seem to be clunky and awkward, given its lack of integration with the web browser.

    ReplyDelete
  3. Your post is EXACTLY what I want.
    I too skipped on Kaazing due to it's commercial nature and large size.
    ape-project.org also claims to have WebSocket emulation support that uses comet, but it too was a pretty large download and large server side component just to get WebSocket support.

    I've had experience with Orbited in the past, so I was able to get js.io + orbited working with WebSocket emulation.
    However js.io's emulated WebSocket doesn't quite match the spec and the comet part of Orbited has some difficulty working in certain browsers when you have multiple domains (like comet.product.com and product.com). If you use a different port than 80 on the same domain your good, but then firewalls start to block you because your not on port 80.

    In the end I chose to just go with Flash even though I hate having to use flash for anything. I hear din my head how like 95% of browsers have flash installed so hey, it should be fine.
    I was SHOCKED at how many people didn't have flash and can't use the site because of it.

    I'm still using the flash websocket emulation for now though until I can come up with a small sized comet emulation.

    I think I have to just break down and look at the low levels of comet techniques, and implement something minimal and small for each browser one by one.

    ReplyDelete
  4. Thanks for the feedback Robert, it is good to hear some detail from someone who has gone further than me in this.

    ReplyDelete
  5. So I'm very determined to get WebSocket support for all browsers.

    1. Use native WebSocket if available
    2. Fall back to WebSocket emulated with flash if flash is available
    3. Fall back to js.io emulated WebSocket over a comet server as a last resort

    I'm working on that last part now. Due to the problems I've been having with orbited, I'm looking into use Apt-Project's TCPSocket support and writing WebSocket emulation on top of that.

    ReplyDelete
  6. There has been a ton of progress relating to js.io, Orbited and comet libraries recently. In particular, Orbited is in the process of switching to comet session protocol which is designed to be a fallback protocol for browsers without flash or websocket: http://orbited.org/blog/files/csp.html

    There is already two python implementations, one for twisted and one for wsgi/eventlet.

    Please send me an email if you want help or details, as most of this is sort of under the radar.

    ReplyDelete