Is it over yet?
- What is Comet?
- Why do I care?
- How does it work?
- Who's using it now?
- Where can I find out more about it?
In the beginning...
- ...there was HTML
- HTML - HyperText Markup Language
- document-centric
- high latency due to full page loads only
- coarse-grained interactions with the server
- multi-user from the beginning
Next came...
- AJAX - Asynchronous JavaScript And XML
- allowed fine-grained interactions from browser to server
- reduced latency for a lot of client-initiated interactions
- no need for full page load every time
- only pull data for and refresh the parts of the page that required update
- does not provide for server-initiated interactions
Enter the Comet
- COMET - C O M E T
- Not an acronym; just a meme
- allows full bidirectional, asynchronous communication between browser and server
- Term coined by Alex Russell of the Dojo toolkit
- harkens back to the dot-com hooplah about "server push"...
- ...except that Comet is more real than hype
- has nothing to do with PointCast
Hustle and Flow
© Alex Russell
So?
- Comet brings multi-user to the low-latency Web
- apps can update all interested parties as things happen
- potential applications include:
- chat
- conferencing
- multiplayer games (10-way live Go Fish action!!)
- auctions
- tickers
- monitoring
- etc
Long Polling
XMLHttpRequestconnection is opened back to the server- once server sends, connection is closed and then immediately reestablished
- server can send multiple datagrams in one connection to reduce load
- somewhat higher latency due to connection establishment/teardown
- can have problems dealing with lots of push messages
- good if your app can deal with some lag
Persistent Frame
- incremental rendering in browser evaluates new messages from server
- iframe receives inline script tags from persistent connection
- those tags call function(s) in parent frame to update view
- also called a "forever frame"
- most portable method
- can connect to subdomains, too
- this is the de facto standard these days
Flash
- Flash's
XMLSocketcan act as a persistent bridge between browser and server - can use
crossdomain.xmlto do cross-domain calls, too - proprietary
- can't ensure Flash will be installed/enabled/work right
Multipart XMLHTTP
- persistent connection opened to server (chunked transfer encoding)
- server can then just push data to browser and it will evaluate it as needed
- great method if it will work for your situation
- not portable today
- IE and FF differ (big shocker there)
- Safari does not support this at all
Toolkits using Comet
- Dojo - dojo.io.cometd
- Juggernaut for Ruby on Rails
- uses Flash method
- Grizzly/Glassfish for Java
- this guy hacked it into Google Web Toolkit
Related Stuff
What about the server?
The Rise of COMETd
- combination of server, protocol and JavaScript libraries
- being implemented by lots of projects
- Grizzly
- Twisted
- Jetty
- Perl cometd
- Bayeux is their JSON-based protocol for event pub/sub
- hopefully will make it much easier to get a Comet app developed and deployed
Oh, the scale...
- Comet will require handling tons of concurrent connections
- lots of those connections will be idle at any given time
- processes and OS-level threads don't scale to the numbers of sockets Comet apps will need
- newer multiplexing techniques can handle the load: epoll(4), kqueue(2), Solaris' /dev/poll and ports, etc.
- Erlang has been taking one for the team on this point for over 20 years
Its not all wine and roses
- may require multiplexing logical services down the same physical connection
- two connection limit in browsers today
- may require some DNS hacks to get multiple domains working together
- subdomains, wildcards, etc
- browsers are just now coming to grips with AJAX apps
- lots of code may load and run slowly
- can cause stability issues and crashes
- can leak memory
- intervening proxies will snap off long-idle connections
- have to "recycle" connections periodically
Who is using it?
- A bunch of apps, actually:
- GTalk in GMail
- GDocs (formerly Writely)
- Renkoo
- cgi:irc
- Meebo
- KnowNow
- JotLive
- ConceptShare
- Lingr
- NOT Campfire
- they are just polling really often
- Lets take a quick look at how Lingr does Comet
Lingr
- Lingr is a Web 2.0, realtime chat application with some community features
- they use a Comet-based architecture to pull this off
- even have an API and everything
- really open with the backend process on their blog
Lingr Architecture v1
- main Web platform is Ruby on Rails
- use persistent frame style of Comet (dynamic
<script>tags and JSONP, similar to Dynodes) - all requests first shunted to a Jetty cluster
- Jetty 6 Continuations allow them to keep track of connection state between events
- persistent connection to the Jetty cluster for real-time updates
Lingr Architecture V2
- But, this had some trouble
- previously, all requests went through Jetty
- in V2, only the Comet-required requests went through Jetty (
observe) - all others go directly to Rails cluster
- this relieves load on the Jetty cluster but had to implement notifications between Rails and Jetty clusters to keep in sync
Lingr Architecture Now
© Lingr
Uh, are you finished yet?
- Comet holds a lot of promise for bringing real-time collaboration to the Web
- some kinks left to be worked out on the browser side
- new expectations of load and load profiles on the server side will force more scalable server technologies
- plus, we users get cool new apps