Checking multiple sets of chunk checksums, possibly having different lenghts, adds complexity to the client regardless of speed. IF they do have the same length, then of course you can compare each individual chunk checksum in the metalink and the torrent. They don't have to be.
If they don't have the same length and you download the file randomly, as bittorrent does, then it will get both complicated and most probably take more time to calculate the additional hashes (while downloading). I agree that reading the file once and computing all the hashes at the same time (as you said) is a good strategy, once the file is finished. The chunk checksums have hopefully been checked already at that time, though. If you have a slow or busy CPU it won't be I/O bound. It's obvious that it takes more resources to check more hashes. If that translates to more time depends on the system where it runs. What you say is probably true for many modern desktop systems (not necessarily all, especially not when compiling stuff in the background or similar). Not that it's necessarily a bad idea to make those checks, but IMO it might not be worth it (both when it comes to speed and complexity). It's a lot easier when the lengths match, so a middle way would be to only do it in those cases. As always I think it's up to the client programmer. I'm not sure if I would have done it. A hash for the whole torrent would make all this unnecessary and would be a lot easier. It would be just as easy (and effective!) when the chunks have different lengths too. Hampus On Tue, 12 May 2009 21:51:28 -0300 Nicolas Alvarez <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
