[bittorrent] Why are blocks smaller than pieces?
ryanwalklin at gmail.com
Sat Sep 8 18:17:19 EDT 2007
Well, typically requests (and therefore blocks) are 16kb (so that slow peers
and high latency links don't cripple swams), compared to typical piece
sizes, which are between 128k to 4mb or more (no real limit).
Consider a 20gb torrent with 16kb pieces, the consequent size of the
.torrent file, and more importantly, the protocol overhead required to send
massive bitfields and the numerous HAVE messages. You're quite right though,
this means there is a vulnerability where we cannot identify peers sending
bad data (unless they are the only peer sending a piece). I have implemented
two ways round this in my client/library.
First, I use the Bluetack Level 1 (Anti-P2P) IP blocklist (www.bluetack.org)
to ban known bad peers on connection.
Secondly, when a piece fails hash-checking, I increment a counter for each
peer associated with that piece, and reassign each peer to a different
block. Conversely when a peer is associated with a good hash I decrement the
counter by 2.
The result is that peers consistently associated with (and therefore likely
to be sending) bad data quickly build up a large positive value. I've found
that disconnecting and banning peers with a counter of 3 or above is a
highly effective way to weed out "bad seeds". Because this method is not
foolproof (it bans by association only) I only ban per-session.
Hope that's useful. Certainly that is a weakness neccessitated largely by
the dynamics of sending (very) large files over potentially slow links, but
it can be worked around.
On 9/9/07, Guido Seifert <tanuki64 at gmx.de> wrote:
> sorry if this has been answered 100 times. In the archive I could not find
> something about my problem. I am currently working to understand the
> protocol. When I learned that the smallest fraction of data is not
> actually a
> piece, but a block and there can be several blocks in a piece, I wondered
> this isn't a weakness, which can be exploited by malignant clients.
> I know cases from emule, where such clients on purpose sent corrupt
> pieces. Since
> in emule every single pieces can be hashed, it is no problem to identify
> clients and block them.
> In bittorrent I cannot hash a single block. A client, which sends corrupt
> cannot be identified without tremendous efforts. If I wanted to disrupt
> download I'd modify a client that for every piece it sends one corrupt
> Are there provisions to protect onself against such a denial of service?
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent