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.
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. 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. -V.B. olegk wrote: > > On Thu, Jun 25, 2009 at 04:55:38PM -0700, J. D. wrote: >> >> Thanks Ortwin for your SocketFactory idea. I did explore that idea >> earlier >> and found it to be a fairly cumbersome effort. >> >> Problem is with tunnel, you also have to deal with multiplexing multiple >> streams onto a tunnel stream. A socket factory would hand you a socket - >> which can be some abstraction of a single logical stream and therefore >> you >> end up writing your own SocketChannel impl that would end up handling >> tunnel >> protocol and the socket streaming specifics - which if not an optimal >> design >> would atleast be a fairly intricate development effort. >> >> I realize that BaseIOReactor depends on a SocketChannel which in itself >> poses this problem. However, in reality, what HTTPCore provides is a HTTP >> protocol tier that can/should abstract itself from the transport >> specifics >> and therein I started contemplating that maybe BaseIOReactor should not >> depend on a SocketChannel but instead should depend on an abstraction of >> a >> communication pathway that could be a SocketChannel or any other Channel. >> >> -V.B. >> >> > > V.B. > > This may be difficult or even impossible to do without breaking API > compatibility, which cannot afford until the 5.0 time frame. Please by all > of > means do feel free to submit a patch with the intended changes, though. > > By the way, is the tunneling module you are using based on NIO? > > Oleg > > > >> >> Ortwin Gl??ck wrote: >> > >> > V.B, >> > >> > To me this looks similar to TLS. Can you thus not just implement a >> custom >> > SocketFactory? That's usually the way how you would integrate a TLS >> > library that >> > doesn't support JSSE as well. >> > >> > Ortwin >> > >> > >> > J. D. wrote: >> >> I am trying to use HTTP Core NIO module to build highly scalable HTTP >> >> clients >> >> that do not directly use sockets to connect to peer HTTP servers. The >> >> network >> >> topology involves a tunnel and hence not amenable to a direct socket >> to >> >> the >> >> peer. >> >> >> >> [ Users <==> HttpClients <==> Tunnel(s) ] <==> [ Peer HttpServers ] >> >> >> >> My first thought was to simply use an instance of pair of >> >> java.nio.channels.Pipe pipeIn, pipeOut and use these pipes to hook up >> >> with my >> >> tunnel IO module. For outcoming (w.r.t. HttpClient) pipeOut.sink >> channel >> >> will >> >> enable HttpClient to write data to my tunnel and pipeIn.source will >> >> enable >> >> HttpClient to read data from my tunnel. Tunnel module in conjunction >> with >> >> Users interaction would be responsible for channel setup and teardown. >> >> Note >> >> that Channel setup and teardown entails special tunnelling protocol >> >> events >> >> and hence cannot be straight Selector event driven like current >> >> implementation in DefaultConnectingIOReactor. >> >> >> >> The current implementation of HTTP Core expects a SocketChannel and >> hence >> >> it >> >> does not seem feasible to directly hook up any other types of >> channels. >> >> Do >> >> you recommend an integration strategy that would be inline with future >> >> direction? >> >> >> >> BaseIOReactor is being created by DefaultConnectingIOReactor and >> expects >> >> a >> >> ChannelEntry that requires a SocketChannel. Instead an abstract >> >> ChannelEntry >> >> that would assume channel is any nio channel could be used. This would >> >> however require current code that expects channel to be a socket - >> e.g. >> >> setting socket preferences can check if it is indeed a SocketChannel. >> I >> >> am >> >> not sure how pervasive is such a change and if there is a better idea >> >> that >> >> can prevent such change. >> >> >> >> -V.B. >> > >> > -- >> > [web] http://www.odi.ch/ >> > [blog] http://www.odi.ch/weblog/ >> > [pgp] key 0x81CF3416 >> > finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Http-Core-NIO-Client-Using-non-socket-Channel-tp24179229p24212890.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] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://www.nabble.com/Http-Core-NIO-Client-Using-non-socket-Channel-tp24179229p24234943.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]
