Re: NIO uploads and downloads

Converting the download to using NIO will implicitly reduce the number
of threads.  The LimeWire NIO infrastructure was designed to work as a
state-machine in a single thread (and may not work if used in multiple
threads).

That said, it'd be pretty easy to take write a DownloaderChannel class
that's almost exactly like com.limegroup.gnutella.io.NIOInputStream &
use a java.nio.charset.CharDecoder to easily read HTTP Headers (and
read directly from the buffer for the body).  The two hard parts will
be adding support to tiger tree handling (and DIME) to read from
something other than an InputStream, and making reading & writing
(which will require its own channel class probably) from/to the socket
act in step.

Sam

On 10/16/05, Gregorio Roper <[email protected]> wrote:
> My idea was to have the HTTPDownloaders read the data directly from the
> socket to MappedByteBuffers. Since this won't be possible using
> Input/OutputStreams I want to make the whole downloader use NIO.
> Reducing the number of threads wasn't my primary goal and I'm not sure I
> would want to do that during the first pass...
>
> mfg
> gregorio
>
> Zlatin Balevsky wrote:
> > A much less intrusive change that will have bigger and more
> > immediately visible benefit would be moving the verifying file to use
> > memmapped files.  For a large number of downloads all going at high
> > speeds, the difference in disk seek times, paging and general disk
> > load is staggering.  While it may sound like a trivial change, there
> > are several issues that need to be considered, the main one being the
> > 2GB process limit which makes it impossible to mmap more than 2GB of
> > data through java.
> >
> > Addressing this issue will not only result in faster downloads (yes,
> > they easily become limited by disk throughput) but will have very
> > positive effect on the commonly experienced "LimeWire slows down my
> > computer" complaint.  Admittedly, reducing the # of threads will
> > indirectly reduce memory usage which will in turn reduce OS paging,
> > but at the moment the overwhelming majority of disk load is generated
> > by the RandomAccessFile activities.
> >
> > Also, moving other parts of the nio engine to use direct buffers
> > and/or optimized routines (uploads for example could use
> > FileChannel.write(OtherChannel)) can also yield some benefit.
> >
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>

_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev