hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpConn] connection interface and implementation
Date Sat, 23 Dec 2006 13:03:31 GMT
On Wed, 2006-12-20 at 21:29 +0100, Roland Weber wrote:
> Hi all,
> 
> regarding HTTPCLIENT-602 (formerly HTTPCORE-8)
> https://issues.apache.org/jira/browse/HTTPCLIENT-602
> I'd like to share my ideas and get your feedback.
> Here is a more or less random collection...
> 

Hi Roland

Let me start with a few general comments and ideas. 

(1) First off, I think we can safely keep NIO out of the picture. The
process of opening a connection in non-blocking mode is completely
different from that in the blocking one.

* The user registers a request for a new connection with the connecting
I/O reactor:
http://jakarta.apache.org/httpcomponents/httpcore/jakarta-httpcore-nio/xref/org/apache/http/nio/reactor/ConnectingIOReactor.html

* At some point of the the I/O reactor fires one of the methods of the
session request callback
http://jakarta.apache.org/httpcomponents/httpcore/jakarta-httpcore-nio/xref/org/apache/http/nio/reactor/SessionRequestCallback.html

The process is very similar to the way server side sessions work:
connections are bound to a socket created by some external factory
rather than provide a facility to create a new socket internally.

I suspect we will never manager to come up with a generic connection
management API that works well with both. So, let us concentrate on
developing a clean API for the classic I/O. 

(2) HttpHostConnection is as ugly as hell and needs fixing.

(3) I am still of an opinion that connection tunneling is a special case
and should be treated as such. I think essentially the connection should
be able to re-bind itself to a new socket. That is it. It should not be
aware of any tunneling aspects.

(4) We should start thinking about changing the socket factory interface
to enable support for detached sockets
https://issues.apache.org/jira/browse/HTTPCLIENT-475

(4) Let us try to not over-engineer and keep stuff simple. In HttpCore
API flexibility was more important than API simplicity. In HttpClient
the priorities should be different.  

> interface: open, target
> Opening a connection should be possible as long as
> it is closed. For traditional blocking connections
> and (Secure)SocketFactory, we need to specify the
> target host and optionally the proxy host to which
> to connect. That can be done by separate setters
> before opening, or as arguments to an open method.
> I prefer the latter, how about you?
> 

The latter.

> interface: open while open
> For performance optimizations in HttpAsync as well
> as in a connection manager, it would be good if a
> connection can be opened without being closed explicitly.
> The idea is that it might be possible to avoid closing
> and re-opening, for example if different target hosts
> are accessed via the same proxy host.

Agreed. This might also help with connection proxying / tunneling.

> I'd rather leave this out initially. Oleg has to remind
> me on a regular basis that a series of smaller steps is
> better than a big jump. Not this time ;-)
> 
> connection states
> Currently, a connection is either open or closed. That's
> fine with the blocking IO model. It's also good enough
> for HttpCore, since we don't have an open() method there.
> If we had an asynchronous open() method, that is one
> that returns immediately and leaves the actual opening
> to an event handling thread, we'd have a third state:
> "opening". You can't use the connection for reading or
> writing yet because it's not open, but you can't open
> it either since that operation is already in progress.
> I'd really like to get input on that one, given my lack
> of experience with NIO. Should we have an asynchronous
> open method in the first place? Or make the open call
> blocking even for a NIO connection? Leave NIO totally
> aside in HttpClient/HttpConn? (I wouldn't like that.)
> If we introduce a third state, what's the behavior of
> read/write methods while in that state? Throw an exception
> or block until open? Should we define separate interfaces
> for traditional and NIO connections?
> 

See my comments above. I prefer to keep NIO out of HttpConn for the time
being.

> implementation: split open/close from read/write
> In the initial patch I provided for HTTPCORE-8, the
> connection implementation was a container for a socket.
> The connection "knows" how to write to and read from a
> socket, using IO or NIO depending on the implementation.
> Opening and closing was delegated to a different object,
> there called an operator. The advantage of this approach
> is that the open/close implementation is not tied to the
> actual connection implementation and it's read/write
> behavior. The drawback is an increased complexity of
> the interfaces.
> I am not sure how valuable the flexibility is that we
> would gain. Is there a need to freely combine different
> implementations for open/close and read/write? Or will
> we end up using only two combinations anyway, one for
> traditional IO and one for NIO? (or a single combination
> if NIO is left aside, see above) Is this another case
> where we should apply the small steps approach? I am
> most uncertain how NIO fits in here.
> 

May I suggest we leave this out for the first cut? If we see a need for
an extra API complexity in order to support real-world complex cases, we
can revisit this issue 

Happy hacking

Cheers

Oleg

> 
> I guess that's it for now. Thanks in advance for your
> thoughts on these matters, and for reminders about
> what I forgot.
> 
> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


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