Sign in to follow this  
Followers 0
Skasowitz

DHT banned in hubs

35 posts in this topic

We run a large campus LAN hub, and having DHT enabled by default will cause the general users to use their limited bandwidth.

enabled by default - what's the difference in bandwidth usage when DHT is enabled by default and when it's not enabled by default and user enables it on his own?

their - as you said, it's their bandwidth, so why the hell should the hub decide whether user wants DHT or not?

We'll probably employ something similar to this script to block DHT-connected users in the hubsoft.

If you block users who are connected to another hubs too, then everything is ok. And PPK is right in that topic, more clients with DHT-based network exists and also some of them are fakeclient which can fake tag. So you won't be able to block them :P It's same as it was with upload limiter in the client. StrongDC++ was blocked in some stupid hubs because of upload limiter (although it was set to e.g. 10 MB/s) So hubs were full of fakeclients with limit set to 1 kB/s (and nothing in tag) and admins were happy, because there were no clients with L: in its tag ;)

It's really funny arguments against DHT, I read everywhere. It's still "DHT this" and "DHT that", so we will block it. But another hubs where user is connected to are no problem although the same arguments can be applied on them. That's the reason why DHT detection will be removed in future and only hub count will be increased by one when DHT is enabled.

Oh, and by the way, when user enables DHT after connection to your hubs has already been made, then your detection fails, because DHT won't be reported to anywhere. So it is better for you to have it enabled it by default :P

Share this post


Link to post
Share on other sites

We understand it's their bandwidth and their choice to use DHT, and it's a great idea for internet hubs, but we're honestly doing it for their own good - people expect the campus hub not to use their limited, expensive internet bandwidth, and it hasn't done for the past five years. Making DHT difficult to detect will make DC an unsatisfactory solution for lan-only filesharing like in our situation.

Simply put, the users don't understand why the hub is suddenly draining their internet bandwidth, despite repeated warning in the MOTD. We're doing this for their protection.

Share this post


Link to post
Share on other sites

I'm not sure you know what you are talking about. Or why do you talk about DHT when named problems paid for every hub and is not DHT specific? DHT = virtual hub and that's why same rules should be applied on DHT like on another hubs.

Share this post


Link to post
Share on other sites

I'm not sure you know what you are talking about. Or why do you talk about DHT when named problems paid for every hub and is not DHT specific? DHT = virtual hub and that's why same rules should be applied on DHT like on another hubs.

The fundamentals in actually connecting with DHT is different to connecting to another hub from a user stand point.

And when you enable DHT, hub still can detect and boot user instantly.

Share this post


Link to post
Share on other sites

The fundamentals in actually connecting with DHT is different to connecting to another hub from a user stand point.

But I was talking about stated wannabe problems:

- they claim that DHT is bad, because it will share data outside of their private hub. It's true, but when user connects to another hubs, it will be shared outside of their private hub too. And they will be much more easily accessible in hubs, because you just use search or download filelist to get them. You need to know TTH in DHT. So hubs are more security issue than DHT.

- they claim that DHT is bad, because it will use their limited bandwidth. Again, it's true, but when you don't use DHT and only connect to hubs, you will get less sources. And less sources = more stress on uploader's bandwidth, because you will download more bytes from them. So when many users disable DHT, users' bandwidth will be used much more.

Share this post


Link to post
Share on other sites

This may come off as blunt, but do you intend to protect them from actually learning something new as well, if they can't disable an option in settings I truly feel sorry for them.

This may come off as blunt, but do you intend to endanger them and prevent them from actually learning something new as well, if they can't enable an option setting I truly feel sorry for them.

I hope this point is basically made by now. Turn off DHT and let the users decide how they will be seen or used by others. This way the client is not making the decisions. If you want to inform more people about DHT, great... just don't force it upon them first.

Share this post


Link to post
Share on other sites

I hope this point is basically made by now. Turn off DHT and let the users decide how they will be seen or used by others. This way the client is not making the decisions. If you want to inform more people about DHT, great... just don't force it upon them first.

That's like saying they should go through every setting and set it themselves. It is our responsibility to provide the best default settings for most users. We feel enabling DHT will provide the majority of public hub users with faster downloads, and allow them to collect sources all over the place. This is the true advantage to DHT, and if people don't like that they can disable it. I understand the issue with private hubs and its users, but this is easily monitored and resolved.

I know it works because I've seen it. After 6 days, 65% of users in a private hub have already upgraded to 1.3.5 and followed the "You are not allowed in this hub because DHT is enabled, please disable it by following these steps" message. The user count hasn't dropped either.

Share this post


Link to post
Share on other sites

I don't see what the big deal is. In the hub I run, I detect the use of DHT and kick them with a link to a tutorial on how to turn it off. Simple. There hasn't been a drop in the user count and everybody running ApexDC++ is running the latest version. The only thing thats wrong with this situation is the hub owners. If they can't be bothered to learn LUA (or whatever) and write the DHT blocking script (or hell, copy it from someone on the internet), and instead choose to ban the client because it's easier, they really shouldn't be hub owners. With that being said, not being able to release a pre-configured version that disables DHT is a little over the line. I did some testing on my machine. I installed the client, looked at the DcPlusPlus.xml settings file and UseDHT was set to 0. I ran the client and looked at the settings file again and UseDHT was set to 1. What gives guys? I understand the need to include the feature but why force feed it to people?

Share this post


Link to post
Share on other sites

I don't see what the big deal is. In the hub I run, I detect the use of DHT and kick them with a link to a tutorial on how to turn it off. Simple. There hasn't been a drop in the user count and everybody running ApexDC++ is running the latest version. The only thing thats wrong with this situation is the hub owners. If they can't be bothered to learn LUA (or whatever) and write the DHT blocking script (or hell, copy it from someone on the internet), and instead choose to ban the client because it's easier, they really shouldn't be hub owners. With that being said, not being able to release a pre-configured version that disables DHT is a little over the line. I did some testing on my machine. I installed the client, looked at the DcPlusPlus.xml settings file and UseDHT was set to 0. I ran the client and looked at the settings file again and UseDHT was set to 1. What gives guys? I understand the need to include the feature but why force feed it to people?

First of all, thanks for coming into the conversation with a decent attitude towards this as a hub owner. Would it be possible for you to upload a sample of your lua script for others to use?

Regarding forcing DHT, it's enabled by default on first run. We have a first run wizard on the to do list that will ask the user whether to enable/disable it and what it does. Yeah, some users may skip over it but at least the information is there. :)

Share this post


Link to post
Share on other sites

I did some testing on my machine. I installed the client, looked at the DcPlusPlus.xml settings file and UseDHT was set to 0. I ran the client and looked at the settings file again and UseDHT was set to 1. What gives guys? I understand the need to include the feature but why force feed it to people?

Same here. I am providing our LAN users with a preconfigured ApexDC++ so that they minimize the trouble when using it. But DHT enables itself regardless of the setting in XML and that is irritating, partly defeating the sole purpose of such preconfigured client. Any way to get around this behaviour?

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0