harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented: (HARMONY-499))
Date Mon, 24 Jul 2006 08:45:16 GMT
Seems no others interest in this;), so I'm going to assign harmony-617 
to myself and implement a connection pool if no one objects.

I may need a couple of days to implement and test it, so I plan to add 
the class skeleton to o.a.h.luni.net, and enrich them step by step, 
until at last I'll refactory HttpURLConnection to use it , maybe also 
need to refactor HttpsURLConnection, though I expect little modification 
needed for it. (Or I need to implement them in sandbox at first?)

A question is about RI's specific properties support[1], say 
|sun.net.http.errorstream.enableBuffering,| etc, do we need to support 
them, too?

[1] http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html

Paulex Yang wrote:
> Alexander,
>
> 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
IBM



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


Mime
View raw message