(Geek) Faking asynchronous events on web pages with Ajax

[ciphergoth]

Despite being a geek, I don't actually know all that much about HTML, CSS, or all that webby stuff. The election thing was my first ever applet, and I've never known JavaScript before yesterday. But I've been thinking more about AJAX and the things you can do with it, and I think it's time I learned that stuff, because it's super cool and will be super extra hyper ace cool once SVG gets added to the mix. Here's something I've been trying today.

Because web clients generally insist on initiating all requests, the only way to keep a page up to date is usually to poll. Poll too slowly and you don't hear about changes until much later; poll too fast and you load the whole system unnecessarily.

It turns out that with AJAX you have a third option. I've just implemented a simple Web-based "tail" program with it - go to a Web page, and it shows you the tail of a file, updated in real time. The trick is basically to implement a hook in your CGI script so that if you have nothing to report, wait until you do before returning. As soon as you do have something, return it and close the connection. It's easy to be robust against timeouts so that if the connection gets closed early the client will just open it again and wait some more. The result is that the "polling" load is very low because the "polling interval" is as long as your timeouts, but once news arrives the client gets to hear about it very fast because it's hanging waiting for it.

Next, a boardgame. Or a Web-based IRC client. Or maybe a terminal emulator...

Comments

[brad.livejournal.com]

I did this. With firefox, hit:

http://www.danga.com:8080/misc/jsdraw/xmlhttp.html

The server is Perlbal, with a plugin that keeps a long-lived (forever) HTTP connection open sending chunked content when new data arrives.

No polling.

[kitty-goth.livejournal.com]

Is the source for this available? If so, where is it?

[brad.livejournal.com]

Here:
http://danga.com/misc/Jslab.pm.txt

It doesn't consume a process or a thread... it's all async/event-based, so don't do anything that'll stall the event loop (the one server process) for too long.

[deliberateblank.livejournal.com]

Doesn't this approach increase the problems of having a limited number of entries in your (server-side) socket table?

[eqe.livejournal.com]

You'd expect so, yes. But I'd be more worried about the other server resources being consumed: you've got a CGI process and a httpd hanging around, too.

[http://users.livejournal.com/_nicolai_/]

Occupying an httpd excessively, unless they're resources you don't share with others, is pretty nasty. It's easy for websites to run out of httpd processes on the server side, blocking the entire webserver. Not good for shared servers or serving a lot of clients.

[ciphergoth.livejournal.com]

Not all websites are high-load! And processes aren't necessarily all that heavyweight. If they are, you can arrange to use threads instead with some work...

[brad.livejournal.com]

That number's pretty ridiculously high. C10K's a solved problem, and 10K's not even that big anymore.

[skx.livejournal.com]

Have you seen this?

http://www.danga.com/openid/

I thought it might be interesting to you, after our old discussions about identity verification to third party sites.

[mara1.livejournal.com]

hey just saw you like Momus too - grrt band - i mean whateva!!