[bittorrent] Endgame mode

Alan McGovern alan.mcgovern at gmail.com
Sun Aug 5 10:58:25 EDT 2007

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...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070805/4672d503/attachment.html 

More information about the BitTorrent mailing list