[bittorrent] Friend-machines-assisted approach to boosting one's BT download
dwknight at depthstrike.com
Tue Jun 13 09:34:36 EDT 2006
Elliott Mitchell wrote:
>>>>> Though, equally, have you confirmed that a meta-peer will damage a swarm?
>>>> There is only one situation where it would not:
>>>> 1> all members of the meta-peer have a larger uplink between each other
>>>> than they do to the rest of the swarm and/or have a separate uplink
>>>> between each other and the rest of the swarm
>>> DVDs in the mail fit this.
>> For real time exchange of pieces? Really?
> The master-slave links have two very distinct bands. Maintaining the list
> of pieces that other peers have obtained needs quick response, but little
> bandwidth. Even a modem would be sufficient for this because peers can
> pipeline their decisions of pieces to download. The master will want to
> upload hashes to the slaves, but that isn't a major bandwidth strain.
> The other band is the piece transfer. This requires large amounts of
> bandwidth, but isn't bothered by large latency. Once the piece is known
> to be good, the time it takes to transfer the piece to the master is
> unimportant. DVDs in the mail can easily handle this task.
You must have a different postal system than I do, because DVDs in the
mail aren't able to get from .au to .uk in the span of seconds with the
postal systems I know.
>>> Uploading to their master first will also be similar to this situation.
>>> I'd tend towards slaves incrementally uploading to their master, rather
>>> than waiting until the end. By giving preference to their master, that
>>> upload will squelch the swarm uplink, guarenteeing that it will
>>> effectively have greater bandwidth than the swarm uplink.
>>> I don't see how this will prevent damage to the swarm, but this condition
>>> is met anyway.
> Do you disagree with that statement?
Why aren't they uploading to each other and to the swarm as well?
>>>> 2> all members exchange pieces with each other SIMULTANEOUS to sharing
>>>> with the swarm (effectively giving each member peer a public and private
>>>> share pipe, letting member peers share full speed to outside peers and
>>>> high-full speed separately to inside peers).
>>> In order to fulfill their job, the slaves must do this anyway. If they
>>> don't upload to their local peers, they won't download from their local
>>> peers, and therefore they'd be unable to upload to their master (at which
>>> point, why would anyone bother implementing this?). This condition is
> Since you haven't disputed my assertion that your two conditions are
> fulfiled, are you conceeding that /my/ concept is at least okay?
>>> This sounds like you're worried about a pool of leeches trying to get
>>> together to multiply the effect of optimistic unchokes. That is something
>>> to worry about, but that is an active attack, not what I am suggesting,
>>> and hopefully not what CoolByte was suggesting elsewhere.
>> Unfortunately, CoolByte was all for suggesting abusive and damaging
>> means to increase his own download speed.
> Well, that may of been the agenda behind what CoolByte was saying, but
> that wasn't said on this list. I said it earlier, I've got my own ideas
> that may or may not be what CoolByte really ment. What CoolByte said _on_
> _this_list_ sounded close enough for me to think it worth commenting.
Well, you missed the conversations in #bittorrent on freenode that lead
to him being banned for his assbackwards destructive proposals.
>> Ultimately, this proposal isn't going to get much support from me, if
>> any, simply because it's a downloader-centric proposal in a
>> swarm-centric protocol.
> Again, what /I/ am thinking of is merely a client feature for specific
> circumstances. No changes to the protocol, just an extra feature that may
> be useful for some circumstances.
I'm still not seeing how your proposal is actually classifiable as "not
More information about the BitTorrent