[BitTorrent] Re: bt2 protocol features
Olaf van der Spek
OvdSpek at LIACS.NL
Mon Jun 7 16:49:17 EDT 2004
Justin Cormack wrote:
> On Sat, 2004-06-05 at 19:37, xtf2007 wrote:
>>--- In BitTorrent at yahoogroups.com, Bram Cohen <bram at b...> wrote:
>>>The main sticking point left is how to deal with piece sizes -
>>>peers should be using the same piece size, but whether that's a
>>>to require and if so (or even if not) how to set it I'm not sure of
>>>Also I'm not sure how to make trackers support scrape functionality
>>>more to the point, I'm not sure how much scrape functionality to
>>>over, and in what way). Other than those issues all that's left is
>>How about this?
>>A merkle tree with 1 kb block size is generated for each file.
>>Each file in a torrent is divided into 2 mb macro blocks.
>>Each macro block is divided into 16 kb micro blocks.
>>The bitfield message will contain one bit for every valid micro block.
>>The have message will contain a 32-bit macro index and a 32-bit micro
>>The want message will look like the have message.
>>The piece message contains a 32-bit offset without the last ten bits
>>and 1 kb data.
>>The index/bitfield combo allows you to specify any set of 0 to 32
>>micro blocks within one macro block.
>>There is a request/response pair of messages to transfer the hashes
>>of all macro blocks up front (40 kb for a 10 gb torrent).
>>There is also a request/response pair of messages to transfer the
>>hashes of all micro blocks in a macro block (640 b).
>>During normal operation, the bitfield of have/want messages will be
>>But at startup, a have for a partial macro block might be broadcasted
>>to start uploading much faster.
>>And when a macro hash check fails, the micro hashes can be downloaded
>>to pin down the fauly micro block(s).
> Having two levels of block size seems rather complex. It would be much
> simpler if blocks were say 1k or 4k. But it might be possible to make a
The reason to have small blocks is to have a low startup time (time
until first block is complete) and so you don't need to discard much
data in case a block verification fails.
The reason to have large blocks is to decrease the amount of overhead
the HAVE messages generate, the amount of hashes you need and the amount
of state the client needs to maintain.
> more compact descriptor than a bitmap, by specifying ranges of blocks
> you have and dont have, as these are particularly short in the cases of
> clients with all or none of the blocks, and also for clients that dont
> download blocks completely randomly.
For a 10 gb torrent, the BITFIELD message is only 640 bytes, so I doubt
you can make it much shorter.
A range would need two 32-bit integers and that'd take up the same
amount of space as 64 normal blocks, so you'd have to be large ranges.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Domains - Claim yours for only $14.70
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent