[bittorrent] Re: BT protocol Q

David P. Mott dpmott at sep.com
Mon May 2 12:11:19 EDT 2005

My bad, I forgot to mention the client memory usage.  I was stuck on the
protocol aspect of it.

(Also, my apologies for not keeping the correct thread subject in my
previous post.)

So, to sum up, the protocol doesn't prevent having small pieces, but
current meta file creation tools tend to prevent this in order to reduce
tracker bandwidth and client memory consumption.

I was just pointing out (in response to Justin's post) that the protocol
doesn't expressly prohibit or forbid this.  For instance, for the original
problem stated, someone could create a torrent with small pieces that
could be completely requested in one 'request' message, and we could see
if the problem still manifests itself in the swarm.  I'm not recommending
that people do this in common practice.

I think we're on the same page.


On Mon, 2 May 2005, Mike Ravkine wrote:

> David,
>   Piece length is typically set automatically (that's how MakeTorrent does 
> it at least, and I know it's fairly popular), and is usually set in such a 
> way as to keep the torrent from growing no bigger then 40-50k.  Dropping the 
> piece size as you suggest has 2 consequences:
> 1) Bigger torrents.. using a 128kb piece size will double the current 
> standard torrent size, and effectively kill off the [very useful] ability to 
> scale piece length linearly with the filesize to maintain a constant torrent 
> size.
> 2) Memory use.  Particularly in python implementations of BT, memory use 
> grows substantially as you increase the number of pieces (I ran some tests a 
> while ago).
> --kRYPT
> David P. Mott wrote:
>> It does?
>> I thought that it said this:
>> * You can request up to 2^17, and you typically request 2^15.
>> * Piece length is almost always a power of two, most commonly 2^18 = 256 K
>> So, I don't see any reason (except for very large meta files) why you 
>> couldn't make the piece length 2^17 or smaller, such that you could request 
>> entire pieces at once.
>> The large size of the meta files, however, is the other nasty part of BT, 
>> and has historically hindered scalability across large trackers because of 
>> the bandwidth required to download them.
>> (Somebody correct me if I'm wrong on any of that...)
>> All of that led to the extended discussion and foray into Merkle trees, 
>> which was supposed to keep the meta file small and still let you request 
>> entire (and small) pieces.
>> Still waiting for BT 2.0... any word on if/when it'll ever see the light of 
>> day?
>> -dpmott

More information about the BitTorrent mailing list