Thursday, July 13th, 2006p>
Comet is mostly considered a server-to-browser thing, but how about a permanent connection in the opposite direction, from browser to server? I’ve been talking about this on my blog and received some interesting thoughts from Alex Russell.
There are two key issues:
(1) Server needs to start outputting before incoming request is finished. With a specialised server, this problem could be overcome.
(2) (More serious as we can’t control the browser) The browser would need to upload data in a continuous stream. You can do it with Flash/Java, but I can’t see how to do this with standard JS/HTML. If you use XHR, you’re going to call send() and wave goodbye to the entire request…there’s no support for sequencing it. Same if you submit a regular form, change IFrame’s source etc. Even if you could somehow delay reading of content so it’s not immediately uploaded, the browser would probably end up not sending anything at all as it would be waiting to fill up a packet.
Now I’ve seen various people mention the possibility of HTTP keep-alive, but I’ve never actually seen any concrete demos or techniques to take advantage of it from a script. So if you know of any …
Anyway, Alex Russell says it’s probably not possible, but we can get around it anyway:
So I’ve spent some time investigating this (as you might expect), and at
the end of the day there’s not much to be done aside from using Flash
and their XMLSocket interface. That’s an obvious possibility given the
high-performance Flash communication infrastructure we have in Dojo.
Doing bi-directional HTTP probably won’t happen, though, but I don’t
think that’s cause for despair. In my tests, we can get really good
(relative) performance out of distinct HTTP requests so long as the
content of the request is kept to a minimum and the server can process
the connection fast enough. HTTP keepalive exists at a level somewhat
below what’s currently exposed to browsers, so if the client and server
support it, frequent requests through stock XHR objects may verywell be
using it anyway. We’ll have to do some significant testing to determine
what conjunctions of servers/clients might do this, however.
As an interesting side note, he also pointed to some work going on at http://cometd.com to build an open Comet protocol.