when µTorrent uses DHT if there's an announce key in the torrent

[nightshifted]

If this has already been discussed, please point me to the right thread. I tried a forum search and none of the hits seemed to discuss what I want to know, but my search skills are abysmal.

I had the impression that µTorrent, like the official client, would use DHT only for a trackerless torrent. (Maybe that's not true of the official client either and I was wrong about both.) On further reflection, it seems to me that that can't be right, because then there would be no need for it to honor the private=1 key: privacy would be implicit from the existence of the announce key.

Let's say a .torrent file names a tracker in the announce key, but it lacks the private=1 key (that is, internally in the .torrent file; I know that µTorrent ignores a private=1 flag in the announce response). Now, a user connects to it with µTorrent -- since version 1.2.2 is current, let's say the person is using 1.2.2 -- without disabling DHT for him/herself (either globally or for that torrent). Will µTorrent use DHT for that peer? Will it avoid DHT if the tracker responds but fall back on DHT if the tracker becomes unreachable? Will it switch to DHT if the user removes the announce URL through the Properties card or changes it to something invalid (or to that of a tracker where that torrent isn't running)?

Any clarification would be greatly appreciated. Thank you.

[Firon]

DHT is used at all times unless disabled (globally, per-torrent, or by private flag). It's not used as a backup, it's used regardless of the state of the tracker. (BitComet works similarly)

If the .torrent has no private flag and DHT is on (it is by default), then DHT is used.

Removing/changing/adding the tracker has no impact (as it should) on the use of DHT.

To sum up: if private=1 is present, DHT will never be used. If it is not present, it will always be used unless explicitly disabled globally or on a per-torrent basis.

[nightshifted]

Thank you greatly, Firon.

Does the official client -- at least DHT-aware versions from 4.1.0 on up -- act the same way?

One dissimilarity in BitComet is that it claims to honor the private=1 announce response flag, which µTorrent does not. Where can I read an explanation the problems with it, which led to the decision that µTorrent should ignore it? (Sorry again, but my search skills are horrid; I almost never find anything, or I get too many hits and can't wade through them.)

[Firon]

The mainline client never uses DHT as a backup. It only uses it for trackerless torrents.

BitComet invented the private flag in the announce protocol. It was decided against supporting it because of how crappy it was.

This thread has the explanations for why support was removed.

http://forum.utorrent.com/viewtopic.php?id=2950

private=1 in the .torrent is the only way to go...

[nightshifted]

Thank you again, Firon. So releases of µTorrent before 1.2 didn't support DHT, 1.2 supported DHT and the private=1 announce response flag, and releases 1.2.1 and later support DHT but not the announce response flag ... just trying to get all the data together.

Now the question is why µTorrent 1.2.2 can create a .torrent file with the private key but no announce key. Wouldn't such a torrent be useless?

[Firon]

Yeah. 1.1.7 supported creating torrents with private=1, 1.2 added DHT and supported both kinds of private flags, 1.2.1 and later don't support announce private.

That kind of torrent is typically useless yeah, but you can always add a tracker manually (since it has nothing to do with private=1) afterwards. Not sure what kind of situation you'd need it, though... Maybe as a test torrent or something.

You could always add a peer manually. Go to the Peers tab, right click and use Add Peer.

[nightshifted]

Adding a peer manually? Never noticed that ... guess it requires IP and port, which you'd have to know somehow.