Lack Of "Use Strict Private Annouce Mode"

[Mareko]

Would be great to see such a feature implemented. Have been in awe of µtorrent ever since it came out but reluctant to make it my primary client due to this issue, since i mainly use private trackers.

Keep up the great work guys, eventually µtorrent will definitely become the client of choice by most torrent users

[jroc]

Im with Firon. I've switched from Az and I dont see what u guys are talking about. Every site I tried (tried 4 torrent search engines, tried 6 private sites I belong to, tried 4 public sites) using µT reports 100% correct, sometimes lower. but never over. Its gotta be something else.

[c4rypt0]

There is no doubt that it only happens on some private trackers but I believe this is only due to human intervention and not a bug in the tracker. i.e. its a human nature thing rather than a technical thing

[frenchdm]

This is a major problem for private torrent sites. I know of several key uploader members on some sites that have stopped or limitted their activity because of these spiked torrents.

We all know Azureus isn't perfect, wouldn't it be great if utorrent was?

[MrCoke]

because of recent outbreaks of my private torrents posted on public dumps, i'm considering switching back to azureus... which is scary, but gotta save my bandwidth from going away, hopefully you can find a way to implement this feature of IGNORING DHT completly, as an optional feature of course but saves alot of us bandwidth. good luck, and i hope you can find the development easy enough.

[psymin]

I am in support of this proposed feature. I'm sure some of your users might even be willing to donate to help provide some motivation. I know that I would pitch in.

[vurlix]

Motivation is not necessary. Ludde doesn't want to implement it because it's a half assed solution that works as a side effect

[c4rypt0]

hmm ok

doesnt bother you that Azureus works and utorrent doesn't?

[Firon]

or you guys could stop being so anal about SHARING. If it's such a serious problem with torrents being shared, tell your tracker administrator to move to a PID system and setup an auto-ban if the PID is used twice for leeching from 2 different locations. and make sure the torrents are all created with the private flag. If there's clients that don't respect the private flag, ban them from the tracker.

[c4rypt0]

Firon dont be a troll and accept that not everyone uses torrent in the same way as you.

Sharing does not mean sharing to anyone and everyone at the expense of members of private trackers. Private trackers are setup to be a closed community of people wanting to share with each other. If we wanted to use a public tracker we would... all thats being asked if for utorrent to work as well as Azureus giving people the choice.

And i will say this again...

this is nothing to do with private flags or keys or anything like that.

Currently utorrent accepts connections from ANYONE that can get your IP and has the correct hash details. No matter what is done with the tracker it makes bugger all difference if your using utorrent it blindy accepts connections.

[Firon]

I would like to mention that ALL CLIENTS DO THIS, EVEN AZUREUS! The only thing that happens with Azureus when a torrent is set with the private flag is that it won't do Peer Exchange or use DHT. It does not stop it from receiving any incoming connections, period. It is much, much harder to get your IP if the tracker doesn't allow outside users to grab a peerlist from it!

[c4rypt0]

All i can say is that in practice this is simply not true.

Consistantly Az shows the correct number of seeds and leeches whist at the same time utorrent does not.

Also i can confirm the tracker "doesn't allow outside users to grab a peerlist from it".

[Firon]

uTorrent displays the number of peers differently.

Peers: 52 of 125 connected (109 in swarm)

for example.

The tracker doesn't differentiate between seeders and peers when giving uTorrent the peerlist, so uTorrent displays it all initially as peers. As it connects to them, it finds out whether said peer is a leecher or a seeder. Many are unconnectable, so they stay in the cache for 30 minutes as peers, even the unconnectable seeders, so naturally it will show a much higher peer count, such as in my example. Stale peers also stay in the cache for 30 minutes: peers that were connected to you but disconnected because they stopped the torrent/closed the client/etc, so it also raises the number of peers displayed.

[c4rypt0]

yup i undertsand that.

however we are not talking a few peers here and there we are talking 10 times more than have ever been in the swarm and higher in some cases.

Also the tracker has never seen any of these IPs so they are invading the swarm using another method.

[MrCoke]

If it's such a serious problem with torrents being shared, tell your tracker administrator to move to a PID system and setup an auto-ban if the PID is used twice for leeching from 2 different locations. and make sure the torrents are all created with the private flag. If there's clients that don't respect the private flag, ban them from the tracker.

the tracker is on a PID system and it has an autoban feature. the problem is the people hack the existing torrents so that the PID isnt in there, and the tracker still fails to connect, thats where OTHER peoples DHT connect to uTorrent becuase it accepts these connections, instead of ONLY the trackers ip's. so we loose a very considerable amount of bandwidth. sorry you dont think this is important but it is to us.

[Firon]

Well, if the torrent is set to the private flag and people are using DHT clients that don't respect the private flag, that's not uTorrent's problem is it? Ban those clients that are known to not respect it.

In all honesty, as vurlix said, there isn't any good solution to this besides reworking the protocol.

[c4rypt0]

come on lets be realistic here.

banning all clients that dont respect the private flag is virtually them all so thats not a viable solution.

reworking the torrent protocol is not a viable short or even medium term solution either.

so why not consider even doing some experiments with the solution we proposed.?

Also "that's not uTorrent's problem is it" ... you are 100% correct. I just though it made sense that the most promosing client be the one to talk to.... plus the fact i thought the devs would want to know that Az outperforms utorrent in this respect (for what reason i dont know)

Edit: After re-reading a few of the last posts I sense quite a negative attitude. If i caused this i appologise. I should point out that i believe utorrent to be the most impressive client currently in development. I also see it being THE client of choice in the future. Kudos devlopers regardless of any decisions made about this proposed feature

[Firon]

Only 3 clients have DHT: Azureus, Bitcomet, and Mainline.

Azureus respects the private flag. I have no idea if Mainline does, but I would assume it does. I think some versions of Bitcomet do, but there are some that don't (not too sure on this), so it's not that hard to ban clients that don't respect it (probably all BitComet vesions to be safe). There isn't really any solution that can be implemented that works -well- on the client side right now, which is the problem with what you're asking for.

[c4rypt0]

There isn't really any solution that can be implemented that works -well- on the client side right now, which is the problem with what you're asking for.

surely something is better than nothing?

and since this has not been tried how can we know for sure it wont work better than expected?

[bkman]

Only 3 clients have DHT: Azureus, Bitcomet, and Mainline.

Azureus respects the private flag. I have no idea if Mainline does, but I would assume it does. I think some versions of Bitcomet do, but there are some that don't (not too sure on this), so it's not that hard to ban clients that don't respect it (probably all BitComet vesions to be safe). There isn't really any solution that can be implemented that works -well- on the client side right now, which is the problem with what you're asking for.

Azureus and Bitcomet respect the private flag, and mainline doesn't need to since it doesn't use peer-exchange and backup tracking via DHT. An old version of Bitcomet had peer-exchange before the advent of the private flag, but that is probably banned everywhere. Still there are probably hacks about of that version which report a different version number, but that is the same problem as rogue Azureus builds.

[c4rypt0]

can someone explain why only allowing Ips from the tracker to connect to you would be such a big deal?

surely the only downside is that it will slow the growth of swarm between the clients getting tracker updates

and you could easily improve this by just making the client update more when the seed to leech ratio is low

[bkman]

Perhaps a better idea is to only report regarding peers gleaned from the tracker to the tracker. Ie, only report uploads and downloads of peers from the tracker, and ignore the others.

Are there any issues with this?

Edit: Nevermind, this is just as flawed.

[c4rypt0]

Hopefully the devs are still following this thread.

Here is a solution that may fit better.

Between client updates from the tracker operate completely as normal.

Then when the client gets an updated IP list drop all IPs that are in the swarm but not in the tracker IP list.

Repeat at each update.

This way swarm invaders only can leach bandwidth for one annonce period.

This feature could/should only be available if the private flag is set.

Unless i am wrong this should have zero impact on legitimate private tracker users and zero effect on public trackers.

[Firon]

You can't do that because the tracker only gives you a small amount of RANDOM peers. The tracker doesn't give you the entire peerlist when the swarm is larger than the number of peers it gives in one scrape. You would drop a TON of legit peers in the process.

Bkman, I thought the 4.x tree of Mainline had DHT in it? And I know that they can change their reported client version, but it will at least help to some extent since there probably are known versions that don't have the client id changed by default.

[bkman]

Bkman, I thought the 4.x tree of Mainline had DHT in it? And I know that they can change their reported client version, but it will at least help to some extent since there probably are known versions that don't have the client id changed by default.

The Mainline does feature a DHT, but not as a fallback. It is only used for totally decentralized torrents.

Btw, I found your suggestion to ban all BitComet clients earlier (to be on the safe side) hilarious. I hope you weren't serious.