Chunksizes of 97 KB
 

Hi,

I am not currently using LimeWire myself currently, but I noticed that LimeWire users in most cases request a download from my Gnutella client with chunk sizes of 97 KB over and over again, even for big files.

97 KB is quite a small chunksize. Other Gnutella clients (e.g. GTKG) have chunksizes of 500 KB minimum and 5 MB maximum (but this is configurable). Small chunksizes mean lower throughput when downloading/uploading files, because a new connection must be established more often and the risk also is that the upload slots are full on the server previously connected to. For fast connections (e.g. T1 or T3) such small chunksizes really are a pain, because the 97 KB are transferred in fractions of seconds, but the request for the next 97 KB chunk takes some seconds.

I request that the minimum chunksize for LimeWire is increased to ~500 KB or more and that the actually used chunksize should depend on the filesize.

Re: Chunksizes of 97 KB
 

The TCP connection is persistant - it won't be dropped and reestablished until the download is completed. Only the HTTP headers are exchanged once again after a chunk has been downloaded.

"The TCP connection is persistant - it won't be dropped and reestablished until the download is completed"

Many of my up/downloads seem to disconnect/reconnect (or worse--requeue/requery) after 97.7 chunks. Is this related to the "handshaking" problem?

When the HTTP handshakes are exchanged the GUI would show that you are "connecting...". The connection is never lost. If it was lost, the transfer would not continue at all.

Well, even if the connection is not dropped, the used chunksize could be larger. On a fast connection, it seems like LimeWire hammers on a host to get those tiny chunks over and over again. Wouldn't it be better if LimeWire would try to download bigger chunks or at least increase its chunksize over time (e.g. once it sees that a certain number of chunks have been delivered by a specific host)?

Hmmm. Tooltip's observation that "the 97 KB are transferred in fractions of seconds, but the request for the next 97 KB chunk takes some seconds" seemed to match the connection problems I'd noticed in java clients. Making chunksize dependent on connection quality sounds good (this isn't "handshaking?").

In Acq.74 the "error: Unable to move to download folder" relate to 97.7 chunks (it's easier to notice at the start of a download when I can roughly estimate multiples), so I'd guess it's a limewire core problem. The kill/resume trick can babysit some downloads to completion from the same host, but unless automated, wouldn't seem to be enough to "hammer" the host.

Might hosts drop the TCP connections if the HTTP was unexpectedly slow or the user killed it, and can't I trigger a TCP reconnect?

Of course it might slow the download down a little bit if the http headers have to be parsed again but that doesn't even take one second. I suspect the period of time a download remains in a 'Connecting...' state depends more on the refresh rate of the GUI.

LimeWire does not retry hosts if the TCP connection failed because it assumes that a remote host won't drop a TCP connection without a reason. Kill/Resume will cause LimeWire to retry a failed connection but you will loose all your alternate locations.