hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Http Core NIO Client Using non-socket Channel
Date Sun, 28 Jun 2009 13:45:17 GMT
J. D. wrote:
> Thanx Oleg for your response. I have an NIO as well as non-NIO tunnel impls.
> Either one can be integrated first and will suffice initially but
> ultimately, I will need to integrate both.

J. D.

The reason I am asking is that trying to mix blocking and non-blocking 
I/O models usually produces very suboptimal results. If the tunneling 
module were based on blocking I/O, you should have simply chosen 
HttpCore blocking I/O module or HttpClient.

> I am exploring to see if BaseIOReactor can be updated/extended to accomodate
> the ability to perform non-socket channel control:
> 1) Currently, BaseIOReactor is handed over either an accepted socket channel
> (from DefaultListeningIOReactor) or a connected socket channel (from
> DefaultConnectingIOReactor) and the channel henceforth performs IO and close
> within the scope of a BaseIOReactor selector. If current BaseIOReactor
> cannot be altered due to other non-technical reasons, a non-socket channel
> aware BaseIOReactor can extend current BaseIOReactor with following changes.
> A factory can be used by
> DefaultConnectingIOReactor/DefaultListeningIOReactor to instantiate the
> appropriate AbstractIOReactor impl.
> 2) If processNewChannels (and for future extensibility
> processClosedSessions) is made protected, then a non-socket channel aware
> BaseIOReactor can skip socket related option configurations, add the channel
> to the selector, create an IOSession. A better option would be to use a
> ChannelLifecycleController that can be set to perform these operations for
> more elegant protocol controls in future. Obviously, a custom ChannelEntry
> that expects a Channel instead of SocketChannel is required.

While it does not look entirely impossible, it may be very hard to 
decouple ChannelEntry and all classes dependent on it from SocketChannel.

As far as I understand the tunnel module should be able to expose the 
socket it is connected to, so you might want to consider wrapping the 
tunnel code with a custom SocketChannel impl instead of trying to fight 
your way through the HttpCore NIO code.

> 3) Since IOSession provides access to channel, it is necessary to still
> identify if the IOEventDispatch impls or its users care whether the channel
> is a socket. A brief look into codebase does not reveal anything else but
> please advice if that is not the case. At many places, socket specific ops
> already check whether channel is a socket channel e.g.
> IOSessionImpl.getLocalAddress().
> Please advice.

I can confirm the IOSession does not depend on any SocketChannel 
specific functionality except for #getRemoteAddress() and 
#getLocalAddress(). It should work just fine with any selectable channel.

Hope this helps somewhat.


> -V.B.

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message