Download/Upload control - AntiLeech feuture
Moderator: Moderators
Download/Upload control - AntiLeech feuture
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".
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".
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.
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.
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 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...
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.
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.
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.
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?
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 .
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 .
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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+
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+
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Ah, someone dissatisfied with my code. =)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.
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.
Er... so what is arne's reason for not including bandwidth limiting?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.