Lack Of "Use Strict Private Annouce Mode"

[DreadWingKnight]

Restricting to peers that you've obtained from the tracker isn't practical.

Keep in mind that some swarms have gotten into the 60,000 peer range (that's just for ONE torrent, not the entire tracker, ONE torrent). To transfter that to a client in its entirety takes over 360,000 bytes. For a tracker, the bandwidth involved in sending that to every peer that connects is insane (and not the good kind of insane either).

Sane trackers limit the maximum number of peers to return to a client down in the 200 range (at the highest, most use 100). In the larger swarms, there's no guarantee that you'll actually nail getting incoming connections from those 100-200 peers. In fact, you're FAR more likely to end up with incoming connections from the other 59,799 peers on the torrent than you are to get from the 200 in your announce.

Private trackers should just develop their own clients that authenticate to the tracker and don't accept connections from outside the swarm and stop begging client developers to implement fuctions that don't actually solve the problems they're having.

[c4rypt0]

I have to thank you for all your detailed answers. It is quite clear that in larger swarms this idea is not going to work. Its a pity since in smaller swarms it probably work quite nicely.

I will leave this thread with repeating one thought that hasnt been answered as yet....

"What makes Azureus so special that in this scenario it works so much better than uTorrent?"

[jroc]

Its funny cuz Az has in its connections settings:

"Peer Source: select the default source for peer connections:

from a tracker;

decentralized tracking;

added by a peer;

added by plugin" options that can be checked/unchecked.

(u would check 'by a tracker' and uncheck 'decentralized tracking' in these settings if u dont wanna get burned by DHT)

Whats wrong with that? As long as some of these features have an on/off setting, I dont see whats the problem.....

[system]

I have an idea that you may be interested in implementing. Say the torrent file was to carry an extra field called peerauth. This field would contain the url of an authorization page (hxxp://tracker.com/auth.php perhaps). This page would accept info_hash, peer_id and ip as inputs and return 0 for decline, 1 for accept (minimal bandwidth usage, even with thousands of peers).

Torrents without the peerauth field would function as normal, torrents with the peer_auth field would require checking in with the server when an unknown peer tries to connect.

To make it even more economical, the client could contact the auth page every 10 minutes and post a bencoded dictionary of lists ( dl20:<info hash>20:<peer id>9:127.0.0.1el20:<info hash 2>20:<peer id 2>9:127.0.0.1ee for instance).

In this case, the reply from the server would be a bencoded list of each auth result in order (li0ei1e). The client would accept all connections as normal, dropping those which return 0 at the next auth.

In cases where no response is recieved from the auth page, or a response header other than 200:OK is encountered, the client would function as normal.

The peerauth field would be inside the info part of the torrent dictionary, so any tampering with the field would result in a different info_hash.

I shall be making these suggestions to other client devs as well. I think this would be a lot more useful than the private flag.

Edit: Actually, it wouldn't need the url to be in the info part of the dictionary as any altered torrents would be on external trackers with non authorixed peers anyway.

[c4rypt0]

This is an extremelly interting idea.

Can one of the devs comment?

[vurlix]

That method would put quite a bit of load on the tracker.

[system]

I have come up with some methods that would allow the tracker sysops to decide how much strain they can take.

hxxp://revolt.org.uk/peerauth.htm

Edit: If it still doesn't look like something you'd include, how about a secondary url to do the opposite of announce. It would take all the same inputs as announce, but the list it returns is peers to be dropped.

hxxp://revolt.org.uk/antipeer.htm

This would have a very negligable effect on the tracker, especially when there are no peers to be banned from the swarm but would allow site owners to fully ban users (even if they are leeching/seeding at the time).

Another possibility for site owners using this would be to set up a client that just recieves connections and checks if they are in the peer database. This way, the authorization is handled entirely on the tracker end and messages are only sent when a peer is to be dropped.

[Zoltrix]

I think the main question that has been asked, and not answered, is, why does Azureus have such a feature but utorrent does not? If the developers don't know how to implement such a feature, then they should advise everybody, no one is going to hold it against them.

It's not like it's a feature that doesn't exist, it has already been done. And it is obviously seen as a legitimate feature, otherwise it wouldn't have been developed.

And if it some people feel such a feature has drawbacks, that's why these features are options, so you can turn them off. I can't see how it would cause any harm to the application itself. The only thing it would do, is give utorrent an even bigger user base then it already has.

Cheers,

Zolt

[c4rypt0]

agreed.

Also FYI uTorrent 1.2 still suffers from the same problems. I was hoping the addition of DHT would make a difference but it does not.

[1c3d0g]

Well it looks like it isn't going to be implemented. Remember, feature creep is THE fastest way to reach bloatedness...

[c4rypt0]

this thread taken a roller coaster trip but this now has has nothing to do with feature creep

The current questions is "why does Azureus work so much better than uTorrent in this respect."

Thats not a feature request, its a toubleshooting/bug report.

cheer