Toward server-sent data w/o iframes

So this past week at OSCON, I had some discussions with people around what comes after XMLHTTP for sending data to and from web browsers with low latency. Traditional polling schemes really really suck, and the alternatives are all giant hacks. Having re-written the mod_pubsub JavaScript client last year, I’m pretty familiar with what you can and can’t do to and from a browser.

Or at least I thought I was.

At OSCON, I fortuitously meet Johnny Stenback, who informed me that you could indeed get multiple replies from a single request under Mozilla after I’d stated otherwise in a session. Today I started to dig a bit based on his direction and the results are interesting.

But they’re not really interesting if you don’t have the back story. Previously, I had thought that the only way to keep a connection open and do multiple things with it in a cross browser way was to rely on an incremental rendering hack (which is how the mod_pubsub client works). In this scenario, the client opens up an iframe and points it at a special page that doesn’t close the connection. When the server has data, it synthesizes a <script> block which gets sent to the client (sometimes with some padding), which then evaluates it thanks to a “partial rendering” behavior that seems to be part of every browser since time began. The script loaded this way then calls back up to the parent page (on a special function) which then disseminates the event data to everything that had previously registered it’s interest. This works pretty well, but falls into the well populated “giant, gratuitous hack” category of useful techniques for doing things in browsers.

Something better would be much appreciated. For a long time, DHTML hackers have eyed Microsoft’s XMLHTTP docs with some envy as there is a stream type and an interactive mode which aren’t made available to scripting, and there hasn’t even been that much promised under Mozilla et. al. So back to iframe hacks we fell. But things are looking up.

It seems that it’s now possible to send chunked data to the client in Mozilla on a long-lived connection, and it might very well be possible to do the same thing for IE.

Unfortunantly, unlike the iframe hack, it looks like the format on the wire will be different between the browsers (and things like Safari might still require iframes, which is yet another code branch). Whether or not any of this is a better trade-off than doing something like LivePage or the current mod_pubsub implementation is still up for debate, and only trial-and-error will really tell.

Of course, the biggest hurdle is still the scalability of servers for long-lived “zombie” connections, which things like Java servlet containers completely melt under, but Twisted Python (which mod_pubsub is now based on) indicate the way forward. I think it won’t be too long before real-time monitoring and chat features turn into commonplace occurrences in the Web2.0 experience.

It’ll just take another set of sexy apps to point the way forward. And a lot of elbow grease.


  1. Posted August 6, 2005 at 8:37 pm | Permalink

    Well, if you’re hijacking Flash’s XMLSocket, you get persistent connections with XML document chunks and lax cross-domain restrictions (provided the endpoint has crossdomain.xml).

    Making it talk to JavaScript is ugly, but possible (e.g. Flash JavaScript Integration Kit), and it works with all the popular browsers. On top of that, Flash 8 supposedly has a real API for talking to JavaScript.

    It’s a Good For Now solution, until browsers are similarly capable on their own.

  2. Posted August 9, 2005 at 4:44 pm | Permalink

    I’ve personally salivated over XMLSocket for years, but it just feels even more brittle than either the iframe or xmlhttp hacks, and being able to send a message terminator on both major browsers seems to be a huge step in plugin-less data transport.

    I would, however, like to see a small XMLSocket package from a Flash person that comes bundled w/ an exposed JS API.

  3. Posted August 9, 2005 at 8:28 pm | Permalink

    So I’ve been thinking about “” since it was posted. If I could connect to a Jabber server from JavaScript then things would be set, especially if I could connect anonymously so I don’t give away my JID. A brief interogation of Justin Kirby about is OpenAether library and XPCOM bindings ( that it’s callable from JavaScript in Firefox with some error messages.

    I have to test, but mmm.

  4. Posted September 25, 2005 at 10:17 am | Permalink

    The problem with those long lived zombie connections is exactly what the Continuations feature in Jetty 6 is supposed to fix (

    It’s not that I’m so fond of Java but I know a lot of people who are.

  5. Posted September 25, 2005 at 1:12 pm | Permalink


    I noted with some interest the continuation support announced in the new Jetty. Perhaps it will provide an answer for Java folks someday (or they could just use Rhino w/ continuations and avoid the throw/catch hackery), but things like Twisted Python and mod_pubsub are here today. No waiting, and no condescending programming language to deal with. Give them a look.


  6. Posted September 25, 2005 at 2:10 pm | Permalink

    To clarify I’m very much a Python person and have fooled around with Twisted a bit.
    Similarly Java people have had NIO for a while now but it is difficult and I believe incompatible with servlets.

    I’m curious about this mod_pubsub thing (have been for a while now) but if I go to the URL you gave ( I get: “You don’t have permission to access / on this server.”

  7. Rajeev
    Posted March 4, 2006 at 11:37 pm | Permalink

    Can you elaborate on this a bit plz ?

    — or they could just use Rhino w/
    — continuations and avoid the
    — throw/catch hackery

  8. Posted March 20, 2006 at 2:11 pm | Permalink

    Lightstreamer is a stand-alone Java server based on NIO, optimized to sustain tens of thousands of concurrent connections for each CPU.

    So the typical deployment architecture is based on two distinct clusters: the Pull cluster (a common web server cluster) and the Push cluster (a Lightstreamer server cluster).
    The browser first connects to the Pull cluster to download al the static resources of the page (html, js, css, images, etc.). Then it connects to the Push cluster to open the push/streaming connection and to subscribe to any item. The real-time updates are sent over the push/streaming connection. In this way the load caused by the real-time traffic is entirely absorbed by the Push cluster (that is specialized for this task), without affecting the traditional architecture of the Pull cluster.

    To know more and see some online demos just go to


  9. Mangesh
    Posted August 4, 2006 at 7:13 am | Permalink

    hi all, i am a java programmer i m using XMLSocket in my project. I could send data from flash to java using XMLSocket but please can u tell me how i would be able to recieve data from java. How to read from XMLSocket

  10. Daniel Doubleday
    Posted September 11, 2006 at 2:14 pm | Permalink


    I was wondering if somebody actually tried MSXML2.DOMDocument to implement Multi Part XHR. Because I did and failed miserably. Maybe I get something totally wrong but it seems that the ondataavailable is pretty worthless for that matter.
    MSXML2.DOMDocument calls the handler only every x elments where x is .. well some number (> 200 elems)
    Even if MSXML2.DOMDocument loads assync it doesn’t seem to start parsing the document before the stream is closed (which alone makes it completely worthless)
    I don’t think that anybody ever really considered using it – but since the idea is floating around and is referred to from a lot of blogs …

    By the way: there’s almost zero information about this apart from the msdn page mentioned in the article.


One Trackback

  1. […] But couldn’t you do something with XMLHTTP? Short answer: yes, but not as portably and it won’t get you around IE’s 2-connection limit either, so there’s not much of a win. For the long answer, see my talk at ETech or wait for me to post the slides. At the end of the day, the hidden <iframe> hack scales best and is the most portable. Especially if you can lick the UX problems. […]