Re: Http Core NIO Client Using non-socket Channel

olegk wrote:

> 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 not trying to hookup a blocking tunneling module directly to HTTP NIO.
There are adapter(s) to tunneling module(s) that provides the necessary
non-blocking abstraction. The tunneling module is decoupled completely from the
HTTP module and hence this is not an issue. There are various tunneling modules based on peer's capabilities and it is really not a trivial endeavor to just
make its interfacing look like a socket - it is more of a stream i.e. data is
sent and received. The connectivity semantics must be decoupled as it goes
through a lot more complex processing. I am afraid that will be the case with
most complex tunnels.

> > 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.

I am not entirely sure if this is the case as the only class that seem to depend on
ChannelEntry.getChannel() is org.apache.http.impl.nio.reactor.AbstractIOReactor.
This dependency is in processNewChannels and closeNewChannels. It is easy to change  processNewChannels() as mentioned above. closeNewChannel obviously need not
depend on a SocketChannel - all it needs is a Channel to close it. Please clarify if I am
missing something.

> 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.

I need to separate the connectivity semantics from data transfer semantics for
tunnel as I explained earlier and it does not seem pragmatic to do so due to the
aforesaid reasons.

The reason I am persistent on doing it in HTTP NIO modules is because,
as I had stated in an earlier mail, the utility of HTTP component is
significantly improved if a non-socket channel can be used to perform IO as the
HTTP messaging can go through  through various communication
techs/topologies.

> >
> > 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.
>
> Oleg
>
>
> > -V.B.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
>