Jump to content

Multiple Hashing


streetstopper

Recommended Posts

I know that all clients check the hash of all pieces they receive.

However, with utorrent, pieces that are shared back (uploaded) are not hash checked (please correct me if I am wrong).

So is it possible that we could have this option?

Like for example, a leecher requests a block of a piece. Before my client sends it, it re-checks the whole piece then sends the requested block. If it fails, then it doesn't send anything. If it passes, then utorrent, sends the request.

I know that this will add to additional drive activity and may possibly eat more CPU resources but I think it would be better than being flagged as someone who sends bad pieces and gets kicked out, which eventually, I'd find myself connected to 0 peers.

Anyways, this would just be an option which the user can enable or disable.

What do you think guys?

Link to comment
Share on other sites

Why should a piece/block which is downloaded and has been hashchecked (= OK) before it was stored be hashchecked again when seeding?

If your feature would work and the hashcheck is OK on seeding too, why should your piece/block be OK "now" on the other side?

Link to comment
Share on other sites

thanks for the replies guys.

for one, not all machines are equal as regards integrity. there are machines that sometimes have hardware problems such that, while the piece is hashed okay, they are written incorrectly.

one way to avoid this is to turn off diskio.smart_hash.

but what about viruses, worms, and/or trojans which modify files? i am sure there are a few media players out there which modify media files as well, with or without our knowledge.

further, a force re-check can take a very long time especially on a very large torrent.

bottomline here is just integrity.

we all want to share pieces that pass the hash. if our machine's integrity is high, then we can turn this off. if we get kicked off of a torrent because of some unknown reason and find ourselves where, out of thousands of peers, we are only connected to less than 10 and the number is going down, we can try this option.

at the very least, if we find ourselves seeding a torrent, and this option flags a piece as having failed a hash check, then at least, our client can re-download that failed piece, thus correcting that "bad" piece and restoring our seeded torrent to how it should have been.

or maybe you can call this as "distributed force re-check" where re-checking is done not on one go, but as the torrent is seeded.

remember internet connection firewall that became windows firewall? they used to monitor incoming packets only. then we were all advised not to use it because it's not safe. we were told that we need something that monitors incoming and outgoing packets because that would be safer.

cheers!

Link to comment
Share on other sites

To streetshopper: If your machine really has such poor integrity, maybe you should replace or repair the suspect components (or the whole machine) before something more important gets affected.

If you are going to turn this thing on AFTER you realize you may have bad data, integrity means that you should recheck the whole file and see what other pieces have gone bad rather than just dealing with it "as it comes".

Link to comment
Share on other sites

thank you for response on this, Kazuaki Shimazaki.

nope, my machine is in tip top shape. the reason for this suggestion is the fact that i have seen persistent peers sending bad data. either they are actually poisoning the torrent or they actually have an integrity issue with their machine. however, i'll give them the benefit of the doubt and go with the latter.

Link to comment
Share on other sites

yep, related to that. but more of a failed hash check rather than got bad have. in fact, i can't even remember if i ever have gotten a "Got Bad Have." but i'd get "Failed Hash Check"s every now and then. sometimes, more often than what i'd consider normal.

and it's not limited to non-uTorrent clients.

in fact, in one specific torrent, i already got 82 hash fails from a 1.8.3 client. and i'm only at 52%. and considering that the pieces are at 4MB, imagine how much i needed to re-download? LOL!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...