Le 14 oct. 08 à 19:45, Nicolas Cannasse a écrit :
KaalH! a écrit :
Le 10 oct. 08 à 19:03, Nicolas Cannasse a écrit :
I'm not a big fan of inscreasing the timeout, since it shouldn't
depend
on that for handling large files. Is it not possible instead to
stream
the data while parsing it like mod_tora for apache does ?
With other proxy backends (fastcgi,ajp13,http,scgi), raw data is
sent as
is or splitted in fixed length data packets, final decoding is
made by
the proxied server.
Adding smthg like CMultiBoundary & CMultiData to the tora
protocol and
decode data in the server would be better for lighttpd.
I updated mod_tora sources and the protocol is now fully abstract.
You should then be able to easily write a mod_light_tora for
lighttpd by entirely reusing protocol.c and ../common/psock.c
Great :)
I've previously made some major bugfixes in the lighty patch, I
will send this new version next week.
I will use some of protocol.c in next releases.
I can't entirely reuse protocol.c, because lighty modules are not
using sockets.
Let's explain a bit,
in lighty you have to use "chunckqueues", which are chains of
memory buffers/temp files.
You have to entirely encode the "in" chunckqueue to an "out" one ,
and then the proxy_core send it to the backend server ( tora in
this case).
Then, you decode the backend response form one chunckqueue to
another, and lighty send it the the client.
All of this is compatible with the tora protocol, except multipart
handling. I've find a way to make it works, but it's not perfect,
socket timeout can occurs because lighty needs to entirely parse
the multipart data before sending it to tora.
Then I'm thinking... "humm, nicolas is usually a brillant software
architect, and I like to transfert multipart data only if/when it's
needed, maybe light is wrong... let's see how nignx is dealing with
fastcgi and compare both implementations"
I've re-read lighty proxy sources code and read the ngnix modules
guide (http://emiller.info/nginx-modules-guide.html).
Nginx is strictly using a chain of small (4k) buffers, which are
piped along modules, seems cool ... but you can't talk to
sockets, nginx architecture do not allow it.
So, lighty and nginix both use buffers, not sockets, and do not
allow bidirectional transactions with backends, so handling
multipart as you do with apache do not seems possible (hope i'm
wrong here, but just now I don't think so)
I'm not sure I'm following your here.
Why exactly mod_tora for lighty or nginx cannot connect directly to
the tora host and use the protocol as mod_tora for Apache is doing ?
I maybe have a wrong vision of tora.
You may have think mod_tora "only" as a http server plugin to solve
some memory comsumption issues.
But for me, programmer and sysadmin (can't choose only one, both are
madly enjoying ), tora must be a scalable way to deploy neko
application in web farms, so the lighttpd/nginx/... implementation
should be able to connect to several tora instances, load balance and
failover between them, like it's done with fastcgi on lighttpd and
nginx.
The proxy paradigm make difficult to implement the tora multipart
content scheme, be able to pass raw data to tora without have to wait
for the CGetMultipart code would be a lot easier to implement in
lighttpd, and seems to be required for nginx ( http://marc.info/?l=nginx&m=121425082522327&w=2
)
kaalh
Best,
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
--
Neko : One VM to run them all
(http://nekovm.org)
