[BitTorrent] Re: bt2 protocol features

Olaf van der Spek OvdSpek at LIACS.NL
Mon Jun 7 16:56:30 EDT 2004


Elliott Mitchell wrote:
>>From: Olaf van der Spek <OvdSpek at LIACS.NL>
>>dpmott at sep.com wrote:
>>
>>>--- In BitTorrent at yahoogroups.com, Bram Cohen <bram at b...> wrote:
>>>
>>>
>>>>>Related thing, how about peers refering to pieces *strictly* by 
>>>>>hash?
>>>>
>>>>It turns out that the size of those hashes can be fairly 
>>>>significant, and the program logic winds up doing a lookup to 
>>>>translate back from hash to index on the other side anyway.
> 
> 
>>>Let me know if any of this is wrong...
>>>
>>>If you were to eliminate the "offset" and "length" fields when 
>>>requesting a chunk, and make the chunksize appropriately small, then 
>>>you could just request a chunk by offset.
>>>
>>>And, you can request a validation hash for each chunk.
>>>
>>>And, this approach would elminate that whole "chunk" and "piece" 
>>>distinction...
>>>
>>>Is any of that wrong, or undesirable for some reason?
>>
>>Yes, a piece size of between 16 kb and 64 kb would be required and that 
>>would significantly increase the protocol overhead compared with 2 mb 
>>pieces.
> 
> 
> Really?

You'd have to send more HAVEs and you need more hashes.

> The mainline client by default already requests chunks in mere 32KB
> chunks and will ignore requests larger than 256KB. Even if this size has
> to be shrunk pipelining on the client is a trivial solution (and again,
> already implemented on the mainline client). The use of Merkle trees will
> also force hashes to cover smaller pieces (which is a good thing because

That depends on the actual implementation of merkle trees.

> a client will no longer be able to get credit for uploading garbage).
> 
> Next argument please.
> 
> 
>>And at such sizes, you're running into limitations of current HDDs when 
>>it comes to random IO, especially on high-bandwidth links.
> 
> 
> Hmm, we can already cause this by requesting random chunks of random
> pieces with the existing protocol. The solution of course is to request
> chunks that are clustered together, and possibly have a client impose a
> slight penalty when discontiguous chunks are requested.

True, but that'd introduce the concept of another block size larger than 
chunks again.


-- 
Olaf van der Spek
http://xccu.sf.net/


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
     BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 



More information about the BitTorrent mailing list