ShAQ Posted April 30, 2007 Report Share Posted April 30, 2007 Hi.When I change the Tracker (Right click on torrent, Properties, Tracker...) e.g. from 'http' to 'https' all connections get disconnected. This is an unwanted behavier bcs. my connection is firewall (can't change this) and speed drops down fast and needs time to come back. Could you guys add a switch to enable/disable this feature? BTW: It keept the connections until the beta. :|Best regards,ShAQ Link to comment Share on other sites More sharing options...
ICleolion Posted April 30, 2007 Report Share Posted April 30, 2007 Not a bug, its done deliberately. So this is a Feature Request. And although i'm not sure of the reason behind this change, i doubt they are gonna give u the option to turn it on or off, as they probably would have done that already. Link to comment Share on other sites More sharing options...
ShAQ Posted April 30, 2007 Author Report Share Posted April 30, 2007 A option to disabled this feature would be nice. Link to comment Share on other sites More sharing options...
Ultima Posted May 1, 2007 Report Share Posted May 1, 2007 Not happening. ludde suggested this behavior to the devs to prevent ghost leeching on private trackers. Link to comment Share on other sites More sharing options...
ShAQ Posted May 1, 2007 Author Report Share Posted May 1, 2007 It doesn't matter if you disconnect the peers their or not. Already connected peers will come back after a while. So why disconnecting them all when they will come back? This 'feature' is nonsense. Link to comment Share on other sites More sharing options...
Ultima Posted May 1, 2007 Report Share Posted May 1, 2007 Yeah, that's what you think. This is a decently-effective counter-measure against ghost leeching on private trackers. If you're only changing trackers, then you'll reconnect soon after anyway, and it'll be the same as simply restarting µTorrent. I can't really imagine all that many legitimate reasons for why anyone would want to be editing the trackers list constantly. If you need to change from HTTP to HTTPS, then change it before you start the torrent, or immediately after you add it -- simple enough.Sorry, as far as I can tell, this isn't getting undone.Edit: Hm... Firon made a good point on the IRC channel that I hadn't thought about before. The fact that incoming connections are still gonna be made after the peers get disconnected and the peer list gets cleared does diminish from this change's efficacy... Perhaps you're right... Link to comment Share on other sites More sharing options...
Smoovious Posted May 3, 2007 Report Share Posted May 3, 2007 as is, it would do more harm to the swarm than good...The only way to prevent ghost-leeching, is to only allow connections from peers found in the announce list. On large swarms, you usually only get a random sample of the total swarm, depending on how many peers are configured by the tracker.What this means is, two µTorrent clients couldn't connect to each other until they both have announced, and got the ip of each other in the announce results.If we go that far to prevent ghost-leeching, it would end up doing more harm than good to the swarm, and IMHO, isn't worth it.Just clearing the current connections, isn't going to prevent ghost-leeching whatsoever.-- Smoovious Link to comment Share on other sites More sharing options...
Firon Posted May 3, 2007 Report Share Posted May 3, 2007 I'm gonna agree with ShAQ on this one. Just won't work. Link to comment Share on other sites More sharing options...
chaovel Posted July 15, 2007 Report Share Posted July 15, 2007 Hm... Firon made a good point on the IRC channel that I hadn't thought about before. The fact that incoming connections are still gonna be made after the peers get disconnected and the peer list gets cleared does diminish from this change's efficacy... Perhaps you're right...And this bug/feature is still present in 1.7.1Was the final decision to keep it or was it just forgotten and not removed?BTW peer list is cleared even when you do such a little change as adding/removing 1 empty line. Link to comment Share on other sites More sharing options...
Ultima Posted July 16, 2007 Report Share Posted July 16, 2007 The final decision was to keep it. Changing *anything* in the tracker list for private torrents will cause the clearing. Link to comment Share on other sites More sharing options...
Switeck Posted July 16, 2007 Report Share Posted July 16, 2007 How about just for torrents with the private flag that have DHT and Peer Exchange disabled? Link to comment Share on other sites More sharing options...
Ultima Posted July 16, 2007 Report Share Posted July 16, 2007 Hm...? DHT being enabled or disabled doesn't really make a difference for private torrents. As for PEX... any reason there should be a distinction whether it's enabled or disabled? (Just curious) Link to comment Share on other sites More sharing options...
Switeck Posted July 16, 2007 Report Share Posted July 16, 2007 Presumably only private torrents CARE about tracking ratios. Link to comment Share on other sites More sharing options...
Ultima Posted July 17, 2007 Report Share Posted July 17, 2007 >_>lol I'm still confused xD Link to comment Share on other sites More sharing options...
Honeyfrog Posted August 13, 2007 Report Share Posted August 13, 2007 IMO, a torrent shouldn't _really_ be considered "private" unless it contains a SINGLE tracker which includes the text-phrase "passkey".(And passkey files still aren't private: I can, in just a few minutes with MakeTorrent 2.0 and Edxor, create two new .torrent files -- with additional trackers and the passkey announce, and another with just the additional trackers. I launch uTorrent using the "passkey+others" file, and upload the "others only" file to an index site to pick up external peers, then act as the bridge between the isolated peer-groups. -- This trick works *independently* of client.)I truly do loathe this new "feature" -- it does nothing whatsoever to enhance privacy while merely annoying those who need to bypass it with extra steps. Link to comment Share on other sites More sharing options...
Ultima Posted August 14, 2007 Report Share Posted August 14, 2007 So private trackers aren't allowed to use backup trackers? A "private" torrent has the private key set, that's all. Passkeys aren't the only ways to track users on private trackers. Link to comment Share on other sites More sharing options...
system Posted August 14, 2007 Report Share Posted August 14, 2007 You would only act as a bridge in that you would upload pieces you have downloaded from the private swarm to the non-private one. Something that can be done anyway by simply tracking the torrent elsewhere.None of the people you connect to would appear as ghosts to anyone else on the private swarm and none of the peers from the private swarm would connect to the peers in the non-private one.If you remove the private flag in the second torrent, it has a different info_hash which will prevent things like PEX allowing connections to private peers (they will just drop any connection attempts).Simply uploading the torrent with a tracker change to another tracker would have the same effect.There are ways to bridge the 2 swarms completely, allowing peers from the non-private to cross over and connect to the private peers, just not that way (unless everyone uses a client that allows PEX on a private torrent, which makes it very client dependant).Relying on the list only containing a single tracker prevents any possibilities for load balancing or other things that may be done with private torrents.Relying on the existance of the word "passkey" in the announce doesn't work on trackers that use IP auth. If I had a tracker limited by IP to 10 friends, the torrent files most definately would be private.Another consideration is that both the announce URL and the passkey (which is part of the URL) are outside of the info part of the torrent. With your suggestions above, any user could add a second tracker to the announce list and make that torrent public, allowing DHT and PEX to work which would increase the number of ghost peers on a supposedly private torrent.The private flag cannot be altered without changing the info_hash as it is inside the info part, and therefore remains outside the users control. Subjecting all peers on a private tracker to outside connections is not a decision that should be made by a single user.Regarding the dropping of peers though, simply dropping all peers from memory on a tracker change isn't really protection against ghosting except when the user is firewalled or behind NAT.Other peers will simply reconnect and start downloading/uploading again.If all peers were remembered and blocked on incoming connections it would prevent ghosting, but it would have a memory and performance impact on the client (now storing 2 lists for the torrent and cross referencing between them) as well as a massive impact on the speed. On changes that reconnected to the same tracker (changing http to https etc), all peer info gathered during the life of the torrent would have to be regathered from the tracker before being removed from the second (blocking) list, and a lot of unconnectable peers would be permanently blocked with trackers that only return connectable peers. Some places, connectable peers make up something like 10-15% of the swarm, meaning 85-90% of the peers would be lost. Link to comment Share on other sites More sharing options...
Ultima Posted August 14, 2007 Report Share Posted August 14, 2007 Yep, I already addressed the point about incoming connections not being prevented Remembering the previous peers wouldn't be necessary; all µTorrent would have to do is check if an incoming connection is targeted at a private, trackerless torrent. If so, then the connection attempt could be blocked/dropped as if the torrent never existed. That still wouldn't prevent people from simply copying the peers list and readding it after removing trackers, though, but there really isn't any foolproof way to prevent ghost leeching other than to simply disable the torrent entirely if it's private and trackerless.That said, because of the current limitations with how it's implemented, I myself am not a big fan of this feature (though I do understand its intentions). *shrug* Link to comment Share on other sites More sharing options...
system Posted August 14, 2007 Report Share Posted August 14, 2007 It was actually a reply to honeyfrog, but I'll reply anyway Dropping all incoming connections would be one way to go, but even with this feature in, there's nothing to prevent someone doing the old firewall trick. If all clients ignored all unknown incoming connections for all private torrents (edited or not) it may work, but there'd still be a chance a ghoster managed to connect to somebody who announced between the time the ghoster started the torrent and the time the tracker deleted them as a peer. It'd also make things run like treacle for a lot of peers.I understand its intentions, but I just don't see this feature doing much of anything except upsetting users. Link to comment Share on other sites More sharing options...
jhn195 Posted January 6, 2008 Report Share Posted January 6, 2008 Since when utorrent started bending its back for private trackers? I thought the previous position (admirably so) was screwed them. Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 6, 2008 Report Share Posted January 6, 2008 Off-topic, and old thread. Not a discourse on the "found bug" or "feature request", tsk tsk. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.