[BitTorrent] Re: bt2 protocol features

John Prevost j.prevost at gmail.com
Thu Jul 15 20:07:21 EDT 2004

On Thu, 15 Jul 2004 16:38:28 -0700 (PDT), Elliott Mitchell <ehem at m5p.com> wrote:
> Looking at the statistics, it looks like the mainline look for
> 35 peers is pretty reasonable, while the general number cited
> for bandwidth aproximations, 100, is pretty ridiculous. I think
> clients should take steps to strongly discourage users from
> changing it as it won't help them.

I completely agree there.  The 100 peer number is one that I think
people pick because it's ludicrous, but still within the realm of
possibility.  I usually use around 30, but sometimes go as high as 50
(primarily to increase the pool of peers I might talk to with these
ludicrously large torrents--8GB with 2MB pieces does seem to perform
marginally better with 50 than with 30 peers.)

> I doubt this approach will be useful. Your IP stack should deal
> with buffering fairly well. The problem is the raw number of
> HAVE messages, not their size.

Ahh, perhaps you misunderstood.  It's not the size that I was
wondering about, it was in fact the number.  If it's possible to make
the change I suggested, then instead of sending a HAVE message
whenever you complete a piece, you would send either a large number of
HAVE messages or a single HAVEMANY (or whatever) message when you
unchoke that peer.  Now instead of sending tiny messages at randomly
distributed times to every single peer that you're connected to, you
send fairly frequent updates to your unchoked peers (typically around
five peers), and whenever you unchoke a new peer (once every ten
seconds at most, once every thirty seconds if your non-optimistic
unchokes are relatively stable) you would end one large message.  That
change in behavior ought to decrease the amount of TCP overhead

> Yup. Ideally a preliminary protocol proposal so we can see if
> we can suggest refinements.

That would be pretty wonderful, yes.  :)

I do like your idea of helpers being able to work on torrents that
they don't have full information about, by the way.  But I'm not sure
that the mechanisms you suggest are entirely necessary.  With hash
trees, I don't think it will be *possible* to prevent a random
observer from discovering the size and order of blocks in the file,
which makes dancing to avoid exposing that information rather
fruitless.  If it could decrease the amount of metadata that a helper
needs to have available, that might be nice--but I don't think it's
going to help on that front.  (I'd be surprised if it was easier to
cache pieces based on root-hash * piece-hash than to cache based on
root-hash * index.)


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70

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 mailing list