hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. D." <j1234d2...@yahoo.com>
Subject Http Core NIO Client Using non-socket Channel
Date Wed, 24 Jun 2009 01:11:41 GMT
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.



      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message