Standards (was [BitTorrent] Back to Merkle Hash Trees...)
Olaf van der Spek
OvdSpek at LIACS.NL
Tue Feb 8 12:54:30 EST 2005
Justin Cormack wrote:
>>The first thing any peer does, is get the info. The info is probably
>>very small (size depends on the file count), so would that really be an
> I think it can be. If a lot of peers connect to a torrent at once, most wont
> have it. If you request it what should they do? You dont mention this case.
True, but my document isn't about that. The URL format is an idea for
> Presumably you should only ask one peer at a time for it (or you run the risk
> of eating bandwidth by getting multiple copies) so if a small proportion of
> the peers have it it can take a long time to find them.
A have_info would solve that.
>>But what is the advantage over 32k? Do you consider 32k too large?
> Well 32k might be reasonable if piece = chunk = 32k if there is not too much
> overhead in sending out have messages. Not having piece and chunk simplifies
> things. Actually I would pick 65536, and then use 48 bit chunk numbers,
> bacause I am tidy minded that way... Its an improvement over the current
> (typical) piece size of 256k or 1M. The main reason this was so high was
> because of size of torrent file.
> Doing the maths, a 4G file with 64k pieces/chunks will have 64k of them,
> which means a bitmap is 8k, which is smaller than a request (64k) so
> thats not a huge transfer. you will get 64k have messages (worst case)
> which is 512k. These figures are per peer.
> Actually the file size for which the request size = bitmap size is:
> 64k chunk: 32G
> 32k chunk: 8G
> 4k: 128M
> With 4k pieces/chunks the bitmaps get too big (128k) especially compared
> to the transfer size which has gone down to 4k. You clearly need to change
> how these are encoded.
> In fact if we dont want to change the encoding you could specify the
> piece and chunk size by this rule...
> Your scheme where you can transfer and verify 32k chunks but cant tell
> anyone you have them until you get enough to make an arbitrary larger
> piece doesnt make much sense to me. It is a kind of lossy compression
> of have and bitmap messages in effect.
You can tell everyone that you have them if necessary/useful, that's
what chunk_have is for.
And the disadvantage of a larger chunk size is that a peer is required
to send the entire chunk (or to close the connection). This is related
to the choking algorithm.
And you don't have to redownload 'chunks' if a 'piece' fails (advantage
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