[bittorrent] Re: BitTorrent Digest, Vol 2, Issue 18

Mike Ravkine krypt at mountaincable.net
Mon May 2 11:06:12 EDT 2005


    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).


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