[bittorrent] Friend-machines-assisted approach to boosting one's BT download

Elliott Mitchell ehem at m5p.com
Tue Jun 13 00:46:12 EDT 2006

>From: Harold Feit <dwknight at depthstrike.com>
> Elliott Mitchell wrote:
> >> From: Harold Feit <dwknight at depthstrike.com>
> >> Elliott Mitchell wrote:
> >>>> From: Harold Feit <dwknight at depthstrike.com>
> >>>> Elliott Mitchell wrote:
> >>>>>> From: Harold Feit <dwknight at depthstrike.com>
> >>>>>> Elliott Mitchell wrote:
> >>> Yes, how does this damage the peer or swarm?
> >>>
> >>> The non-cluster peer can still download those pieces from another
> >>> non-cluster peer. Unless a single meta-peer is at least 40 times a swarm
> >>> it joins, I don't see it causing any sort of problems. Crucially there is
> >>> little point in employing a meta-peer larger than around half the size of
> >>> a swarm because at that point, the meta-peer's bandwidth will likely
> >>> outperform the swarm's, at which point additional members won't increase
> >>> download speed.
> > 
> >> With a meta-peer that has not downloaded the piece, that interaction is
> >> forced rather than voluntary, causing a negative skew in piece distribution.
> > 
> > How?

> If the meta-peer is actively not trying to download pieces already in
> the cluster, it won't have those pieces until late in the torrent
> progression, forcing the torrent off.

I'm still unsure what you mean.

> >> When the meta-peer leaves, they take the ENTIRE meta-peer's COMBINED
> >> upload rate AND distribution away from the swarm.
> >> In smaller swarms, this can be fatal to the piece distribution for the
> >> given torrent.
> > 
> > Yes, what about people on OC12s leaving swarms though? These two are
> > pretty comparable, a node with large amounts of bandwidth leaving a swarm
> > will be noticable, but not fatal.

> We aren't talking about OC12s here though, and if someone's on an OC12,
> they've usually:
> 1> worked alone
> 2> uploaded 3-10 times what they've downloaded because they feel they
> can afford to.

True, how do you know the lead of a meta-peer won't allow the meta-peer
to upload more than it downloads? They're similar in class, both command
huge amounts of bandwidth and any swarm will feel the loss of them
leaving. You have to deal with large bandwidth peers leaving, for this
purpose there is little difference.

> >>>>> Again, slaves and the master conform to the BitTorrent protocol. If they
> >>>>> can harm the swam by conforming to the protocol, then the protocol needs
> >>>>> to be fixed. I don't see how they would harm the swarm though.
> >>>> If they are selectively not downloading pieces that others in their
> >>>> cluster don't have, they are preventing other clients from outside of
> >>>> their cluster that connect to them from being able to get the pieces
> >>>> from them.
> >>>>
> >>>> If all the slaves were operating 100% by the protocol the following
> >>>> things would happen:
> >>>> 1> They would continue to download pieces already obtained within their
> >>>> cluster, either from within their cluster or from outside (I don't care
> >>>> which personally).
> >>>> 2> They would try to not preference internally to the exclusion of all
> >>>> external peers.
> >>> This is not required to conform to the BitTorrent protocol. This is
> >>> merely conventional client design.
> >>>
> >>> Peers will merely download those pieces from other peers that are not
> >>> part of the cluster. The effect you're concerned with isn't serious until
> >>> the meta-peer is massively larger than the swarm (until then the peers
> >>> are very likely to have connections to non-cluster peers), and it isn't
> >>> useful to employ a meta-peer that large because it cannot utilize its
> >>> full download nor upload.
> > 
> >> And what if there are only two peers in the entire swarm that have a
> >> given piece and one of them is in the meta-peer and it isn't sharing
> >> with the rest of the swarm?
> > 
> > Well, it will be handled by standard swarm dynamics. Peers will see it is
> > rare, and tend to download it and spread it across the swarm.
> > 
> > Having said that, why wouldn't a meta-peer not share a piece it has? It
> > wants to download just as much as anyone else, so of course it is going
> > to upload the piece! Just it will only be uploading the piece from
> > specific localities within the swarm, mainly only the one or two group
> > members who have the piece will upload it. The swarm then has to take
> > care of spreading the piece around. How is this distinct from the case of
> > any other peer?

> Normal peers don't attempt to preference one peer over another because
> they are told to by a user or authoritative command peer. They
> preference because the peer is playing nice.

Yes. This still doesn't mean doing so harms the swarm.

> >>>> But part of the original proposal had exactly what I mentioned, having
> >>>> one peer in the cluster redirect the traffic for that piece to another
> >>>> peer in the cluster.
> >>> I didn't read that in what CoolByte was suggesting, nor have I ever
> >>> deliberately suggested such a thing. The only traffic redirection
> >>> CoolByte appears to of suggested was that the slaves upload pieces to the
> >>> master for no compensation (meta-BT, really). Not something a normal peer
> >>> would do, but still conformant to the BitTorrent protocol.
> > 
> >> CoolByte did recommend the redirection of piece requests in his original
> >> proposal. It is beyond the capabilities of the protocol.
> > 
> > Well, then I disagree with CoolByte and support your statement on this
> > specific issue.
> > 
> >> It is the option of the peers to upload to the central system without
> >> expecting anything in return, however the only members of a swarm that
> >> should be doing this are seeds.
> > 
> > Sure, normally. I still don't see why providing free uploads to a master
> > destroys a swarm though.

> If the master isn't giving back to the swarm directly.

Well, it won't be able to download directly from the swarm then. Kind of
silly given that the master likely has some upload that isn't being used
for anything else. I still don't see how this harms the swarm. Sure, the
master gets extra bonus bandwidth from the slaves, but those slaves have
to upload to the swarm in order to get those pieces to give to their

> > Someone actively trying to destroy the swarm won't care that they can't
> > download.

> It's when they can't upload because all of the downloading peers have
> banned them for being jerk-offs that they start caring.
> The next counterpoint is "What if they change IPs?"
> To which the counter-counterpoint is "Then that IP will get banned for
> repeated hashfails too."

You're still thinking of someone trying to take advantage and get extra
download. They won't care.

Try this one on for destroying a torrent:

Choose one or two blocks target (possibly early to destroy meta-data, or
crucial points in the file).

Have a bunch of zombies jump into the swarm, that claim to have that
piece, and that piece only.

When connecting to a peer, if that peer does not have that piece,
advertise having the piece and unchoke. When the peer asks for a block of
the piece, send them garbage and immediately choke them.

If a peer has the piece (either on connection, or gains it elsewhere),
indicate interested, send HAVEs for a bunch of pieces they don't have and
Upload genuine pieces freely and attempt to download as much as possible
(ideally in a performance degrading way). The upload allows you to drain
a lot of that peer's bandwidth.

Peers will see that piece as fairly common and not grab it early (all
the zombies claim to have it, therefore it must be common). The peers
that really do have the piece get massively leeched in an attempt to
stop them from spreading it around.

I do admit that I could be wrong. This might take a large amount of
bandwidth to pull off, but unless you've got a pretty sizable number of
seeds the zombies should be able to extinguish a few pieces. This is less
effective in a swarm with a lot of seeds (you might make it take a long
time to get the piece, but eventually you will find the genuine piece).

> >>> Though, equally, have you confirmed that a meta-peer will damage a swarm?
> >> There is only one situation where it would not:
> >> Conditions:
> >> 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.

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

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

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.

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

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

More information about the BitTorrent mailing list