On Thu, 2007-02-08 at 14:48 +0100, Stojce Dimski wrote: Hi Oleg, > Hi Stojce
> I am trying to bend myself over a httpCore-nio, so please bear with > me... > No worries. I'll happily do my best to help > a) If understood correctly, when 'requestReceived' I would have to: > 1) transcode the headers for a new proxyRequest > 2) 'suspendOutput' > 3) invoke proxyRequest > 4) (when received full proxyResponse) 'suspendOutput', > 5) 'requestOutput', pump the response > 5) 'submitResponse', 'requestInput' > Is this correct ? > Sounds like. I'll expand it a little (1) Listening I/O reactor -- receives an incoming connection. -- fires 'requestReceived' on the incoming connection. (2) Service handler of the listening I/O reactor -- registers a session request with the connecting I/O reactor -- passes a request handle object containing all the necessary references as an attachment -- registers a callback interface with the session request object -- suspends input events on the incoming connection -- terminates (3) Connecting I/O reactor -- fires a method on the session request callback interface (4) The callback impl -- obtains the request handle object from the attachment -- sticks the request handle object to the HTTP context of the outgoing connection -- terminates (5) Connecting I/O reactor -- fires 'requestReady' on the outgoing connection (6) Client handler of the connecting I/O reactor -- prepares a new request object, rewrites some headers -- submits the request to the target server -- obtains a reference to the incoming connection from the request handle object -- enables input events on the incoming connection -- terminates (7) Listening I/O reactor -- fires 'inputReady' event (8) Service handler of the listening I/O reactor -- reads data from the content Decoder into a shared buffer -- enables output events on the outgoing connection if necessary -- terminates (9) Connecting I/O reactor -- fires 'outputReady' event (10) Client handler of the connecting I/O reactor -- tries to write the content of the shared buffer to the content Encoder (11) All this continues until Decoder#isCompleted() returns true (12) At this point the request has been successfully submitted to the target server. (13) Similar sequence of events is going to take place while receiving and processing a response Oh well, now I need to recess. The truly brain splitting stuff begins when the incoming connection produces either too much data for the outgoing connection to handle or too little. A well behaved proxy should toggle input/output events to make sure they do not fire unnecessarily. This is where really _serious_ fun begins. Did not I say to stay away from NIO unless _really_ necessary? ;-) > b) connection.getContext in 'requestReceived' gives me the context with > which I can uniquely identify this request ? I can safely pass it to > 'client side' ? > I would recommend creating a handle object that uniquely represents a request long with all the associated information and pass it around between the 'server' and the 'client' side > c) Is it possible to have a reactor which listen on multiple addresses > ? > Absolutely > d) Or is it possible to have multiple reactors connected to the same > dispatcher ? > I believe so. Cheers Oleg > > Thanks, > Stojce > > > > > > > ___________________________________ > L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: > http://it.docs.yahoo.com/nowyoucan.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
