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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >
Please advise. -V.B. -- View this message in context: http://www.nabble.com/Http-Core-NIO-Client-Using-non-socket-Channel-tp24179229p24260709.html Sent from the HttpComponents-Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
