Simon Willison's Weblog: comet

Why does Facebook chat use subdomains so aggressively?

2011-01-10T11:57:00+00:00

My answer to Why does Facebook chat use subdomains so aggressively? on Quora

Probably because it involves long-running connections. Browsers have a limit on the number of connections you can have open to the same domain at the same time (I think it's 8 in most browsers these days). If Facebook chat opened a connection to www.facebook.com and you opened up 8 Facebook windows you would no longer be able to navigate to any more Facebook pages, since all 8 connections would be taken up by the long lived chat connections. By connecting to a different subdomain for each connection this problem can be avoided.

Tags: comet, javascript, quora

What is the history of Django?

2010-08-24T17:31:00+00:00

What is the history of Django?

I’ve been playing with Quora—it’s a really neat twist on the question-and-answer format, which makes great use of friends, followers and topics and has some very neat live update stuff going on (using Comet on top of Tornado). I just posted quite a long answer to a question about the history of Django.

Tags: comet, django, history, tornado, quora, recovered, qna

Hookbox

2010-07-29T09:48:00+00:00

Hookbox

For most web projects, I believe implementing any real-time comet features on a separate stack from the rest of the application makes sense—keep using Rails, Django or PHP for the bulk of the application logic, and offload any WebSocket or Comet requests to a separate stack built on top of something like Node.js, Twisted, EventMachine or Jetty. Hookbox is the best example of that philosophy I’ve yet seen—it’s a Comet server that makes WebHook requests back to your regular application stack to check if a user has permission to publish or subscribe to a given channel. “The key insight is that all application development with hookbox happens either in JavaScript or in the native language of the web application itself”.

Via Comet Daily

Tags: comet, django, javascript, michael-carter, php, rails, webhooks, recovered, hookbox

App Engine at Google I/O 2010

2010-05-20T15:30:00+00:00

App Engine at Google I/O 2010

OpenID and OAuth are now baked in to the AppEngine users API. They’re also demoing two very exciting new features—a mapper API for doing map/reduce style queries against the data store, and a Channel API for building comet applications.

Tags: comet, google, google-app-engine, mapreduce, oauth, openid, google-io, recovered

Realtime Election Tweets

2010-05-06T21:20:00+00:00

Realtime Election Tweets

Jay Caines-Gooby’s realtime election tweet service, using Node.js, nginx and WebSocket with a Flash fallback.

Tags: comet, flash, javascript, nodejs, realtime, twitter, websockets, recovered, election, jay-caines-gooby

Lou's Pseudo 3d Page

2010-02-08T11:21:18+00:00

Lou's Pseudo 3d Page

Spectacularly detailed exploration of the road graphics used in racing games prior to true 3D. This is a potential gold mine for anyone looking for a fun project to try out with canvas. Bonus points for comet integration—I’m still looking forward to the first real-time multiplayer game in the browser using comet and canvas.

Tags: 3d, canvas, comet, game-design, graphics, html5, javascript

Comet (long polling) for all browsers using ScriptCommunicator

2010-02-03T00:37:34+00:00

Comet (long polling) for all browsers using ScriptCommunicator

More Comet from the Plurk team: 80 lines of dependency free JavaScript implementing long polling using script tags (hence working cross-domain) across IE6+, Firefox, WebKit and Opera. The clever bit is the code to detect loading errors. It doesn’t try to fix the infinite loading indicator problem—is that still a cromulent usability concern?

Tags: comet, javascript, long-polling, plurk, usability

Plurk: Instant conversations using Comet

2010-02-01T10:13:14+00:00

Plurk: Instant conversations using Comet

Plurk’s comet implementation sounds pretty amazing. They’re using a single quad-core server with 32GB of RAM running 8 Node.js instances to serve long-polled comet to 100,000+ simultaneous users. They switched to Node from Java JBoss/Netty and found the new solution used 10 times less memory.

Via Hacker News

Tags: comet, java, javascript, jboss, netty, nodejs, plurk

Web Sockets in Tornado

2009-12-31T11:54:48+00:00

Web Sockets in Tornado

Bret Taylor has a simple class making it trivial to experiment with the Web Sockets protocol (now shipping in Chrome) using the scalable Tornado application server. He also raises the million dollar question: what will existing load balancers and proxies make of the new protocol?

Tags: bret-taylor, chrome, comet, python, tornado, websockets

Real time online activity monitor example with node.js and WebSocket

2009-12-08T23:07:36+00:00

Real time online activity monitor example with node.js and WebSocket

A neat exploration of Node.js—first hooking a “tail -f” process up to an HTTP push stream, then combining that with HTML 5 WebSockets to achieve reliable streaming.

Tags: comet, html5, http, javascript, nodejs, websockets

Node.js is genuinely exciting

2009-11-23T12:50:22+00:00

I gave a talk on Friday at Full Frontal, a new one day JavaScript conference in my home town of Brighton. I ended up throwing away my intended topic (JSONP, APIs and cross-domain security) three days before the event in favour of a technology which first crossed my radar less than two weeks ago.

That technology is Ryan Dahl's Node. It's the most exciting new project I've come across in quite a while.

At first glance, Node looks like yet another take on the idea of server-side JavaScript, but it's a lot more interesting than that. It builds on JavaScript's excellent support for event-based programming and uses it to create something that truly plays to the strengths of the language.

Node describes itself as "evented I/O for V8 javascript". It's a toolkit for writing extremely high performance non-blocking event driven network servers in JavaScript. Think similar to Twisted or EventMachine but for JavaScript instead of Python or Ruby.

Evented I/O?

As I discussed in my talk, event driven servers are a powerful alternative to the threading / blocking mechanism used by most popular server-side programming frameworks. Typical frameworks can only handle a small number of requests simultaneously, dictated by the number of server threads or processes available. Long-running operations can tie up one of those threads - enough long running operations at once and the server runs out of available threads and becomes unresponsive. For large amounts of traffic, each request must be handled as quickly as possible to free the thread up to deal with the next in line.

This makes certain functionality extremely difficult to support. Examples include handling large file uploads, combining resources from multiple backend web APIs (which themselves can take an unpredictable amount of time to respond) or providing comet functionality by holding open the connection until a new event becomes available.

Event driven programming takes advantage of the fact that network servers spend most of their time waiting for I/O operations to complete. Operations against in-memory data are incredibly fast, but anything that involves talking to the filesystem or over a network inevitably involves waiting around for a response.

With Twisted, EventMachine and Node, the solution lies in specifying I/O operations in conjunction with callbacks. A single event loop rapidly switches between a list of tasks, firing off I/O operations and then moving on to service the next request. When the I/O returns, execution of that particular request is picked up again.

(In the talk, I attempted to illustrate this with a questionable metaphor involving hamsters, bunnies and a hyperactive squid).

What makes Node exciting?

If systems like this already exist, what's so exciting about Node? Quite a few things:

JavaScript is extremely well suited to programming with callbacks. Its anonymous function syntax and closure support is perfect for defining inline callbacks, and client-side development in general uses event-based programming as a matter of course: run this function when the user clicks here / when the Ajax response returns / when the page loads. JavaScript programmers already understand how to build software in this way.
Node represents a clean slate. Twisted and EventMachine are hampered by the existence of a large number of blocking libraries for their respective languages. Part of the difficulty in learning those technologies is understanding which Python or Ruby libraries you can use and which ones you have to avoid. Node creator Ryan Dahl has a stated aim for Node to never provide a blocking API - even filesystem access and DNS lookups are catered for with non-blocking callback based APIs. This makes it much, much harder to screw things up.
Node is small. I read through the API documentation in around half an hour and felt like I had a pretty comprehensive idea of what Node does and how I would achieve things with it.
Node is fast. V8 is the fast and keeps getting faster. Node's event loop uses Marc Lehmann's highly regarded libev and libeio libraries. Ryan Dahl is himself something of a speed demon - he just replaced Node's HTTP parser implementation (already pretty speedy due to it's Ragel / Mongrel heritage) with a hand-tuned C implementation with some impressive characteristics.
Easy to get started. Node ships with all of its dependencies, and compiles cleanly on Snow Leopard out of the box.

With both my JavaScript and server-side hats on, Node just feels right. The APIs make sense, it fits a clear niche and despite its youth (the project started in February) everything feels solid and well constructed. The rapidly growing community is further indication that Ryan is on to something great here.

What does Node look like?

Here's how to get Hello World running in Node in 7 easy steps:

git clone git://github.com/ry/node.git (or download and extract a tarball)
./configure
make (takes a while, it needs to compile V8 as well)
sudo make install
Save the below code as helloworld.js
node helloworld.js
Visit http://localhost:8080/ in your browser

Here's helloworld.js:

var sys = require('sys'), 
  http = require('http');

http.createServer(function(req, res) {
  res.sendHeader(200, {'Content-Type': 'text/html'});
  res.sendBody('<h1>Hello World</h1>');
  res.finish();
}).listen(8080);

sys.puts('Server running at http://127.0.0.1:8080/');

If you have Apache Bench installed, try running ab -n 1000 -c 100 'http://127.0.0.1:8080/' to test it with 1000 requests using 100 concurrent connections. On my MacBook Pro I get 3374 requests a second.

So Node is fast - but where it really shines is concurrency with long running requests. Alter the helloworld.js server definition to look like this:

http.createServer(function(req, res) {
  setTimeout(function() {
    res.sendHeader(200, {'Content-Type': 'text/html'});
    res.sendBody('<h1>Hello World</h1>');
    res.finish();
  }, 2000);
}).listen(8080);

We're using setTimeout to introduce an artificial two second delay to each request. Run the benchmark again - I get 49.68 requests a second, with every single request taking between 2012 and 2022 ms. With a two second delay, the best possible performance for 1000 requests 100 at a time is 1000 requests / (1000 / 100) * 2 seconds = 50 requests a second. Node hits it pretty much bang on the nose.

The most important line in the above examples is res.finish(). This is the mechanism Node provides for explicitly signalling that a request has been fully processed and should be returned to the browser. By making it explicit, Node makes it easy to implement comet patterns like long polling and streaming responses - stuff that is decidedly non trivial in most server-side frameworks.

djangode

Node's core APIs are pretty low level - it has HTTP client and server libraries, DNS handling, asynchronous file I/O etc, but it doesn't give you much in the way of high level web framework APIs. Unsurprisingly, this has lead to a cambrian explosion of lightweight web frameworks based on top of Node - the projects using node page lists a bunch of them. Rolling a framework is a great way of learning a low-level API, so I've thrown together my own - djangode - which brings Django's regex-based URL handling to Node along with a few handy utility functions. Here's a simple djangode application:

var dj = require('./djangode');

var app = dj.makeApp([
  ['^/$', function(req, res) {
    dj.respond(res, 'Homepage');
  }],
  ['^/other$', function(req, res) {
    dj.respond(res, 'Other page');
  }],
  ['^/page/(\\d+)$', function(req, res, page) {
    dj.respond(res, 'Page ' + page);
  }]
]);
dj.serve(app, 8008);

djangode is currently a throwaway prototype, but I'll probably be extending it with extra functionality as I explore more Node related ideas.

nodecast

My main demo in the Full Frontal talk was nodecast, an extremely simple broadcast-oriented comet application. Broadcast is my favourite "hello world" example for comet because it's both simpler than chat and more realistic - I've been involved in plenty of projects that could benefit from being able to broadcast events to their audience, but few that needed an interactive chat room.

The source code for the version I demoed can be found on GitHub in the no-redis branch. It's a very simple application - the client-side JavaScript simply uses jQuery's getJSON method to perform long-polling against a simple URL endpoint:

function fetchLatest() {
  $.getJSON('/wait?id=' + last_seen, function(d) {
    $.each(d, function() {
      last_seen = parseInt(this.id, 10) + 1;
      ul.prepend($('<li></li>').text(this.text));
    });
    fetchLatest();
  });
}

Doing this recursively is probably a bad idea since it will eventually blow the browser's JavaScript stack, but it works OK for the demo.

The more interesting part is the server-side /wait URL which is being polled. Here's the relevant Node/djangode code:

var message_queue = new process.EventEmitter();

var app = dj.makeApp([
  // ...
  ['^/wait$', function(req, res) {
    var id = req.uri.params.id || 0;
    var messages = getMessagesSince(id);
    if (messages.length) {
      dj.respond(res, JSON.stringify(messages), 'text/plain');
    } else {
      // Wait for the next message
      var listener = message_queue.addListener('message', function() {
        dj.respond(res, 
          JSON.stringify(getMessagesSince(id)), 'text/plain'
        );
        message_queue.removeListener('message', listener);
        clearTimeout(timeout);
      });
      var timeout = setTimeout(function() {
        message_queue.removeListener('message', listener);
        dj.respond(res, JSON.stringify([]), 'text/plain');
      }, 10000);
    }
  }]
  // ...
]);

The wait endpoint checks for new messages and, if any exist, returns immediately. If there are no new messages it does two things: it hooks up a listener on the message_queue EventEmitter (Node's equivalent of jQuery/YUI/Prototype's custom events) which will respond and end the request when a new message becomes available, and also sets a timeout that will cancel the listener and end the request after 10 seconds. This ensures that long polls don't go on too long and potentially cause problems - as far as the browser is concerned it's just talking to a JSON resource which takes up to ten seconds to load.

When a message does become available, calling message_queue.emit('message') will cause all waiting requests to respond with the latest set of messages.

Talking to databases

nodecast keeps track of messages using an in-memory JavaScript array, which works fine until you restart the server and lose everything. How do you implement persistent storage?

For the moment, the easiest answer lies with the NoSQL ecosystem. Node's focus on non-blocking I/O makes it hard (but not impossible) to hook it up to regular database client libraries. Instead, it strongly favours databases that speak simple protocols over a TCP/IP socket - or even better, databases that communicate over HTTP. So far I've tried using CouchDB (with node-couch) and redis (with redis-node-client), and both worked extremely well. nodecast trunk now uses redis to store the message queue, and provides a nice example of working with a callback-based non-blocking database interface:

var db = redis.create_client();
var REDIS_KEY = 'nodecast-queue';

function addMessage(msg, callback) {
  db.llen(REDIS_KEY, function(i) {
    msg.id = i; // ID is set to the queue length
    db.rpush(REDIS_KEY, JSON.stringify(msg), function() {
      message_queue.emit('message', msg);
      callback(msg);
    });
  });
}

Relational databases are coming to Node. Ryan has a PostgreSQL adapter in the works, thanks to that database already featuring a mature non-blocking client library. MySQL will be a bit tougher - Node will need to grow a separate thread pool to integrate with the official client libs - but you can talk to MySQL right now by dropping in DBSlayer from the NY Times which provides an HTTP interface to a pool of MySQL servers.

Mixed environments

I don't see myself switching all of my server-side development over to JavaScript, but Node has definitely earned a place in my toolbox. It shouldn't be at all hard to mix Node in to an existing server-side environment - either by running both behind a single HTTP proxy (being event-based itself, nginx would be an obvious fit) or by putting Node applications on a separate subdomain. Node is a tempting option for anything involving comet, file uploads or even just mashing together potentially slow loading web APIs. Expect to hear a lot more about it in the future.

SPDY: The Web, Only Faster

2009-11-13T13:00:08+00:00

SPDY: The Web, Only Faster

Alex Russell explains the benefits of Google’s SPDF proposal (a protocol that upgrades HTTP)—including header compression, multiplexing, the ability to send additional resources such as images and stylesheets down without needing the data:uri hack and Comet support built in to the core assumptions of the protocol.

Tags: alex-russell, comet, compression, datauri, google, http, spdy

nginx_http_push_module

2009-10-17T16:48:31+00:00

nginx_http_push_module

More clever design with webhooks—here’s an nginx module that provides a comet endpoint URL which will hang until a back end process POSTs to another URL on the same server. This makes it much easier to build asynchronous comet apps using regular synchronous web frameworks such as Django, PHP and Rails.

Tags: comet, django, nginx, php, rails, webhooks

Diesel

2009-09-23T17:15:42+00:00

Diesel

Yet Another Asynchronous Python Comet Library, of interest because this is the first one I’ve seen that uses Python’s generator coroutines, taking advantage of the return value of the yield statement to feed messages in to a generator function. Currently only works on Python 2.6 on Linux due to a dependency on 2.6’s epoll support.

Tags: async, comet, diesel, generators, python

Tornado Web Server

2009-09-10T21:32:57+00:00

Tornado Web Server

An extremely exciting addition to the Python web landscape, Tornado is the open sourced version of FriendFeed’s custom web stack. It’s a non-blocking (epoll) Python web server designed for handling thousands of simultaneous connections, perfect for building Comet applications. The web framework is cosmetically similar to web.py or App Engine’s webapp but has decorators for writing asynchronous request handlers. The template language uses Django-style syntax but allows you to use full Python expressions. FriendFeed have benchmarked it handling 8,000 requests a second running as four load-balanced processes on a 4 core server.

Via Bret Taylor

Tags: bret-taylor, comet, django, epoll, friendfeed, google-app-engine, python, tornado, webapp, webpy

svnpubsub.py

2009-09-06T21:50:01+00:00

svnpubsub.py

A Twisted/Python powered comet API for pushing out Subversion commits, built for Apache Foundation projects.

Via apache.org incident report for 8/28/2009

Tags: comet, python, subversion, svnpubsub, twisted

EtherPad

2009-07-24T00:35:25+00:00

EtherPad

Outstanding implementation of an online real-time collaborative text editor—basically SubEthaEdit in your browser. I can see myself using this a lot.

Tags: appjet, comet, etherpad, javascript, realtime, subethaedit

Webhooks behind the firewall with Reverse HTTP

2009-07-22T13:46:20+00:00

Webhooks behind the firewall with Reverse HTTP

Hookout is a Ruby / rack adapter that lets you serve a web application from behind a firewall, by binding to a Reverse HTTP proxy running on the internet (such as the free one provided by reversehttp.net). Useful for far more than just webhooks, this means you can easily expose any Ruby web service to the outside world. An implementation of this as a general purpose proxy server would make it useful for applications written in any language.

Tags: comet, hookout, reversehttp, ruby, webhooks

Reverse HTTP Demo

2009-07-21T15:54:33+00:00

Reverse HTTP Demo

This is a bit of a brain teaser—a web server running in JavaScript in your browser which uses long polling comet to respond to incoming HTTP requests channelled through a “Reverse HTTP” proxy.

Via ReverseHttp

Tags: comet, javascript, reversehttp

Paul Buchheit: Make your site faster and cheaper to operate in one easy step

2009-04-17T17:19:44+00:00

Paul Buchheit: Make your site faster and cheaper to operate in one easy step

Paul promotes gzip encoding using nginx as a proxy, and mentions that FriendFeed use a “custom, epoll-based python server” as their application server. Does that mean that they’re serving their real-time comet feeds directly from Python?

Tags: comet, epoll, friendfeed, gzip, nginx, paul-buchheit, python

Visualising Radio, pushing, not pulling

2009-01-13T00:59:31+00:00

Visualising Radio, pushing, not pulling

The BBC’s new radio player uses Comet over a Flash XMLsocket connection transport, with an ActiveMQ message queue behind the scenes. I’d like to know what server they’re using to broadcast out to the XMLsocket connections.

Tags: activemq, bbc, comet, duncan-robertson, flash, javascript, xmlsocket

ptth (Reverse HTTP) implementation in a browser using Long Poll COMET

2008-12-08T17:22:42+00:00

ptth (Reverse HTTP) implementation in a browser using Long Poll COMET

Donovan Preston experiments with the cleverly named idea of ptth, where servers send HTTP requests to clients.

Tags: comet, donovanpreston, http, ptth

FriendFeed launch a real-time API

2008-10-22T14:18:56+00:00

FriendFeed launch a real-time API

This is huge: JSONP plus long polling Comet, with “everything since X” tokens to ensure you don’t miss anything. This is the first open Comet API I’ve seen anywhere. Combine this with FriendFeed’s regular API (which allows arbitrary message posting) and you’ve got a really powerful tool for hackers who want to experiment with Comet without rigging up their own infrastructure.

Tags: apis, comet, friendfeed, javascript, json, jsonp, realtime

A Million-user Comet Application with Mochiweb, Part 1

2008-10-16T14:16:18+00:00

A Million-user Comet Application with Mochiweb, Part 1

Richard Jones explores Mochiweb, Erlang and linux kernel tuning for building a high performance comet server. Does this mean real-time web features are coming to last.fm?

Tags: comet, erlang, lastfm, mochiweb, realtimeweb, richard-jones

Private Messages with cometD Chat

2008-10-16T14:14:31+00:00

Private Messages with cometD Chat

cometd-java (a Java servlet reference implementation of the Bayeux protocol) can be extended with BayeuxService subclasses that run within the server itself.

Tags: bayeux, comet, cometd, cometdjava, java, javascript

View your FriendFeed in real-time

2008-10-16T14:06:16+00:00

View your FriendFeed in real-time

FriendFeed become the latest site to enable real-time updates using the long-polling variant of Comet. The real-time Web was something of a theme at this year’s FOWA, with talks on message queues, XMPP and scaling Comet at Meebo.

Tags: comet, fowa2008, friendfeed, meebo, realtimeweb, xmpp

Spawning + Django

2008-07-31T10:56:21+00:00

Spawning + Django

The latest version of Spawning (a fast Python web server built on top of the Eventlet non-blocking coroutine networking library) can run Django applications out of the box, using threads and processes to work around the blocking nature of the ORM’s database drivers. Eric Florenzano reports better performance than Apache and mod_wsgi, and is now hosting his site on it.

Tags: comet, django, eric-florenzano, eventlet, python, spawning

How Comet Brings Instant Messaging to meebo

2008-07-27T11:18:35+00:00

How Comet Brings Instant Messaging to meebo

“What started off as a hack appears to be fulfilling one of the most basic needs of the Web, which is live synchronous interaction”—Jian Shen

Tags: comet, javascript, jianshen, meebo

Independence Day: HTML5 WebSocket Liberates Comet From Hacks

2008-07-04T09:54:55+00:00

Independence Day: HTML5 WebSocket Liberates Comet From Hacks

The HTML5 spec now includes WebSocket, a TCP-style persistent socket mechanism between client and server using an HTTP handshake to work around firewalls. The Orbited comet implementation provides a WebSocket compatible API to existing browsers today, and can also act as a firewall/proxy between WebSocket and regular TCP sockets, allowing browsers to talk to things like XMPP servers using Orbited to bridge the gap.

Tags: comet, html5, orbited, sockets, tcpsocket, websockets, xmpp

Enough Already with the Connections!

2008-06-30T09:27:52+00:00

Enough Already with the Connections!

Comet doesn’t mean making long-lived HTTP connections (which most browsers do anyway thanks to HTTP keep-alive), it means making long-held HTTP requests. I’m guilty of spreading this misinformation in the past.

Tags: comet, connections, correction, http, keepalive, requests