« Return to Thread: Http Core NIO Client Using non-socket Channel
Re: Http Core NIO Client Using non-socket Channel
by olegk
::
Rate this Message:
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.
Oleg
> -V.B.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
> 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.
Oleg
> -V.B.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: Http Core NIO Client Using non-socket Channel
| Free embeddable forum powered by Nabble | Forum Help |
