Hampus Wessman wrote: > True. Checking all available file hashes doesn't take much time anyway > (you only need to compute the downloaded file's hashes once), so you > have very little to lose really. > > One can safely ignore the chunk checksums in the metalink though, > unless you really want to be sure not to waste any time on bad torrents > (might not be worth all the extra hash checks, though). Perhaps it > would be useful with a way to specify a hash for a torrent? Then you > could easily and efficiently verify that it hasn't been replaced. A > lot better than waiting for a chunk checksum to fail (even after a > failed chunk checksum the client may not be able to tell from where > the bad data came!).
Why would it take more time to check more hashes? If both the metalink and the torrent have chunk checksums with the same chunk size, just see if both have the same checksums. Or, calculate chunk hash and compare it to both. The bottleneck is I/O, not CPU. You can compute sets of chunk hashes for different chunk sizes *and* the full-file hash "at the same time" (reading the file only once). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
