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]
