harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject [classlib][luni]Http persistent connection(was Re: [jira] Commented: (HARMONY-499))
Date Fri, 16 Jun 2006 10:20:03 GMT

I modified the subject to make it more obvious:). Sorry at first for 
responsing so late, I was a little distracted by the NIO work. I agree 
with you that option 1 and 2 below is feasible, and I have some rough  
thoughts on the cache mechanism,  I'm interested in how others think 
about them.

The connection pool should:

a. has different protocals support, with handy and consistent interface 
to HttpURLConnection and HttpsURLConnection
b. proxy issue, SSL connection via proxy is based on plain socket, so it 
must be handled but should be transparent to users
c. the cached sockets' lifecycle 
(max-number/create/cache/synchronization/validation/idle connection 
collection/finalization) is managed transparently to users
d. performance of the pool (say, over-synchronization, and other issue?)

Wow...seems pretty much work! So, ideas and comments?

Alexander Kleymenov wrote:
> Paulex,
> On 6/1/06, Paulex Yang <paulex.yang@gmail.com> wrote:
>> > I make HttpsURLConnection as a wrapper over the existing
>> > HttpURLConnection
>> > implementation
>> > (due to HTTPs spec:
>> >  "Simply use HTTP over TLS
>> >   precisely as you would use HTTP over TCP." RFC 2818).
>> > I.e. I do not reimplement HTTP functionality, just reuse it (although
>> > some
>> > minor updates of the base HttpURLConnection implementation should be
>> > made).
>> > So if there will be support for persistent connections in
>> > HttpURLConnection,
>> > HttpsURLConnection will have it too.
>> I don't catch up
> I extended existing o.a.h...HttpUC implementation with o.a.h...HttpsUC
> and redefine HttpUC.connect method to use SSLSocket instead of plain
> ones.
>> , based on above, may I assume that your
>> HttpsURLConnection implementation is neutral to HttpURLConnection
>> whatever we have persistent connection support or not?
> It depends on how persistent connections support will be implemented.
> It can be implemented in such a way that o.a.h...HttpsUC
> implementation could be neutral. For example:
> HttpUC.connect() {
>      ...
>      Socket s = getFromPool(url); // url contains http: or https:
>      If (s == null) {
>            s = new Socket();
>            s.connect(address);
>            s = wrapConnectedSocket(s);
>            putIntoThePool(url, s);
>      }
>      ...
> }
> In such a way, HttpsUC should only redefine method
> wrapConnectedSocket() which will create SSLSocket over the connected
> plain socket. It will be stored (as SSLSocket) in the pool by HttpUC
> and HttpsUC will not realize it. In other words HttpsUC could be made
> in such a way that it will be independent of HttpUC implementation.
> All it will do is wrapping the plain connected socket into the SSL
> sockets.
> There is one issue with this approach. If HttpsUC uses a proxy the
> first interaction over the socket (sending the CONNECT request to the
> proxy, and receiving the response) should be made in plain format and
> then socket should be wrapped into the SSLSocket (and stored in the
> pool). So wrapConnectedSocket() method call and putting resulted
> socket in the pool can be delayed in the case of proxy connection.
>> If so, then the
>> cached socket can be shared between Https and Http, because the SSL
>> related work is handled over the HttpURLConnection's plain socket. If
>> not, then the HttpsURLConnection won't automatically share persistent
>> connections if HttpURLConnection does.
>> > But Http implementation uses plain
>> > sockets, while Https uses SSL sockets. Thus we should use whether 2
>> > different connection pools (one for http, one for https) or 
>> indexing of
>> > sockets in the pool should be made by URL with non empty protocol part
>> > (i.e.
>> > "http://some.host/" or "https://some.host/") to distinguish http
>> > connections
>> > from https' ones.
>> This issue is just what we should discuss here, IIUI, the SSLSocket is
>> based on plain Socket, too, and it is created by
>> SSLSocketFactory.createSocket(Socket....), so we have several options 
>> here:
>> 1. cache plain socket and ssl socket in different pool by same mechanism
>> 2. cache them in same pool with different index (IMO it has no
>> significant difference with 1)
> The first variant seems to have better performance, but we should 
> analyze it.
>> 3. cache plain socket only, and create ssl socket over them on demand
>> 4. handle ssl issue over the HttpURLConnection, so that
>> HttpsURLConnection don't need to care about the persistent issues (as
>> you said above)
> We can not mix up SSL sockets with plain ones. HttpUC should not reuse
> socket created by HttpsUC because server side will expect encrypted
> data on SSL connections and will fail if receive plain text (sent by
> HttpUC).
> Persistent connection mechanism should be implemented in HttpUC in
> such a way that it could store SSL and plain sockets and distinguish
> them.
>> I'm sure you have more authority on SSL layer issue than me, so would
>> you please help to evaluate the feasibility and performance impact of
>> the above?
> I think we should follow 1st or 2nd variant which are practically the
> same in sense of implementation.
> Thank You,
> Alexander
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Paulex Yang
China Software Development Lab

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message