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