views:

426

answers:

3

I just learned about the AJAX Push Engine but it runs on Linux/Apache which is not an option for me.

http://www.ape-project.org/

Currently with AJAX to keep a page current I have to poll the server frequently which is not great for a high traffic site. The option to push data to the client only when necessary is a great option, but natively JavaScript does not support sockets, AFAIK. One trick I read about, but the site is now gone, is to use a Flash module to handle socket communications and relay message to JavaScript.

The trouble with researching this approach is that "JavaScript push" as keywords come up with the push function for arrays instead of the context I want.

How could establish a persistent connection with the server to do push communications in the browser? Do I need Flash/ActionScript or is there another option that would work with all of the currently active browsers? (IE6/7/8, FF3, Safari, Chrome)

When it comes to the server I also need to work out the complications due to Origin policy as well as port security. I appreciate anything you can point out that will explain the available options.

+3  A: 

What you want is COMET, or I would also look up long polling.

I asked a similar question.

altCognito
Similar to long-polling?
J-P
I was just pulling together my reference :)
altCognito
A: 

The Direct Web Remoting (DWR) library supports Reverse Ajax, which sounds like what you are looking for. It supports Comet (along with Polling and PiggyBack). More info on their website: http://directwebremoting.org/dwr/index.html

Francois Gravel
A: 

This is interesting stuff, but I did not read anything about scalability issues on these Wiki pages. What does a web server do if you have 10,000 open long-polling connections?

Also, for those not familiar with the underlying concepts, it is important to understand that pushing data from the server to the client in an ad-hoc fashion is impossible and will always be. Even if the HTTP protocol supported this, the network would not, particularly if there is a NAT firewall involved.

So any solutions that claim to offer server push communication must rely on connections that are initiated by the client, kept open, and will eventually time out. I have concerns about this because it must have negative consequences for server scalability and performance.

cdonner
Seems that facebook, and google use long polling, and they haven't fallen down yet. It's not *impossible* by any means.
altCognito
If you want to open a connection to a client from a server and NAT is in the way the port knocking method can be used to establish a connection. Then you can maintain a socket. My concern is the limit of the server to keep many sockets active. I would at least reset the connect occasionally or idle out inactive clients if I can detect if the client is idle.
Brennan
Well, altCognito, if Todd Hoff is right on his blog, then Facebook's $100 million hardware investment last year took care of that. But the article has a few other details about the server implementation. Clearly, long polling is not something you want to do on IIS in .Net, or any other mainstream webserver/language platform, where each blocked connection is tying up expensive resources.
cdonner
http://highscalability.com/new-facebook-chat-feature-scales-70-million-users-using-erlang
cdonner