« Return to Thread: Http Core NIO Client Using non-socket Channel

Re: Http Core NIO Client Using non-socket Channel

by J. D. :: Rate this Message:

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

« Return to Thread: Http Core NIO Client Using non-socket Channel