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.
