You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/06/16 12:20:03 UTC
[classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
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 <pa...@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
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented: (HARMONY-499))
Posted by Stepan Mishura <st...@gmail.com>.
On 7/24/06, Paulex Yang wrote:
>
> 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?
IANAL, I think it is OK to use the guide for implementing the same set of
system properties that control the connection behavior. But I'm not sure
that it is legal to use implementation specific names for them (like you
have mentioned - sun.net.http.errorstream.enableBuffering). May be it makes
sense to ask for permission like Geir did for exception messages and
toString() formats.
Thanks,
Stepan.
[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 <pa...@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
> >>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Paulex Yang wrote:
> 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
Yes, it seems that would be best, to ensure that existing programs work
as close to expected as we can.
geir
---------------------------------------------------------------------
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
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
Posted by Paulex Yang <pa...@gmail.com>.
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 <pa...@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