Tuesday, September 16th, 2008p>Joe Walker of DWR fame on Comet at @media Ajax.
Motivation for Comet
Interested in what our friends are up to, even if no-one else cares (as twitter illustrates). And also interested in what systems/things are doing, not just people. Chat (meebo), collaborative editing (google docs), streaming financial data (lightstreamer), async updates (yes.com), online gaming, async server processing (polar rose, i.e. shift processing complexity to the server – note this could be seen as an alternative to Gears-style local processing in some situations).
The web was designed to be connectionless – Comet blatently aims to make it connected.
Actually does scale. Joe shows the following graph:
Seven ways (!) to implement Comet.
Long polling – “slow” XHR request. Server doesn’t answer immediately. Special part of HTTP to do this – chunked mode. However, IE “lies to you” – keeps saying it’s got something, but you can’t actually inspect it.
Forever frame – Send text/plain and 4k whitespace to flush IE’s buffer. Flush with script tag for each data block. Must keep restarting to avoid memory leak.
Script tags – Dynamic script blocks, can point to any domain.
WebSockets – HTML 5 standard. Cleaner solution.
Mime messaging – “What push was built on 11 years ago” – x-multipart-replace. Works really well, though with memory leakage issues, but not in IE and historically not in the other browsers either.
Forever GIF (bonus technique) – keep sending out new slices of an animated GIF!
Co-ordination when browser has multiple tabs open to the same server – using window.name or cookies, but better solution is multi-home DNS – each call points to the server using a different name (1.example.com, 2.example.com etc all pointing to the same IP address).
Issues detecting when browser or connection has broken.
Proxies which don’t let the stream go through in real-time – hold on to the chunks for a while before releasing them all at once. Can detect if this is happening from the browser using a timestamp technique.
… so just like with Ajax, we have to come up with hacks, likewise with Comet. Facebook and GMail show it’s possible to work around these problems and get Comet working at scale.
e.g. with WebSocket you’re simply posting and receiving data. Event handlers for onOpen, onRead etc. Joe says this will be too low-level in many cases, hence the following styles.
PubSub – e.g. cometd. Low coupling (server-browser separation – Joe describes demo where servers hot-swapped without affecting client), inter-language interop. Good analogy to SOAP, which has gradually shifted from RPC to document exchange.
API – this looks to me like Ruby’s remote JS – server controls what’s happening on the browser. e.g. Effect.shake(“price”) on the server will make the price div shake on the client.
Data Syc API – Keep changing/updating data store. Simplest to understand.
Posted by Michael Mahemoff at 4:27 am