Jump to content

DHT question


danshe

Recommended Posts

I have searched and tried to read what's written about dht but I still don't understand. The tracker I use hasn't banned dht but suggests that people not use azareus or utorrent from version 1.2 on because of dht.

I've downloaded the earlier version but I'd like to know if there are other options to getting rid of dht on the newer versions.

Link to comment
Share on other sites

I'm not sure what a private flag is. This is a public site although it requires membership. Here is what it says:

Azureus has introduced DHT (Distributed Hash Table) technology to its client starting with version 2.3.x.x. µTorrent follows this scheme starting with version 1.2.1.x. Using DHT will harm your DIME share ratio and violates our tracker rules.

Link to comment
Share on other sites

1) That's not true, DHT doesn't affect your ratio at ALL.

2) The tracker has no way of knowing if it's on or not

3) It started with 1.2, not 1.2.1

4) It's a private tracker, not a public one

5) edit: blah, semi-rantness is because of lack of info about said tracker

6) http://azureus.aelitis.com/wiki/index.php/SecureTorrents <- Private flag. If they don't know about this and are running a private ratio-based tracker, they shouldn't be running a tracker.

splintax: but PG2 doesn't advertise itself as a firewall. At all. It presents itself as a kernel level IP blocker, using updated IP range lists. :P It does exactly what it says it does: help reduce spying by anti-p2p/media companies. It doesn't claim 100% protection.

Firewalls claim to "secure your computer from hackers" :P

Link to comment
Share on other sites

1) That's not true, DHT doesn't affect your ratio at ALL.

2) The tracker has no way of knowing if it's on or not

3) It started with 1.2, not 1.2.1

4) It's a private tracker, not a public one

5) It's a STUPID private tracker, since they propagate the ratio myth and don't even seem to know about the existence of the private flag.

6) http://azureus.aelitis.com/wiki/index.php/SecureTorrents <- Private flag. If they don't know about this and are running a private ratio-based tracker, they shouldn't be running a tracker.

Firon, that's the tracker where I'm a moderator. So let me answer:

1. I agree with you about the ratio. The more serious reason for blocking DHT is that, when we find that a torrent violates our rules and we ban it, we want it to die down as the peers who are on it get stalled or drop off. We don't want it living forever in the DHT world when it was launched through us. But to get users to care about that? Forget it. But the ratio stuff is not there as a lie to scare users; our admin accepts it, and I'm not going to argue him out of it.

The second argument against DHT for torrents on private trackers is that part of your upload will go to peers you meet through DHT, when we'd like to see you give all of it to other members of the tracker.

2. That's right: the tracker has no way to know whether the user is enabling DHT, backup DHT, or neither, unless the client ID is one that is unaware of DHT. Ergo, a private tracker cannot rely on the user to disable DHT or backup DHT at his/her end but has to do something to make sure it isn't going to kick in.

3. My answer to #3 won't make sense until you've read my response to #5, so I'll get back to #3.

4. Correct. It is more properly classified as a private tracker.

5. (When you say "the private flag" I gather you mean the infodict key, not the response flag.) We're not stupid; we know about the private=1 infodict key very well, thank you; the admin and I each read http://azureus.aelitis.com/wiki/index.php/SecureTorrents back in May; and our tracker has added it to every torrent uploaded since midday May 13, 2005 (unless the uploader already compiled it in, but one way or the other, it's in every torrent posted on our tracker in almost the last seven months). What Danshe is quoting applies only to older torrents that were already on the tracker at the time. Since the tracker can send a private=1 response flag, µTorrent 1.2 is allowed on those torrents. But the admin did not want to disrupt those older torrents by adding the private=1 infodict key to them, so Azureus 2.3.0.0 and later and µTorrent 1.2.1 and later are blocked from those older torrents. All releases of Azureus and µTorrent are allowed on torrents posted on our tracker since then, because they have the private=1 infodict key.

6. Reread my answer to #5.

And now, back to #3: µTorrent 1.2 honors the private=1 response flag, so the tracker can stop it from using DHT on older torrents that were posted before the tracker started adding the private=1 infodict key. Therefore µTorrent 1.2 is allowed on all of our torrents. That's why we draw the line between 1.2 and 1.2.1, not between 1.1.7.2 and 1.2.

Link to comment
Share on other sites

I have nothing against the private flag, I just disagree with turning off DHT on a -global- basis for various reasons. In fact, I do support the private flag for private trackers. It has its own question in the FAQ after all. :P

Yeah, I meant private=1 in the infodict, it's just easier to call it the private flag...

Anyway, what I said was based off what HE was saying, which apparently wasn't what you guys said (or not completely).

Don't take my "stupid" thing to heart. Sorry though. I was wrong in this case because of a lack of info. :P

From what he said, I thought it was a tracker that didn't use/know about private=1 at all and said that "DHT is bad, turn it off or you'll be banned, it screws your ratio, yadda yadda" (there ARE trackers private like that). You should also specifically mention that "Using hacked/modified clients to circumvent the restrictions on DHT is against the tracker rules."

(and you should ban BitComet for the same reason if you haven't already: it doesn't respect the private flag, even .60!)

What you guys do is perfectly fine, but you really should fix the 'DHT harms your ratio' thing. It's totally untrue: the client does not differentiate between data transferred to DHT peers and tracker-obtained peers when reporting transfer amounts. Ask DWKnight about it or just run a simple test, it's quite easy to verify...

And as for µT 1.2 supporting private=1 flag in the announce, I guess it makes sense to leave it unbanned, since if you banned it, it'd use DHT always...

And in all honesty DHT typically uses about .1 KB/s, I don't think it makes any significant difference to have it on or off...

Link to comment
Share on other sites

As I understand it I should be ok using the current version on that tracker as long as I'm only using recent torrents. If not I am totally confused.

I've tried just about every other torrent software out there at some point and utorrent is the best I've found. Based on what little I understand from this thread I'm going to go back to using the most recent version.

Link to comment
Share on other sites

@Danshe: If you have questions specific to our tracker, email us at the mod desk there.

OK ...

Yeah, I meant private=1 in the infodict, it's just easier to call it the private flag...

And that would work if there weren't something else that "the private flag" could mean.

Anyway, what I said was based off what HE was saying, which apparently wasn't what you guys said (or not completely). ... I was wrong in this case because of a lack of info.

I understood that. You didn't have the full story.

You should also specifically mention that "Using hacked/modified clients to circumvent the restrictions on DHT is against the tracker rules."

That would only give them ideas.

(and you should ban BitComet for the same reason if you haven't already: it doesn't respect the private flag, even .60!)

Might as well say it: a ban on BitComet and BitLord is in the works, for a number of reasons, and DHT leakage was the last straw. (Obviously it wasn't the only reason, because the ban will cover BitLord and pre-0.59 versions of BitComet, which are DHT-unaware.)

... but you really should fix the 'DHT harms your ratio' thing. It's totally untrue: the client does not differentiate between data transferred to DHT peers and tracker-obtained peers when reporting transfer amounts.

That's what I figured. You're going to download exactly the size of the torrent content anyway (plus hash-failing pieces and redundant slices, and I've posted elsewhere in this forum that I feel those should not be counted), whether you get it from peers on the tracker or peers in the DHT world, and you'll get upload credit for what you send to peers on the DHT side. Peers on the tracker, though, should get priority, but our principal reason for trying to keep our torrents out of DHT is the matter of bringing banned torrents to a close.

Even in that I am conflicted, but I can't articulate what's in my mind here.

Link to comment
Share on other sites

splintax: but PG2 doesn't advertise itself as a firewall. At all. It presents itself as a kernel level IP blocker, using updated IP range lists. :P It does exactly what it says it does: help reduce spying by anti-p2p/media companies. It doesn't claim 100% protection.

Firewalls claim to "secure your computer from hackers" :P

Going offtopic...

The reason I use a personal firewall is not for security, but for privacy. Sure, malware and virus authors can use a separate TCP/IP stack (or something along those lines), and I would be none the wiser. But even if the article is right and PF authors are bad programmers know nothing about networking (which I doubt), I don't think the majorit of malware/virus authors are much better. But my broblem is with "legit" software. The amount of software which think it's OK to call home without my permission is appalling. And that is why I use a PF. If anyone have a better idea on how to protect my privacy, I'm all ears. I suppose I could use the HOSTS file, but then I wouldn't know which the offending programs are.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...