[bittorrent] question on the blocks downloading in BT

David P. Mott dpmott at sep.com
Mon Jun 13 10:53:58 EDT 2005

I'm wondering if everyone is using the same termonology on this thread of 

To quote the WIKI (located here: 

piece v/s block: In this document, a piece refers to a portion of the 
downloaded data that is described in the metainfo file, which can be 
verified by a SHA1 hash. A block is a portion of data that a client may 
request from a peer. Two or more blocks make up a whole piece, which may 
then be verified.


The request message is fixed length, and is used to request a block. The 
payload contains the following information
   index: integer specifying the zero-based piece index
   begin: integer specifying the zero-based byte offset within the piece
   length: integer specifying the requested length. This value should
           normally be 2^14 (16384) bytes. Smaller values may be used
           but are usually not needed except in rare cases like a piece
           length not divisible by 16384.

The observant reader will note that a block is typically smaller than a 
piece (which is commonly >= 2^18 bytes). A client may close the connection 
if it receives a request for more than 16384 bytes.

Note that there is nothing here that defines a block, except for a size. 
A peer may request any block of data, starting at any (legal) offset, of 
any size up to the maximum, where the maximum is generally enforced only 
by the clients.

There's nothing keeping a peer from *requesting* an entire piece; other 
peers will likely disconnect them because the request is too big.  It 
seems that the goal here is to maximize throughput of small blocks of data 
so that if/when peers *do* drop out of the network, you're only 
interrupting a small block transfer, not a big piece transfer.

So, there's also nothing keeping you from requesting (for a given piece) 
1/X blocks from all of your connected X peers, such that if/when they all 
get the requested data to you, then you'll have an entire piece.  If the 
piece then fails SHA1 hash checking, then you have to go through some 
other steps to determine who is sending you bad data.

Or you can request all blocks for a given piece from one peer.  For a 
large (or, at least, not trivially small) torrent, this isn't a bad 
strategy.  Given X connected peers and at least X pieces to satisfy in 
your torrent, you can (internally) associate a peer with a given piece, 
and only ask that peer for blocks of that given piece.  Assuming similiar 
transfer rates across all of your connected peers (which is probably *not* 
reasonable), your torrent will finish in about the same time as if you 
sent block requests to random peers who are not choking you.

So, the whole point of this post was to point out that the size and 
positioning of "blocks" is not defined in the protocol, because it's not 
supposed to be fixed.  You can request any "block" of data that you want, 
as small as one byte, and as large as the generally accepted maximum which 
may be 2^14 or 2^15.

This is confusing since the bittorrent message that carries the content 
data is named "piece", but you don't really request a piece.  You request 
a block, which is a subset of a piece.  Perhaps the spec should have named 
the message "piecepart" or "block" or just "response", since the 
initiatiating request is just named "request".

Note: The "official" bittorrent specification has this to say about the 
request message:

'request' messages contain an index, begin, and length. The last two are 
byte offsets. Length is generally a power of two unless it gets truncated 
by the end of the file. All current implementations use 2^15 , and close 
connections which request an amount greater than 2^17. 

More information about the BitTorrent mailing list