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: [email protected]
For additional commands, e-mail: [email protected]
