[BitTorrent] Re: bt2 protocol features

Elliott Mitchell ehem at m5p.com
Mon Jun 7 17:44:02 EDT 2004


> From: Olaf van der Spek <OvdSpek at LIACS.NL>
> Elliott Mitchell wrote:
> >>From: Olaf van der Spek <OvdSpek at LIACS.NL>
> >>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.

Yes, but how large is that? 8-12 additional bytes is not much additional
data unless you're sending out *lots* of them (either a tiny block size
or a massive number of peers).

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

Okay, so care has to be taken, but this doesn't kill the idea.

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

Doesn't look that way to me.

A particular implementation _may_ cause this, but it is not a
requirement. Even if it does, the protocol may already force it; and even
if perhaps inelegant, this may end up being the simplest way to do things
anyway.



So I'll admit care will be needed, but care will be needed anyway. If
some requirement makes it absolutely impossible, _then_ this will need to
be removed. Until that time do you object to this remaining an idea to
_try_ to put in place?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/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