Hi Sam and all
I finally had time to take a closer look at this code and I think this
is certainly something you want to draw upon in the future when
developing http-asynch. However, exactly when this is going to happen
is
a matter how we set priorities.
This is how I see things in a sort of semi-random rambling, so take it
for what it is worth.
(1) HttpCommon already makes use of NIO, albeit in the blocking mode.
So, it should already benefit from performance improvements offered by
new *Buffer and CharsetEncoder/CharsetDecoder classes
(2) A significantly more complex non-blocking I/O hardly makes a lot of
sense on the client side, where the number of concurrent connections
should never exceed a few dozens at max. The extra complexity of non-
blocking I/O is justified only when the number of concurrent
connections
gets over 500.
(3) The servlet 2.x API is still based on the blocking InputStream /
OutputStream paradigm. Currently Servlet 2.x API is de-facto standard
server-side HTTP framework, which limits the pool of potential users
for
non-blocking HTTP.
(4) Embedded HTTP servers may never be required to deal with hundreds
of
concurrent connections, which again makes non-blocking I/O more of a
burden than any real benefit.
(5) At the same an NIO based, scalable server-side HTTP framework is
probably the only way we can attract any interest beyond our existent
user base.
So, the real question is how we set our priorities and allocate our
rather limited resources and what should happen first: promotion to
Jakarta level, HttpClient 4.0 (and therefore http-cookie, http-auth,
and other dependencies), a lightweight server based on a subset of
servlet API, Tomcat Connector based on HttpCommon, something else? In
which sequence?
What do you think?
Oleg
On Sun, 2005-06-05 at 20:13 -0400, Sam Berlin wrote:
Hi Folks,
I recall earlier posts mentioning that HttpClient 4.0 was going to
offer
blocking & non-blocking variations, so that multiple requests (or
responses,
in the case of the server side) could use a single thread. Since I
did
offer LimeWire's support with some of HttpClient 4.0's development, I
figure
I should follow up on that. :)
We've recently completed converting LimeWire's messaging code to be
non-blocking while still allowing blocking use. The package has two
external depencies (used in a single file, for easier error
reporting) which
can easily be removed (other than that, it uses commons logging &
java.net,
java.util, java.io, and java.nio classes).
The architecture may work well for HttpClient. The basic concept is
that
reading & writing use the decorator pattern. So, for instance, you
could
have a HttpHeaderWriter, HttpBodyWriter, and a DeflaterWriter. When
writing
headers, you would set the 'writer' to be an HttpHeaderWriter. When
writing
the body, you would set the writer to be the HttpBodyWriter,
potentially
settings its writer to be the DeflaterWriter. With reading, it'd be
very
similar, an HttpHeaderReader, HttpBodyReader, and InflaterReader.
There's
also the equivilent of BufferedOutputStream, a DelayedBufferWriter,
which
one-ups BufferedOutputStream in the sense that it will try to buffer
all
output (writing only when the buffer is full, to reduce the nmber TCP
packets sent), but if the buffer hasn't filled in X milliseconds, it
will
force the data to be written. It's also possible to add a
ThrottleWriter
(and share a Throttle among multiple ThrottleWriters) which will
limit the
outgoing throughput (allowing a fair share for each ThrottleWriter).
It is possible to use blocking i/o for a portion of the transfer, and
then
convert it to non-blocking, although I'm not sure how useful it is for
HttpClient. Internally, the transfer is actually non-blocking, but it
emulates the blocking portion (somewhat better than Sun's blocking
emulation
with configureBlocking(true)). To use it, all you have to do is
change new
Socket(...) to new NIOSocket(...), and new ServerSocket(...) to new
NIOServerSocket(...). I do not know how convenient this is with the
SocketFactories that HttpClient has. I imagine there could be new
NIOFactories which would subclass the existing ones.
Non-blocking connecting currently isn't supported (neither is
non-blocking
accepting), but they're trivial to add and we're likely going to add
support
soon.
As an example DeflaterWriter & InflaterReader, see
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/
gnutella/conn
ection/DeflaterWriter.java?r=1.2 (Deflater) and
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/
gnutella/conn
ection/InflaterReader.java?r=1.2 (Inflater). Right now they're in a
separate package, but they'd fit really well in the io package.
As an example 'top level writer/reader', see our MessageReader &
MessageWriter:
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/
gnutella/conn
ection/MessageReader.java?r=1.4 and
http://limewire.org/fisheye/viewrep/limecvs/core/com/limegroup/
gnutella/conn
ection/MessageWriter.java?r=1.2 .
Thanks,
Sam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
