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

Elliott Mitchell ehem at m5p.com
Sun Jun 11 17:55:31 EDT 2006


>From: Harold Feit <dwknight at depthstrike.com>
> Elliott Mitchell wrote:
> >> From: Harold Feit <dwknight at depthstrike.com>
> >> As on-topic as this suggestion may be, it has not been met with the best
> >> of responses in the development community.
> >>
> >> By having friend systems not duplicate pieces within the friend cluster
> >> until after 1.0 distribution within the cluster, the cluster is causing
> >> an overall negative skew of the distribution of pieces within the swarm
> >> as a whole, causing degradation in swarm-wide performance.
> > 
> > State the reasoning.
> > 
> > I don't see how this would happen. If you were calculating your numbers
> > incorrectly, I can easily see how you would come to this conclusion, but
> > this doesn't match reality. In particular if you count each member of the
> > group as a true distinct peer, then yes you reach this conclusion. Since
> > there is only one true downloader here though, you must count the entire
> > aggregate _group_ as one peer.

> No you can not count the entire aggregate group as one peer.
> Each member of the aggregate group has different peer connections than
> the other. Because of this, each peer that is connected to a different
> member of the aggregate group sees a different completion.
> With the members of the aggregate group actually following the rules
> about reporting the pieces they have, peers that connect to members of
> the group can only have a partial view of the pieces that the member
> group has.
> Even if they have a full view of the pieces that the group has, they can
> only ever have access to the pieces of the members they connect to.

Yeah, so? Where is the problem?

Slaves act as normal peers except they have a list of pieces that they
don't have and yet do not want (the pieces that the master or other
slaves have obtained). Otherwise their decision making is identical to
any other peer. How can this harm the swarm?

Peers *never* have a complete view of the swarm, because in most cases
they never connect to every other peer. Yet even with this incomplete
view, BT seems to work quite well. The only thing I see would be if a
gigantic (say 200+) group joined a very small swarm (say 5 peers),
because they would flood the swam.

The only harm I see is if a client assumes behavior that is not required
by the protocol. Then presuming that a slave will perfectly conform to
your model. Such as assuming that a peer will be interested in
downloading every piece you have (Azeureus and not telling you about all
the pieces it has, on the assumption that it doesn't need to).

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 the central system advertises possession of pieces it got from
> > slaves, then you will see all pieces that the helpers download advertised
> > from two semi-distinct peers. All pieces the central system downloads
> > from the swam will only be advertised once. This though should not have a
> > major impact on the balance of the swarm (self-interest on the part of
> > normal peers should easily even this out), though it is a decent reason
> > to forbid the central system from advertising possession of pieces it
> > gets from slaves.

> A request to one peer cannot be fulfilled by another peer that has not
> received the same request. A request to one peer cannot be fulfilled by
> another peer when the second peer isn't connected to the requesting peer.

Yes, your point?

Perhaps change that sentence, instead of "from two semi-distinct peers,
with only one visible download" (the download from slave to master not
being visible to the swarm). Odd behavior if your client is observing
very carefully and makes assumptions about precisely how a peer operates,
but still protocol conformant.

> >> Additionally, having the friend cluster separate itself from the main
> >> swarm once it has reached 1.0 distribution within the cluster causes
> >> even MORE of a negative skew of piece distribution of pieces within the
> >> swarm.
> >>
> >> It could potentially make one downloading user faster, at the cost of
> >> everyone else in the swarm.
> > 
> > This is the old "don't disconnect immediately" request. Your slaves
> > should only disconnect when the master shuts down.
> > 
> > And how do you prevent the implementation of this anyway? This is trivial
> > compared any of the other attacks on the swarm that come to mind. Come up
> > with defenses, don't ignore something that can be done.
> > 
> Attacks such as?

Hordes of zombies can easily cause disruption in a swam, but even without
those...

One method is to advertise posession of all pieces, but ensure no one
ever downloads more than one block from you. By corrupting one block of
every piece, the clients will have to discard 224KB of data merely for
32KB of bandwidth on your part. Oh, make that discard 240KB of data for
merely 16KB of bandwidth, the smaller block makes this attack a lot more
efficient. Magnifying your effecting corrupting bandwidth by a factor of
15 is pretty powerful. The problem here being that you cannot immediately
verify every block you download.

Simpler, retrieve random single bytes of random pieces that the peer has.
Pretty well forces random seeks of your disk subsystem (unless you can
store the entire torrent in memory). Kills all caches and just plain
murders performance unless your peer charges extra for small requests and
every time a new piece is loaded into memory.

There is no way to counteract the first without changing the protocol
(thankfully the RIAA, MPAA, et al haven't implemented this attack yet).
The second can be countered by careful design of the clients, but to my
knowledge all current clients will be murdered by this.


-- 
(\___(\___(\______          --=> 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