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

Elliott Mitchell ehem at m5p.com
Tue Jun 13 22:25:50 EDT 2006


>From: Harold Feit <dwknight at depthstrike.com>
> 
> 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:
> >>>> 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?
> > 
> > Yes.
> > 
> > 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.

Last I checked they weren't that fast here either.

Are you saying piece transfer requires a very low latency? Last I
checked, if merely getting the pieces to the master was the goal, latency
is irrelevant only raw bandwidth was important. At which point DVDs in
the mail or hand delivered satisfy the requirement for this portion of
the band. This isn't to say this is the prefered method, merely one that
satisfies the requirements for this band.

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

Because that doesn't serve the purpose of accelerating transfers to their
master (the ultimate goal of utilizing slaves).

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

Okay, just have to convince you of the above then.

> >> 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
> harmful"

And you haven't shown to me how it is harmful either.


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