Quote:
Originally posted by verdyp
Your arguments would be valid if only you said which Limewire version is causing such hammering. Can't you see that version number in your incoming download requests?
May be the looping problem is already fixed in LimeWire 4.0 and only affects previous releases (3.8.9 and 3.8.11 were common before 4.0 was released; all 3.9 versions were betas which were much less deployed). |
the title of the thread is "limewire (3.8.9, 3.8.10, 4.0.4) downloading from bearshare (4.5.0bXX)." what more limewire version info do you want?
Quote:
Originally posted by verdyp
I did not say that we won't check the code and won't correct it; |
from the bearshare forum thread, posted by "pve", whoever that is:
"It won't be fixed. This 10-bytes overhead is not a bug, but needed for checking fast sources that incorrectly return fake SHA1 values."
Quote:
Originally posted by verdyp
it's just that your analysis of the problem is not enough to isolate and solve the problem, caused by older versions of BearShare and Shareaza. |
talk to john lindh. he apparently (read the bearshare forum thread) DID determine that limewire is being confused by a shareaza (x-available-ranges) bug. later, we realized that there was a similar bearshare bug (modifying a file that's already being shared can fail to change the file's advertised hash on SOME versions of bearshare - but not the version i'm running).
in other words, one or more (buggy) bearshare sources may be advertising the same hash even though the file is different (longer) on those sources than on my source. limewire should know both the hash and size advertised by all sources. if hash1 == hash2, but size1 != size2, they're obviously not the same file. limewire should realize that. the hash CANNOT uniquely identify files - you need the size. of course, even then, it's possible to have hash1 == hash2 and size1 == size2 and still have different content, because the hash contains less info than the file itself - but different sizes obviously means different files, regardless of hash.
or it could simply be some other kind of limewire bug, where when there are exactly 10 bytes left in the source, limewire comes up with some weird-*** end-of-last-chunk value. the limewire request/bearshare response pairs captured and posted in the bearshare forum thread seem to support this theory.
please understand the problem before considering or rejecting potential solutions.