There is an increasingly popular technique to emulate server-initiated push
over HTTP. I'm sure everyone here knows it well, but for the sake of
completeness: the clients sends a XMLHttpRequest to the server in the
background; the server does not answer it immediately, but keeps it for
later when there is actually something to say to the client; if the request
timeouts, the client re-sends it.
I am wondering if this technique is usable with Apache in general and
mod_perl in particular.
The obvious solution is to have the request handler sleep until it has
something to answer does not work, since it requires a worker thread and a
perl interpreter for each waiting client, and perl interpreters are few and
expensive.
The ideal solution would be if some part of the request handler could put
the current request (A) "on hold". Later, the handler for another request
(B) could retrieve the request A and generate an answer for it, or at least
wake it up.
Is something like this possible with Apache and mod_perl?
Regards,
--=20
Nicolas George
--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
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. :)
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.
But it seems to me that you're leaning towards some daemon that runs
in the background on the server, generating long-running responses to
requests that come from the server. This is close to what you
described with request A and B, but I'd have the actual request
handled by another daemon.
I can get into further detail and speculation, but maybe we'll leave
that as homework.
--Joel
On Nov 12, 2009, at 1:53 PM, Nicolas George wrote:
> Hi.
>
> There is an increasingly popular technique to emulate server-
> initiated push
> over HTTP. I'm sure everyone here knows it well, but for the sake of
> completeness: the clients sends a XMLHttpRequest to the server in the
> background; the server does not answer it immediately, but keeps it
> for
> later when there is actually something to say to the client; if the
> request
> timeouts, the client re-sends it.
>
> I am wondering if this technique is usable with Apache in general and
> mod_perl in particular.
>
> The obvious solution is to have the request handler sleep until it has
> something to answer does not work, since it requires a worker thread
> and a
> perl interpreter for each waiting client, and perl interpreters are
> few and
> expensive.
>
> The ideal solution would be if some part of the request handler
> could put
> the current request (A) "on hold". Later, the handler for another
> request
> (B) could retrieve the request A and generate an answer for it, or
> at least
> wake it up.
>
> Is something like this possible with Apache and mod_perl?
>
> Regards,
>
> --
> Nicolas George
Re: AJAX pseudo-push
am 12.11.2009 21:22:10 von Perrin Harkins
On Thu, Nov 12, 2009 at 1:53 PM, Nicolas George wrote:
> There is an increasingly popular technique to emulate server-initiated push
> over HTTP. I'm sure everyone here knows it well, but for the sake of
> completeness: the clients sends a XMLHttpRequest to the server in the
> background; the server does not answer it immediately, but keeps it for
> later when there is actually something to say to the client; if the request
> timeouts, the client re-sends it.
I think you'd be better off using polling. There are tools for this
in the popular JS frameworks.
Le duodi 22 brumaire, an CCXVIII, Joel Richard a =E9crit=A0:
> I may be off base, but I think this technique would be ineffective since=
=20
> the server process would be kept busy with an open connection to the=20
> browser. Eventually you'll run out of processes what with all the =20
> clients that end up waiting for something to happen. HTTP is a pull =20
> 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
"" 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 =20
> message queue?) would be more appropriate to allow the browser to poll =
=20
> the server periodically to see if the info is available. Once the info =
=20
> becomes available, then the server can send it to the browser. Thousands=
=20
> 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,
--=20
Nicolas George
--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
> 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.
I wouldn't write your own. There are other event based, asynchronous web
servers out there in Perl (HTTP::Server::Multiplex, Net::Server::Coro,
Tatsumaki) so better to pick one of those than write your own.
This technique in general falls under the umbrella term of "Comet", so
I'd search CPAN for that. When I did it I quickly saw Stardust.
--
Michael Peters
Plus Three, LP
Re: AJAX pseudo-push
am 12.11.2009 21:53:22 von Jean-Damien Durand
Le jeudi 12 novembre 2009 21:33:48, Nicolas George a =E9crit :
> he 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 ve=
ry
> hard.
Just to clarify your meaning, sole HTTP remains a stateless protocol -=20
independantly to the fact that tcp connection can be permanent (default but=
=20
not guaranteed behaviour since HTTP/1.1- unless stated otherwise in the =20
headers).
Cheers, JD.
Re: AJAX pseudo-push
am 12.11.2009 22:20:55 von Perrin Harkins
On Thu, Nov 12, 2009 at 3:33 PM, Nicolas George wrote:
> 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.
That's good enough for most applications, and the "nothing to see
here" requests can be handled very quickly.
If you really need to use Comet, the common approach is a non-blocking
server architecture. If you want to use mod_perl for it, you can read
about the approach Stas used here:
lxxi.org/files/spamcon07/Bekman-SMTP_Multiplexing.pdf
They wrote their own server that passes off to apache when something
happens, but these days you could use perlbal as your base. You can
look at things like lighttpd + FastCGI too, but you'd probably have to
write some C code there to avoid keeping a perl process busy.
[ I think ezmlm has eaten my mail. Sorry if it arrives twice. ]
Le duodi 22 brumaire, an CCXVIII, Michael Peters a =E9crit=A0:
> I wouldn't write your own. There are other event based, asynchronous web =
=20
> servers out there in Perl (HTTP::Server::Multiplex, Net::Server::Coro, =
=20
> Tatsumaki) so better to pick one of those than write your own.
>
> This technique in general falls under the umbrella term of "Comet", so =
=20
> I'd search CPAN for that. When I did it I quickly saw Stardust.
Thanks, I did not know the term "Comet". This will greatly help me to find
implementations that suit my needs.
And thanks also to Jeff Nokes for his useful pointer.
Unfortunately, it all seems to confirm that it can not be done with Apache.
Regards,
--=20
Nicolas George
--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
Le duodi 22 brumaire, an CCXVIII, Perrin Harkins a =E9crit=A0:
> That's good enough for most applications, and the "nothing to see
> here" requests can be handled very quickly.
For what I have in mind, the actual content is rather small so the overhead
of the empty requests is huge.
> If you really need to use Comet, the common approach is a non-blocking
> server architecture.
That is what I used for my proof-of-concept server.
> If you want to use mod_perl for it, you can read
> about the approach Stas used here:
> lxxi.org/files/spamcon07/Bekman-SMTP_Multiplexing.pdf
That seems like a rather strange design, but I will look into it. Thanks for
the pointer.
Regards,
--=20
Nicolas George
--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
> Hi.
>
> There is an increasingly popular technique to emulate server-initiated push
> over HTTP. I'm sure everyone here knows it well, but for the sake of
> completeness: the clients sends a XMLHttpRequest to the server in the
> background; the server does not answer it immediately, but keeps it for
> later when there is actually something to say to the client; if the request
> timeouts, the client re-sends it.
>
> I am wondering if this technique is usable with Apache in general and
> mod_perl in particular.
>
> The obvious solution is to have the request handler sleep until it has
> something to answer does not work, since it requires a worker thread and a
> perl interpreter for each waiting client, and perl interpreters are few and
> expensive.
You could use Apache in the front to handle static content and proxy
to another server for mod_perl and/or a custom notification server you
write. Apache works very well in this type of setup.
If you haven't yet, you could also try this out and see if you hit
real performance problems. mod_perl interpreters can be heavyweight,
but there is a lot of shared data between them, so if most of your
interpreters are not doing much performance may be fine. Or maybe
not of course.
> The ideal solution would be if some part of the request handler could put
> the current request (A) "on hold". Later, the handler for another request
> (B) could retrieve the request A and generate an answer for it, or at least
> wake it up.
This is a very interesting idea, it might be possible to implement it
with a custom Apache module, or maybe even with mod_perl if you found
the right hooks.
----Scott.
Mod_Perl classic, & Apache 1.3 on FreeBSD 64 bit
am 13.11.2009 12:46:39 von Joe Niederberger
Hello,
Does anyone have a recommendation on the best verison of mod_perl
and apache 1.3 to run on a FreeBSD 64 bit server?
Thanks in advance,
Joe Niederberger
Re: AJAX pseudo-push
am 13.11.2009 15:42:39 von David Nicol
On Fri, Nov 13, 2009 at 1:19 AM, Scott Gifford
>
> This is a very interesting idea, it might be possible to implement it
> with a custom Apache module, or maybe even with mod_perl if you found
> the right hooks.
>
> ----Scott.
so we're talking about a mod_perl app that opens a file system socket
in its initialization phase and listens on it with
Re: AJAX pseudo-push
am 17.11.2009 17:49:15 von Tom Schindl
Nicolas George schrieb:
> Hi.
>
> There is an increasingly popular technique to emulate server-initiated push
> over HTTP. I'm sure everyone here knows it well, but for the sake of
> completeness: the clients sends a XMLHttpRequest to the server in the
> background; the server does not answer it immediately, but keeps it for
> later when there is actually something to say to the client; if the request
> timeouts, the client re-sends it.
>
> I am wondering if this technique is usable with Apache in general and
> mod_perl in particular.
>
> The obvious solution is to have the request handler sleep until it has
> something to answer does not work, since it requires a worker thread and a
> perl interpreter for each waiting client, and perl interpreters are few and
> expensive.
>
> The ideal solution would be if some part of the request handler could put
> the current request (A) "on hold". Later, the handler for another request
> (B) could retrieve the request A and generate an answer for it, or at least
> wake it up.
>
What you describe here is called Continuations in Java world :-)