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