From 3aa3ec7d14abd3311ca5e132c9056364ed13bd60 Mon Sep 17 00:00:00 2001 From: Charles Kerr Date: Wed, 10 Mar 2010 15:34:27 +0000 Subject: [PATCH] (trunk libT) #2993 "'Downloaded' much greater than 'Have' or 'Verified'" -- tweak the new throttle code based on slow download feedback from gn0s1s in irc, from Rascal @ http://trac.transmissionbt.com/ticket/2993#comment:29, and from AGSystem @ http://forum.transmissionbt.com/viewtopic.php?p=45631&f=1#p45631 --- libtransmission/peer-mgr.c | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/libtransmission/peer-mgr.c b/libtransmission/peer-mgr.c index 19a8422d0..95814655e 100644 --- a/libtransmission/peer-mgr.c +++ b/libtransmission/peer-mgr.c @@ -2349,10 +2349,37 @@ rechokeDownloads( Torrent * t ) /* decide how many peers to be interested in */ { - const int blocks = tr_historyGet( t->tor->blocksSentToClient, now, msec ); - const int cancels = tr_historyGet( t->tor->cancelsSentToPeer, now, msec ); + int blocks = 0; + int cancels = 0; - if( !cancels && !t->interestedCount ) + /* Count up how many blocks & cancels each peer has. + * + * There are two situations where we send out cancels -- + * + * 1. We've got unresponsive peers, which is handled by deciding + * -which- peers to be interested in. + * + * 2. We've hit our bandwidth cap, which is handled by deciding + * -how many- peers to be interested in. + * + * We're working on 2. here, so we need to ignore unresponsive + * peers in our calculations lest they confuse Transmission into + * think it's hit its bandwidth cap. + */ + for( i=0; ipeers, i ); + const int b = tr_historyGet( peer->blocksSentToClient, now, msec ); + const int c = tr_historyGet( peer->cancelsSentToPeer, now, msec ); + + if( b == 0 ) /* ignore unresponsive peers, as described above */ + continue; + + blocks += b; + cancels += c; + } + + if( !t->interestedCount ) { /* this is the torrent's first time to call this function... * start off optimistically by allowing interest in many peers */