[bittorrent] Proposed Extension to Peer Protocol

Alan McGovern alan.mcgovern at gmail.com
Sun Nov 12 11:18:56 EST 2006

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?

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.

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


On 11/12/06, Adrian Ulrich <torrent at blinkenlights.ch> wrote:
> > There are legit cases where these messages would prove useful in
> real-world
> > usage. Suppose i send a peer piece 16 of a torrent, and it turns out to
> be
> > corrupt on their end. Wouldn't it be nice if that peer sent a message
> back
> > to me saying that the piece was corrupt?
> So an evil peer could force you to do a lot of hash-checks ? yieks!
> > on it and (optionally) resend it (assuming the peer sends a new request
> for
> > it to me).
> This might help your peer but doesn't do any good to the network:
> #1:
> If your peer happens to send bad data it will get blacklisted/muted by
> a lot of other peers anyway (= removing the 'problem' from the swarm).
> #2:
> What would you do after finding a corrupted chunk? BitTorrent doesn't
> provide a 'i don't have anymore' message. So you'd have to disconnect
> from all clients and restart with a new bitfield.
> #3:
> Such a thing doesn't cure the real problem: If your peer happens to have
> bad data it might
> a) be an evil peer (..who'd also ignore such messages anyway)
> b) bad hardware (..so sending bad data would happen again anyway)
> I don't think that the Protocol itself should deal with such specific
> client-side issues.
> Regards,
> Adrian
> --
>             A. Top posters
>             Q. What's the most annoying thing on Usenet?
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20061112/10f0b72b/attachment.html 

More information about the BitTorrent mailing list