hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. D." <j1234d2...@yahoo.com>
Subject Re: Http Core NIO Client Using non-socket Channel
Date Thu, 25 Jun 2009 23:55:38 GMT

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

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


Mime
View raw message