Re: Http Core NIO Client Using non-socket Channel

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

>>>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>>
>
> Please advise.
>
> -V.B.
>