Hi. Le duodi 22 brumaire, an CCXVIII, Joel Richard a écrit : > I may be off base, but I think this technique would be ineffective since > the server process would be kept busy with an open connection to the > browser. Eventually you'll run out of processes what with all the > clients that end up waiting for something to happen. HTTP is a pull > protocol. :)
This is not a protocol problem. May I remind that all Internet is based on an unreliable packet protocol? The fact that HTTP is not connection-oriented means that the server have to implement cookies and timeouts itself to track clients instead of relying on the OS TCP stack, but that is not very hard. VoIP systems that use UDP do the same. The problem of the number of concurrent idle connections is not related to the protocol but to the architecture of the server. Fundamentally, an idle connection is just a socket and a few hundred bytes of data structures to keep track of who the client is and what it wants. IRC and Jabber servers handle hundreds of such connections every day without any problem, and it makes barely any difference whether the reply to the client starts with "<message to='foo'>" or with "HTTP/1.0 200 OK". On the other hand, if the HTTP server is designed to keep a whole thread or process busy for each active request, this will not work. But that is not the only way to design an HTTP server. That is why the core of my question here is not "is it possible?", because I know it is possible (I have already implemented a proof of concept as a stand-alone HTTP server), but: is it possible _with Apache and mod_perl_. > The best that I can think of is some sort of queue system (like a > message queue?) would be more appropriate to allow the browser to poll > the server periodically to see if the info is available. Once the info > becomes available, then the server can send it to the browser. Thousands > of light requests are better than hundreds of heavy ones. We are not talking of thousands of light requests vs. hundreds of heavy ones, but of dozen of requests vs. exactly one request, all as light. I will definitely not use polling, because polling means dozen of useless requests and, when there is actually something, it has to wait to the next round of polling. Imagine a server with an AJAX-based chat room with about twenty people in it. To get reasonable interactivity, there must not be more than about 2 seconds between poll rounds, which means at the very least ten requests per second. Using pseudo-PUSH, with the same bandwidth you can serve hundreds of clients with better interactivity. If I can not do it with Apache and mod_perl, I will write my own HTTP server. But that is a shame, because it has to serve static content too, and that, Apache does definitely better than me. Regards, -- Nicolas George
signature.asc
Description: Digital signature
