J. D. wrote:
Thanx Oleg once again for your prompt response.
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.
V.B.,
What I am trying to say is that using non-blocking HTTP transport on top
of an inherently blocking tunnel implementation will give you all the
disadvantages of blocking I/O such as as poorer scalability coupled with
all the disadvantages of NIO such as poorer data throughput without any
advantages of either. In my opinion you should seriously consider using
blocking HttpCore unless the tunneling module is capable of doing NIO
natively.
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.
Right. It might be very easy to do as long as you do not mind forking
some of the low level reactor classes. It may be significantly more
difficult to pull off without breaking API compatibility with the stock
version of HttpCore.
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.
This should be doable as long as you do not mind maintaining your own
implementation of ConnectingIOReactor.
Oleg
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]
Please advise.
-V.B.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
