[bittorrent] Endgame mode
joris.guisson at gmail.com
Sun Aug 5 14:38:40 EDT 2007
No, when multiple peers are assigned to the same piece, I send requests to
all assigned peers.
So even if one is being slow, the other assigned peers can pick up the
On 8/5/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> An 'EndGame' mode is still useful with your kind of algorithm though.
> I changed from a one-piece-per-peer algorithm to a
> multiple-peers-per-piece algorithm as it offers major benefits (not going to
> go into that here though). However, depending on your request pipelining
> algorithm, you can still benefit majorly from EndGame.For example if you
> have a static queue of 5 pieces, and the last peer has 5 requests and is
> uploading at 0.5-1kB a second, it's going to take quite a long time to
> finish the torrent. EndGame would finish it within seconds.
> On 8/5/07, Joris Guisson <joris.guisson at gmail.com> wrote:
> > I agree, figured that one out a long time ago and once I came to that
> > conclusion, I also realized that a special endgame mode is useless.
> > My client just distributes the peers over the pieces that are currently
> > downloading, it tries to avoid multiple peers on the same piece, by starting
> > the download of new pieces. (when all pieces have a peer)
> > At the end of the download, there are no more pieces left to start, so
> > it automatically assigns free peers to the remaining ones, resulting in
> > multiple peers for the same piece. So you end up in some sort of 'endgame'
> > mode without even having to switch to a different algorithm.
> > Joris,
> > On 8/5/07, Alan McGovern < alan.mcgovern at gmail.com> wrote:
> > >
> > > I was thinking, the best condition for entering endgame mode would be
> > > when there are zero blocks free to be requested. There's no point in having
> > > a fixed limit like '20 pieces remaining'. I want to reword that section to
> > > indicate that 'zero pieces remaining' is the preferred indicator of when to
> > > enter endgame.
> > The reason is that suppose you have 50 open connections downloading the
> > > last 50 pieces, 40 of those peers could be really slow with 10 being fast,
> > > so there's no point in those 10 peers waiting around until 20 slow peers
> > > finish so the threshold of '20 pieces remaining' is reached. This is counter
> > > productive.
> > >
> > > _______________________________________________
> > > BitTorrent mailing list
> > > BitTorrent at lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> > >
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent