Download/Upload control - AntiLeech feuture

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
NodeX
Posts: 5
Joined: 2003-03-19 09:17

Download/Upload control - AntiLeech feuture

Post by NodeX » 2004-02-13 10:56

Hello,
How about implementing that commands to dc++ :

1) $GetUploadersNicks - request from user, list of users which are downloading something from him
2) $GetDownloadersNicks - request from user, list of users which are uploading something to him

Available only for ops.
Two commands, that could eliminate "leech phenomenon".

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2004-02-13 11:31

It's not quite that easy. Protocol changes are usually frowned upon by most people involved in DC++, and for good reason since commands like that would only work in clients supporting it, and possibly also hubs supporting it.

Besides, what would you gain from those commands? The results can be just as easily faked as sharesize, and since DC++ has multi-hub capabilities you would never be the wiser.

NodeX
Posts: 5
Joined: 2003-03-19 09:17

Post by NodeX » 2004-02-13 11:57

OK, i agree with difficulty doing this,
but one note...
Results can't be easily faked.
Ops may compare (validate) results from one user's list with
other.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-02-13 12:28

Multiple hubs.. (To op on hub1: I'm uploading to people on hub2. To op on hub2: I'm uploading to people on hub1.)

NodeX
Posts: 5
Joined: 2003-03-19 09:17

Post by NodeX » 2004-02-13 12:41

maybe commands available for all ?
and one another command...
$GetAllNicks which send list of used nicks (with hub's ip) - this command only for ops...

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-02-13 13:36

How does either making the commands available for all or creating $GetAllNicks rescue your broken idea?

NodeX
Posts: 5
Joined: 2003-03-19 09:17

Post by NodeX » 2004-02-13 14:20

The General idea is to verify that the user isn't cheating with locked slots (or simply he's uploading sth)
cologic wrote:
>> "...To op on hub1: I'm uploading to people on hub2..."
verification step by step:
1. Op sends $GetDownloadersNicks and $GetAllNicks to user#1
2. user#1 replies with downloaders-list and own nicks (<nick><hub_ip>/<nick><hub_ip>...)
3. Op checks users from that downloaders-list with $GetUploadersNicks
4. If uploaders-list doesn't contain user#1's nick (right to that hub) this mean user#1 is cheating...

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-02-13 15:01

This assumes both that (1) it's acceptable to reveal exactly what private hubs one's on, and (2) you have the ability to log on to them.

Address them, and I'll think about it more.

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2004-02-13 17:38

Verifying the claimed downloaders would probably better be done by asking them via UDP, making a connection to the hub and client unnessecary. There would still be the problem that slots can be opened/closed and downloads can be finished any time during and after the verification process, which may result in false positives or enable smart faking clients to avoid detection. A reliable implementation is rather complicated and would only be useful when compliant clients are used by the majority of users, so I personally doubt it's worth the effort.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-02-13 18:07

Private hubs are called "private" for a reason...

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2004-02-13 18:43

You can't fix locked slots/leechers with such a simple but majorly flawed idea. Considering the client was likely modified to allow slot locking in the first place I doubt it would be alot of extra effort to send some random names from the hubs you're in or from hubs that the op isn't in.

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2004-02-13 19:14

I think the idea was to retrieve a list of downloaders from the client and then ask the downloaders if they're actually downloading from that user.
As I mentioned, you can get around the problem that downloaders might be sitting on different hubs, but you will need support from both sides to get useful results.

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2004-02-13 20:47

so you're expecting the client to give you the ip of the person they're downloading off so you can send them a udp request to see if they are downloading off that person? Also you expect it to not only reply to udp requests coming from people not within the hubs they are but also ones that aren't even ops?

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2004-02-14 05:54

I guess it would make more sense the other way: asking uploaders about their downloaders and then sending the udp request to those, but yes, that's what I suggested as an alternative to logging into the downloaders hub, establishing a connection and asking him via TCP...
If I'm not mistaken, clients even accept download connections from people not "within the hubs" on other p2p networks, but I see your privacy concerns - as I said: I don't think this feature to be worth the effort and you just mentioned another downside. On a side note: I don't trust ops I don't know more than I do users I don't know :wink: .

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-02-14 07:33

other p2p networks
The separation of hubs is one difference between DC and a lot of "other p2p networks", one I very much appreciate.
I don't trust ops I don't know more than I do users I don't know
My primary objection to this makes no distinction between ops and non-ops.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2004-02-14 07:53

i hear the sound of rating-servers......
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-02-14 18:31

I hear the sound of scrambling to fix a problem without fully defining what the problem is in the first place.

If someone wants to do this for a niche client, excellent, but the current form of this solution isn't ready for "prime time."

xhost+
Posts: 19
Joined: 2004-01-22 18:01
Location: in.the.middle.of.nowhere

Post by xhost+ » 2004-02-24 15:49

I think that first we should investigate on why do people try to cheat using slotblockers. For me there are 2 answers : they are assholes who didn't really get the meaning of "share" and there is nothing we could do against that except DNA modification or they are honest users but really pissed off to see their downloadspeed drops to naught when someone is downloading from them because they have an asymetric link like most DSL users have. I'm one of them. My link is 1024/128. Pretty asymetric isn't it ?
Over the last months I have been experimenting a way to introduce a smart upload limiter into DC++. Results were pretty encouraging and I think this could be a way to discourage cheating for it will lead to no real gain in terms of dowload speed.
I used a dc++k baseline for speed throtling and performed a simple feedback servo loop on the upload limiter. Try to increase the upload speed, see if it leads to a confirmed trend of download speed decrease and if so stops, else carry on until optimal is reached. With this system, after about 30 minutes of connection, my upload limit was stabilized at 12kB/s which is what I found optimal when playing manually with this limit. Of course sometimes it fails to really optimise and remains at a steady 8kB/s. Interresting idea, however, and I'm still working on it.
I know that the author of DC++ is against bandwidth control. I understand his reason but we should consider this way more like an optimisation of the bandwith usage than a real limiter.
Anyway, my client works fine for me and people can still download from me at 12 kB/s which is pretty low all right but 75% of what I could offer and far more than if I used a slotblocker.

xhost+

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-02-28 14:36

xhost+ wrote:I used a dc++k baseline for speed throtling and performed a simple feedback servo loop on the upload limiter. Try to increase the upload speed, see if it leads to a confirmed trend of download speed decrease and if so stops, else carry on until optimal is reached.
Ah, someone dissatisfied with my code. =)

I don't download in DC++, but I do use the internet for other purposes on my computer - it seems like your code would fall flat on its face in my situation.
xhost+ wrote:I know that the author of DC++ is against bandwidth control. I understand his reason but we should consider this way more like an optimisation of the bandwith usage than a real limiter.
Er... so what is arne's reason for not including bandwidth limiting?

Locked