How does Reverse Ajax Works?

[Xavi Sanchez]

Hi.

Could anyone explain how the Reverse Ajax thing works?

Thanks!

[Tina Ma]

I suppose, reverse ajax refers to asynchronus requests sent by the server to the browser. So it should be like both the browser and server send asynchronus requests to make the webpage more dynamic and faster to the end user.
This is just a guess, I have never used DWR-library or Reverse-Ajax before.

[Tina Ma]

sorry, DWR is new to me. So, I have been reading about it in the documentation, and it seems to have lots of potential. The reverse AJAX refers to creating AJAX requests from ajva classes with the help of DWR util classes. You can also refer to some simple examples demonstrating the awe of this new technology here : http://getahead.org/dwr/examples
if you havent seen it already....

[Frank Zammetti]

Well, reverse AJAX is in fact information sent from the server to client asynchronously, meaning the client didn't directly request the information. In other words, it's a form of push technology.

Now, as for how it works, that's a bit more complicated. There's basically three ways to pull reverse AJAX off.

First is polling. This is simple the client periodically making an AJAX request asking if there's anything the server needs to send. If you're saying "that's not really push", you're right! It's a bit of a cheat. But, all of reverse AJAX is because the the underlying nature of HTTP. The important thing is that to the user, it looks like push.

Another approach is piggybacking. This is where the client makes a request, and the server attaches some information to the response above and beyond what the client requested. Assuming the client knows how to handle that, it works. This is nice because there's no extra load on the client or server (polling there's a periodic request pinging away), but it has the disadvantage that there's no guarantee when the information to be pushed is actually pushed.

The last technique has a couple of names, but most commonly it's called COMET. It's also known as long-lived requests. This is also by far the most complex method to implement. Basically, a request is made by the client, and the server *very* slowly responds, which causes the connection to be maintained. Periodically, when the server has something to push, it'll "burst" send the information, so to speak. This approach gives you real-time push, which is great. But, it has a serious down-side: holding connections open like that isn't how the underlying protocols are meant to work, and most servers aren't terribly happy about it. If your traffic gets too great, you'll chew up threads on the server and wind up bringing your site down.

Most good implementations will periodically break that long connection and start a new one (DWR does this), and that alleviates matters a little. But it's still not great.

There are however some servers, open-source projects and commercial, that are specially designed to deal with COMET. They aren't yet widespread, but they're growing in popularity.

[Xavi Sanchez]

Thank you very much for your answer!

I can get a feeling of how polling and COMET may work, but with piggybacking... which are the options? any request to the same web app will do the trick? or has to be to the same "page"? or which is the contract or the restrictions?

I'll try to find some documentation if you don't have time to answer.

Thanks again.

[Frank Zammetti]

I'm not sure it matters frankly. I'd say it largely depends on the implementation, but if it was written right I don't think it would make a difference whether it's spread across multiple pages or not (I may be wrong about this, but I think in the case of DWR it *is* tied to a given page... I'd have to go look that one up myself).