hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "ConnectionManagementDesign" by RolandWeber
Date Sat, 13 Jan 2007 10:00:47 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change
notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign

The comment on the change is:
added design ideas, renamed some sections

------------------------------------------------------------------------------
   route:: a sequence of proxies leading to a target. For all practical purposes, a route
is either direct to the target or via one proxy. The route is either using plain HTTP, or
TLS/SSL directly to the target, or TLS/SSL over a tunnel via the proxy. Tunnelling a plain
HTTP connection via a proxy is possible but unusual.
  
  
- = Discussion =
+ = Analysis =
  
  == Usage Patterns ==
  
@@ -58, +58 @@

  While TLS/SSL client authentication is out of scope for !HttpComponents, NTLM authentication
is not and needs to be considered.
  
  
- == Implementations ==
+ == Implementation Review ==
  
  The {{{SimpleHttpConnectionManager}}} in !HttpClient 3.x has exactly one connection. It
is re-used only for exactly the same route. No limits need to be enforced.
  
@@ -66, +66 @@

  
  A more sophisticated connection manager could provide performance benefits for !HttpClient
4.x. In particular, re-use of plain connections to a proxy for all routes via that proxy has
potential. Even more so if the proxy requires NTLM authentication and the previous authentication
state can be re-used.
  
+ 
+ = Design Ideas =
+ 
+ Connections should be requested from a connection manager with a specification of the intended
route. The connection manager returns a connection which is either closed, matches the route
exactly, or is a prefix of the route. We need representations for the intended route and for
the actual route of the returned connection. Connection managers can compute internal keys
for connection lookup based on the routes.
+ 
+ Routes are established outside of the connection manager. When the connection is released,
the connection manager needs to know which route has actually been established. The connection
may be closed, the full route may have been established, or a prefix thereof. Of course there
might also be misbehaving applications that establish a route different from the one for which
the connection was allocated.
+ [[BR]]
+ Tracking of the steps can be done by the application, by the connection, or by the connection
manager. Tracking by the application opens a gaping hole for connection management problems
that are very hard to analyse and debug. Tracking by the connection or connection manager
is functionally equivalent. The connection could call back to it's connection manager, and
the connection manager would require the connection as an argument. This kind of tracking
requires a set of methods that correspond to the steps in establishing a route:
+  * open connection to target/proxy
+  * tunnel connection to target
+  * layer secure connection over tunnel
+  * authenticate against target/proxy (connection based authentication only)
+ Optionally, establishing of a route different from the intended one could be prevented by
the connection or connection manager.
+ 
+ Route representation does not need to cover routes of arbitrary length. For practical purposes,
there will be at most two hops: target and proxy. A modifiable route representation is useful
for tracking. A non-modifiable route representation could be useful for lookup keys and return
values. A sophisticated connection manager will probably need different lookup keys though.
Options:
+  * route interface plus both a modifiable and non-modifiable implementation, similar to
{{{StringBuilder}}} and {{{String}}}
+  * modifiable route representation only, similar to {{{HostConfiguration}}} in !HttpClient
3.x
+ The target and proxy can be represented by {{{HttpHost}}} objects. This identifies schemes
(HTTP, HTTPS) by their name. It does not cover cases where applications use different socket
factories for the same scheme. That's not likely to be a problem.
+ [[BR]]
+ Route length (direct/proxied) and tunnelling state can be represented by {{{boolean}}} values.
Using {{{int}}} for the route length would allow for custom implementations of more complex
routes (with the interface option), but the restriction to two hops will probably show up
elsewhere too.
+ [[BR]]
+ Generic {{{Object}}} instances can be used to represent connection based authentication
state. Two objects are required for proxy and target authentication. Comparison relies on
the generic {{{equals}}} method. Applications can use whatever is considered appropriate to
represent the authentication, for example:
+  * {{{CredentialsProvider}}} for NTLM authentication. If a route is requested with the same
{{{CredentialsProvider}}}, the same credentials would be available and so the authentication
state can be re-used.
+  * {{{SSLSocketFactory}}} for TLS/SSL with client authentication. The socket factory uses
a unique key store, so the same credentials would be available and the authentication state
can be re-used.
+  * A key store for TLS/SSL with client authentication. This is a variation of the {{{SSLSocketFactory}}}
option.
+  * application specific user object for applications dealing with more complex multi-user
scenarios
+ Modifiable objects for representation of authentication state have implications if used
in a non-modifiable route representation. This would need to be documented carefully, but
the problem is not different from using modifiable objects as lookup keys.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message