Hello Igor, I didn't implement multiplexed connections directly on the FCGIRequest / FCGIResponse level. Found several discussions about this and none of them stated that multiplexing would be such a great deal. In fact at the beginning I played around with it using PHP as a backend and as far as I can tell even PHP has no multiplexing support at all. As a result of this I added multiple connection support to FCGIClients, so that multiple requests can be send and the responses received with a single client instance.
However multiplexing is generally possible by implementing your own IoHandler for catching and sending FCGIMessages instead of higher level FCGIRequests / FCGIResponses. The encoder accepts all three types and the FCGICodecFactiry can be instanciated accordingly. I'll add a bunch of simple message factories for this (FCGIMessage.createParams(), FCGIMessage.createStdin(), FCGIMessage.createEndRequest() etc.) to make this even easier. Till now I created three simple examples (a FCGIClient, a FCGIServer and a basic FCGHandler) and I think that I'll add a low level one for a server and client soon. In fact you'll need low level FCGIMessages to send / receive partial requests / responses or you can even mix higher level FCGIRequests with lower level FCGIMessages if only huge responses will occur. As an IoHandler multiplexing could be easily established very similar to this. All you'd need to do is assembling incoming multiplexed messages and keep track of the request ids on your own. As a first impression I uploaded the current higher level examples to http://daniel.users.hostunity.net/asyncfcgi/. regards Daniel On Mon, Apr 14, 2008 at 10:54 AM, Igor Clark <[EMAIL PROTECTED]> wrote: > Hi Daniel, that sounds excellent! > > I'd be really interested to see more of this - I got as far as > implementing the server side using the OpenMarket code as a base, but > started to feel I would have to do some significant reworking. Sounds like > you've already done that and more. > > What's your take on multiplexing connections? > > Bests > Igor > > On 11 April 2008, at 06:11, Daniel Wirtz <[EMAIL PROTECTED]> wrote: > > I'm currently taking a deeper look into FastCGI on top of mina. I built > > the basic FCGIEncoder, FCGIDecoder and a FCGICodecFactory with performance > > in mind mostly using IoBuffers and stripping all the needless stuff the > > original 12 years old devkit contains. Connections can be used in both > > directions as client and/or server and there are two modes implemented: A > > simple responder model utilizing FCGIRequest and FCGIResponse that can be > > easily sent and later on received by an IoHandler bypassing all the low > > level stuff by pre-assembling FCGIPackets and also a low level mode to send > > and receive custom FCGIPackets on your own (maybe for authorizer mode, you > > can even mix). I'm currently working on a simple FCGIManager to easily > > spread requests over multiple FastCGI backends - had this working once with > > a good ol' threading model but then I decided to implement it completely on > > top of Mina with a similar overall structure like AsyncWeb. Think it would > > be a nice option to use PHP, Ruby etc. backends for processing arbitrary > > stuff (quite similar to mod_fastcgi in Apache and lighttpd). > > FCGIRequest request = new FCGIRequest(); request.setProperties(....); > > request.setStdin(...); session.write(request); -> messageReceived(...) > > retuns FCGIResponse containing Stdout, Stderr byte arrays + AppStatus, > > ProtocolStatus, RequestId etc. or alternatively a low level FCGIPacket > > depending on the CodecFactory setting (e.g. new > > FCGICodecFactory(FCGIPacket.class / FCGIResponse.class / > > FCGIRequest.class)). > > Tested it with PHP, works fine so far. > > Is there already a good FastCGI implementation available or is there > > still a need for one? > > > > -- > Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355 • > www.pokelondon.com > > > >
