Limewire DOES pay attention to both the filesize and hashes exposed in query hits.
It causes a problem with some BearShare sources that expose incorrect lengths...
The fact that this bug is produced by Shareaza not monitoring its locally modified files and spreading files to BearShare that forget to verify the file downloaded from Shareaza (to see if it matches its supposed SHA1) is not a problem of LimeWire.
If it causes LimeWire to hammer BearShare sources, it's certainly a problem, but the origin is still in Bearshare not verifying the data it sends to the network.
Limewire will integrate patches to detect the case of a file that has been modified on the BearShare host but that BearShare forgot to rehash after the change.
If your Bearshare is exposed to such hammering, you have a bug in BearShare that does not detect such changes in local files, and still accepts to upload files whose SHA1 hash should have been updated. If bearshare had detected this change, it would not reply successfully to the incoming transfer request, but would return a 404.
LimeWire on the opposite is actively monitoring possible changes that may have occured on the local files requested: When a transfer request comes in for a URN, the corresponding file is checked to see if its size or modification date has changed. If such change is detected, then the reply will be 404, the old file entry will be removed from the shared library, and the modified file will be immediately rehashed for future Query Hits.
That's why LimeWire maintains a local cache for shared file properties (name, date, size, precomputed URNs...)
Last edited by verdyp; May 24th, 2004 at 04:54 PM.
|