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

Harold Feit dwknight at depthstrike.com
Sun Jun 11 15:44:42 EDT 2006



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




More information about the BitTorrent mailing list