This should cause uTP sockets to respect read bandwidth limits. I'm not so
sure about the values we return for the read buffer size -- perhaps we
should allow some slack for network latency?
There's no need to test for DHT/uTP being enabled in tr-udp. The DHT
will silently discard any packets directed at the wrong session (see the
beginning of dhtCallback). As to uTP, we need to grok uTP packets
to close any remaining connections after we disabled uTP, so it's better
to participate in uTP, just reject any incoming connections.
Jordan Lee [Fri, 18 Feb 2011 00:33:29 +0000 (00:33 +0000)]
(trunk T) add preliminary enable/disable toggles in daemon, gtk, and qt clients. 'preliminary' because this may be widened to a tri-state of inabled, disabled, and incoming only
Libutp will sometimes call our callbacks after we called UTP_Close,
notably to notify us of the UTP_STATE_DESTROYING state change, but
also, for some reason, to ask us about our read buffer. The simplest
way to avoid issues with that is to switch to a second set of callbacks.
This adds code to participate in the UTP protocol, but without doing anything
useful yet -- we just shut down immediately any incoming connexion request.
Jordan Lee [Thu, 17 Feb 2011 05:14:53 +0000 (05:14 +0000)]
(trunk libT) #3767 "rarest first policy" -- fixed.
This commit, started by a patch from athy, implements a rarest first policy when deciding which pieces to request from peers. It keeps a count of how many peers have each piece, and updates the count when getting bitfields, have, have all, and have none messages, as well as decrementing the counts when peers disconnect.
This running total is generated only for downloading torrents. Seeds don't have this overhead.
Jordan Lee [Thu, 17 Feb 2011 02:26:24 +0000 (02:26 +0000)]
(trunk) #4032 "Better error detection / reporting in http announces" -- added to trunk.
This patch adds two new flags to the callback function -- did_connect and did_timeout -- that are calculated inside of web.c using information from libcurl. This allows the announcer to detect timeouts more accurately and also to distinguish between unresponsive peers (which get the preexisting "Tracker did not respond" error message) and unconnectable peers (which get a new error message, "Could not connect to tracker").
We now try to contact the bootstrap nodes up to six times.
A better solution might be to reattempt bootstrap every half hour
or so. This might be beneficial to people whose connectivity
changes while Transmission is running.
remove selected transfers when removing completed transfers, removing through RPC, etc. (whenever removing transfers that aren't the selected transfers)
inspector: update the displayed global seeding settings only when necessary; update only the displayed global seeding settings instead of all the options
Jordan Lee [Wed, 9 Feb 2011 02:35:16 +0000 (02:35 +0000)]
(trunk libT) fix compiler warning: "peer-io.h:282: warning: inlining failed in call to ‘evbuffer_add_uint8’: optimizing for size and code size would grow"
update-version-h.sh tries to use {{{svnversion}}} when possible. But when it's not, it looks through the "$Id:" lines in the source file comments and uses the largest version number it finds. The new files tr-dht.[ch] didn't have the line of its $Id: comment formatted in the way update-version-h.sh expected. tr-dht.[ch]'s $Id: line has been homogenized to be like everyone else's...
Jordan Lee [Sun, 6 Feb 2011 18:56:44 +0000 (18:56 +0000)]
(trunk libT) #3975 "tr_bencToFile() contains unnecessary calls to stat() and unlink()" -- fixed for win32.
remove() doesn't have the same behavior on Windows. On that platform, we should use MoveFileEx( oldpath, newpath, MOVEFILE_REPLACE_EXISTING )." Thanks to rb07 for testing & confirming the fix.
Jordan Lee [Sun, 6 Feb 2011 18:50:35 +0000 (18:50 +0000)]
(trunk gtk) #3866 "Popup menu for file list manipulation" -- removing from the 2.20 milestone
Looking over the 2.20 tickets, this one keeps sticking out. A popup menu may be useful if the "delete files" ticket is accepted in 2.30, but for this release (2.20) it doesn't really add anything new. One lesson from the 2.1x cycle was that features are a harder to remove than to add. So I'm going to hold off on adding this feature until it has a clear raison d'être.
Jordan Lee [Sun, 6 Feb 2011 17:30:46 +0000 (17:30 +0000)]
(trunk) #3675 "Not all .part files are removed" -- handle trashing files via RPC.
When libtransmission gets a "remove torrent" request from RPC, it tries to delegate the work. This is because the GTK+ and Mac clients don't want torrents disappearing in a different thread and causing possible thread issues. So the GTK+ and Mac clients get notification about this via libtransmission's RPC callback and remove the torrents themselves. Unfortunately, that notification doesn't include information about whether or not to delete local data.
This commit adds that information to the RPC callback so that the Mac and GTK+ clients will know whether or not to trash the local files when a third-party RPC client requests that at torrent and its files be deleted.
Jordan Lee [Sat, 5 Feb 2011 18:46:10 +0000 (18:46 +0000)]
(trunk libT) #3931 "'Announce is Queued' but doesn't get announced" -- remove the 'unresponsive tracker' penalty from torrents whose announce time has been reached.
The 'bad tracker' penalty was introduced in 2009 after a top tier trackers went down. Announces to it would hang, tying up an announce slot in libcurl for minutes at a time. If a user had enough torrents from that tracker, it could bottleneck all announce slots. The workaround was to deprioritize failing trackers so that they wouldn't obstruct other trackers.
Its implementation could be better, however. There are two parts:
1. Deciding how frequently to retry unresponsive trackers
2. Once an unresponsive tracker announce was ready to go, it would be bumped down the queue if other announces were ready too.
Part 2 probably contributes to #3931. If there are enough torrents loaded, there will always be good tracker announces that get pushed ahead of a bad one in the queue. Modifying 2's heuristics would be one option, but it seems simpler to remove it altogether now that getRetryInterval() grades more hashly for consecutive failures. Altering the retry interval also gives better visual feedback to users than Part 2 did.