[BitTorrent] Re: bt2 protocol features
j.prevost at gmail.com
Thu Jul 15 13:07:55 EDT 2004
Oops--yes, a number of incorrect values in my message. This is what I
get for doing back-of-the-envelope calculations in my head while
Your point about TCP overhead is well taken--and I'm really not sure
what can be done about that. The problem is that "non-contributing"
peers are still important--for one thing, a peer which isn't your best
peer at time t1 might end up being a best peer (and sharing a lot of
data with you) at a later time t2. For another, I can certainly
imagine that a peer with a very low bandwidth connection might end up
*only* transferring data to and from other peers in the optimistic
unchoke slot--it would never transfer quickly enough to become one of
the favored unchokes of any peer, but it would still be contributing
and still be receiving data.
Perhaps one option to reduce overhead would be to think about how the
protocol would have to change to make HAVE messages bufferable. For
example, if the protocol is still workable without knowing which peers
are interested in you, it might be possible to send one big HAVE when
unchoking a peer. Chances are good, except at the very start and very
end of a file, that every peer is interested in every other peer. If
you optimistically assume that, I don't think it does anything bad.
It would just mean that you occasionally unchoke someone who won't
actually request any data from you. (And the WANT variety of messages
makes this a non-issue for seeds who are never interested. They would
UNWANT any file that was completed, or never WANT it in the first
place if connecting as a peer.)
Still, I'm most interested in what Bram has to say about all of this.
Oh, and a couple of specific comments:
> Another group. Any structural changes to one effects the other. If hash
> mode was used, ordering by the arithmetic order of the hashes makes more
> sense, otherwise no real comment. I like grabing a byte in the BITFIELD
> message to designate the hash-type in use, as opting for SHA256 is a
> foreseeable future choice. Given the size of the HAVE message, you can
> infer the size of the hash, and differing hashes aren't likely to
I think ordering by arithmetic order in the hashes doesn't make
sense--this is a Merkle hash tree, remember? That means that when we
start out, we don't *know* the individual piece hashes. And it's most
likely that hash requests will be somewhat smaller than "give me every
single piece hash". For example, if I'm requesting the first piece, I
only need the hashes for the right subtrees all the way down the tree.
My example of GETHASH was really a pretty lame example, just to show
one really naive (and broken, honestly) way to do it.
This is the thing we really need Bram's input on--exactly how the
Merkle tree and protocol are meant to interact.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
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