x190 wrote:It seems Transmission makes almost no attempt to make connections to peers it gets from DHT. e.g. Learned 69 peers from DHT, but I'm only connected to the grand total of 1.
There are multiple factors at play here. First, Transmission deliberately prefers peers obtained from trackers to peers obtained from the DHT -- an arbitrary choice, but one that makes sense considering that the user can control the set of trackers, but not the set of DHT nodes. Second, the DHT is much slower than either trackers or PEX, so by the time Transmission has obtained any peers from the DHT, it usually already has plenty of tracker and PEX peers (note that if a peer can be obtained both from the tracker and the DHT, it will be marked as whatever place it was first learnt about).
Finally, the DHT has no mechanism to discard unreachable hosts. According to some estimates, up to 2/3 of DHT peers are unreachable.
I'd suggest the following test: choose a torrent, and in its inspector pane, manually remove all of the trackers. Then stop transmission, remove this particular torrent's resume file, and restart transmission. You'll see how fast the torrent is able to get up to speed from the DHT and PEX only.
Can you [...] tell me if Transmission can use it's loaded blocklists against IPv6 addresses.
A quick glance at the code in r10539 seems to indicate it's IPv4-only. I could be wrong, I've only looked in the most obvious place.
I'm not going to implement IPv6 support in the blacklist, since (1) I happen to think that manually maintained blocklists are a silly idea, and (2) in the rare cases when I do want to blacklist a range, I prefer to do it at the lowest layer possible -- in a host specific firewall, or, better yet, in my router's firewall.
(Before anyone accuses me of being a "rotten apple" again -- the above does not mean I'm opposed to the feature, just that *I* am not going to implement it. I'll be happy to review patches if somebody else writes them.