Monday, May 23rd, 2005

Server to Client callback via mod_pubsub

Category: JavaScript

A common issue that we have to work around, is when we would love to have the server-side of an application, call back into the client-side (browser). Obvious examples are real-time updates of data.

We can of course use polling methods, and Ajax can come in to help with the polling, however this can be painful (having requests from all clients coming in every few seconds even if nothing has changed!).

One project which is trying to help us, is mod_pubsub:

Mod_pubsub is a server and choice of client libraries that together enable publish and subscribe messaging over HTTP.

The point is real-time data delivery to and from web browsers without refreshing; without installing client-side software; and without Applets, ActiveX, Flash, or Plug-ins. Mod-pubsub also allows multiple different clients (say a Windows app, a Java Swing app, and a browser) to see the same data at the same time.

Are there other solutions that people have had success with?

Posted by Dion Almaer at 9:45 am
9 Comments

+++--
3.4 rating from 7 votes

9 Comments »

Comments feed

First off, mod_pubsub is a low-latency HTTP data bus and not really an RPC mechanism (although you can layer RPC on top of it).

The basic design of mod_pubsub makes it probably the fastest way to do this kind of communication to the browser short Flash’s XMLSocket object. Other tools like LivePage (part of the Nevow project) allow this kind of low-latency transfer mechnanism but similarly require server-side support. Twisted Python is used in both Nevow and the new mod_pubsub server. It seems to be one of the only server-side frameworks that is truly event driven and will scale to a reasonable number of clients.

As the guy who re-wrote the javascript client library for mod_pubsub, I can attest that it’s not the most friendly thing in the world to work with right now, but it is seeing a lot of development and we are most of the way though a port of the client code to Dojo’s dojo.io.bind() API.

Regards

Comment by Alex Russell — May 23, 2005

I used pushlets in a realtime weather alert portlet I did. It would receive messages from a JMS Queue and then push an event to my DWR-based client that would then update to show the latest weather alerts that just came in.

Comment by John Christopher — May 23, 2005

Be aware that if you want access to any new mod_pubsub code for the next year you will need to have some cash – see http://www.mod-pubsub.org/blog/archives/456_Modpubsub_Episode_III_Rewrite_of_the_Sitch.html

Comment by Robert Leftwich — May 23, 2005

I did this 4 or 5 years ago. Just a very simple Flash movie using sockets. From javascript you can send messages through the socket connexion inside the Flash movie and the data received could be pass through to any javascript function. No painful pollings. This would be better if Javascript allowed socket connexions. Maybe in future releases (are you listening Firefox and Opera folks?)

Comment by alsanan — May 24, 2005

Asynch messaging up to the browser is really hard to do. I built most of the JavaScript libraries behind Kenamea’s software (which does roughly the same thing as mod_pubsub), and I uncovered a tremendous number of browser bugs and inconsistencies that made coding the JavaScript libraries difficult. The server side scaling is difficult too — many web servers falter in the lots-of-long-lived-connections department. (Pushlets lack in this area because you’re limited by the number of threads in a servlet container.)

The technology to do this has been around for several years now and is fairly mature, so anyone who’s interested in doing real-time callbacks to the browser should definitely use an off-the-shelf or open-source product.

Comment by Neil Mix — May 24, 2005

Brent and I thought of using an open connection instead of a polling connection when thinking about scalability for BlogChat (www.blogchat.com) but decided against it. Although clients will be polling at some interval, the number of concurrent connections at any one time is manageable and works very well in a distributed webserver farm. With an open connection method like mod_pubsub, resources are held the whole time while a client is connected. If the server is overloaded all of the clients are affected and likely lost under severe circumstances. With a polling type of scenario one client may be affected for that instant it hits that particular server in the farm. Of course there are advantages and disadvantages to both methods that should be weighed depending on the application you are developing.

Comment by Tim A — May 24, 2005

With any scheme that utilizes open/hanging connections to the server, you have to always be aware of limitations on maximum concurrent connections to a server. HTTP/1.1 specifies no more than 2 open connections per server (section 8.1.4 of RFC 2616) and browsers such as Internet Explorer enforce this limit. If you had two hanging connections to a server, any other requests (for images, HTML, etc.) block – even requests using XmlHttp. This may not be such a big deal at first – since you may only need one hanging connection. However this limit (at least in IE) is per-process, so if you open up another window and navigate to the same application, you now have two hanging connections with none left to load HTML, scripts, or images!

Having worked with Neil at Kenamea, we got around this with some fancy multiplexing (over a single connection) and inter-window communication. I assume that mod_pubsub does something similar.

My point is that going from a polling model to a hanging-connection model is not an easy step, and like Neil said you should expect to run into all sorts of strange browser behavior. But then again, that’s pretty much the norm for Ajax technology isn’t it? :)

Comment by Marc Novakowski — May 24, 2005

I’ve done this successfully on a large scale using a python-based server and php application code. The biggest problem with the system is that safari 1.3 doesn’t support streaming sockets, so you have to fall back to polling on that platform.

Some implementation notes:

* You need a wildcard subdomain so that each streaming [iframes/] has it’s own connection with the server.
* You need a basic messaging system to identify clients.
* You might want a shared authentication system between your chat server and your web application.

If anyone would like to chat about this stuff, give me an email. ben@ripcord.co.nz.

Comment by Ben Nolan — May 25, 2005

Hey, what about using PingBack/TrackBack?

Comment by n0mer — February 15, 2006

Leave a comment

You must be logged in to post a comment.