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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
