On Tue, 2008-02-12 at 18:11 -0500, Sam Berlin wrote: 
> > IOControl#requestOutput will eventually cause the
> > NHttpClientHandler#requestReady to fire, which in its turn will invoke
> > HttpRequestExecutionHandler#submitRequest.
> 
> Ok -- is it safe to assume that the IOControl can be retrieved always
> from the  context supplied to the handler (with a constant key)?  Or
> do the handlers have to be written with the reactor in mind?
> 

Hi Sam,

All non-blocking connection objects always implement the IOControl
interface. Methods of IOControl instances are expected to be threading
safe, unlike the connection instances themselves, so you can always
stick a reference to an IOControl into the context of another connection
in case you want to coordinate I/O operations on several connections.
And you always get a reference to the connection that caused an event in
the protocol handler. 

Hope this helps

Oleg

> The plan is to use this as the core for swarmed downloads.  That is, a
> single "swarm" would connect to multiple hosts and download different
> ranges of a single file.  Each connection would have to suspend
> reading if the writing is bogged down.  There would be multiple swarms
> going on at once, so there's a lot of activity happening under the
> hood.  Within each swarm, information exchanged during headers (or
> through other means) is propogated to other members of the swarm.
> (Our current code is all hacked up over the years, and it's time to
> retire it.)
> 
> > I think this line of thought is correct. However, several major pieces
> > of functionality are still missing, namely a connection manager and a
> > pipelining capable NHttpClientHandler, in order for the NIO based
> > components to be of any use on the client side.
> 
> The code we've used for nearly a decade doesn't have connection
> management or pipelining either, so no big deal there. :)
> 
> Sam
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to