An evil peer could try and force you to do a lot of hashchecks, thats true. An evil peer could force you to do a huge amount of disk seeking by requesting 1 byte blocks from different pieces of the torrent. Hell, a peer could constantly send request messages followed by cancel messages to force you to read blocks into memory needlessly. Everything can be abused. The question is are the benefits worth it?
<br><br>If i were to receive a "your piece arrived corrupt" message, i could then run a hashcheck on that piece (or just ignore it). If it passes, well and good, it was just a transmission error or bad ram or something. But if it doesn't pass, i have to redownload those blocks from someone to fix the piece. If in the meantime someone requests that piece off me, i'll just postphone sending them the piece until it passes a hashcheck. That will stop me getting banned by other peers.
<br><br>Take a look at the TCP protocol. There are dozens of errorcodes for different events that might occur. In an ideal world, you wouldn't need em. But we don't live in an ideal world, so by recording what error the TCP protocol throws up at us we can figure out what went wrong with trying to send/receive data. This is a *lot* more useful than just the connection vanishing on us. Take a step up to the Bittorrent protocol. At the moment if something goes wrong, that's it. Connection cut. We don't know what went wrong, so we can't fix it. Thats the point i'm trying to make. It would be nice to be able to figure out what does go wrong (if something does go wrong).
<br><br>Alan.<br><br><div><span class="gmail_quote">On 11/12/06, <b class="gmail_sendername">Adrian Ulrich</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> There are legit cases where these messages would prove useful in real-world<br>> usage. Suppose i send a peer piece 16 of a torrent, and it turns out to be<br>> corrupt on their end. Wouldn't it be nice if that peer sent a message back
<br>> to me saying that the piece was corrupt?<br><br>So an evil peer could force you to do a lot of hash-checks ? yieks!<br><br>> on it and (optionally) resend it (assuming the peer sends a new request for<br>> it to me).
<br><br>This might help your peer but doesn't do any good to the network:<br><br>#1:<br>If your peer happens to send bad data it will get blacklisted/muted by<br>a lot of other peers anyway (= removing the 'problem' from the swarm).
<br><br>#2:<br>What would you do after finding a corrupted chunk? BitTorrent doesn't<br>provide a 'i don't have anymore' message. So you'd have to disconnect<br>from all clients and restart with a new bitfield.<br><br>#3:
<br>Such a thing doesn't cure the real problem: If your peer happens to have<br>bad data it might<br> a) be an evil peer (..who'd also ignore such messages anyway)<br> b) bad hardware (..so sending bad data would happen again anyway)
<br><br><br>I don't think that the Protocol itself should deal with such specific<br>client-side issues.<br><br><br>Regards,<br> Adrian<br><br><br><br>--<br> A. Top posters<br> Q. What's the most annoying thing on Usenet?
<br>_______________________________________________<br>BitTorrent mailing list<br><a href="mailto:BitTorrent@lists.ibiblio.org">BitTorrent@lists.ibiblio.org</a><br><a href="http://lists.ibiblio.org/mailman/listinfo/bittorrent">