Costly but very effective solution to slot-faking

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Scope
Posts: 25
Joined: 2004-05-02 15:09

Costly but very effective solution to slot-faking

Post by Scope » 2004-05-02 16:23

How about a feature that makes the client send info about which users are downloading files from them. This way the hub knows how many free slots every user has, based on other users info. Sending upload info with a nick that has the same IP as you should of course not be allowed. You should be able to query the available slots for a user from the hub. Maybe add a new tab in the download/upload area with free slots so users can easily tell when a client is faking "no slots available". The feature must of course be mandatory for all users in the hub for this to work. And it will use more communication with the hub and the hub needs to keep track of all users free slots. But it would definately be worth it!
-------------------------------------------------------------------------------------------------
Ex.

The hub receives open slots from Bob and Robert and stores them

Bob tries to download a file from Robert

Bob sends info to the hub that he wants to download from Robert

Robert sends info to the hub that Bob wants to download from him

If the hub receives a message from both Robert and Bob the hub performs these actions :
Decreases Robs open slots.
Sends info to Robert that the filetransfer is ok.

If the hub doesnt receive a message from both Robert and Bob the hub performs these actions:
Report the type of error to both clients. (Ex. Timeout)
Eventually kick the person for not reporting the upload/download

If Robert receives info from the hub that the transfer is ok, he starts to send the file to Bob.

If the hub reports an error both clients aborts the transfer and reports the error.

If Bob quits the hub will increase Roberts open slots and Roberts client should abort Bobs transfer.

When the connection is closed between the clients, both users should report this to the hub, and the hub will perform proper actions.

-------------------------------------------------------------------------------------------------

This way the hub can also keep track of number of downloads you have running and limit them.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 07:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2004-05-02 16:36

But as you said is it the problem with hubtraffic, and that's a reason to why it probably never will get implemented. As it can be problems with the hubs using bandwith as it is today.

Scope
Posts: 25
Joined: 2004-05-02 15:09

Post by Scope » 2004-05-02 16:56

joakim_tosteberg wrote:But as you said is it the problem with hubtraffic, and that's a reason to why it probably never will get implemented. As it can be problems with the hubs using bandwith as it is today.


Remember this type of communication is only needed when starting and stopping a connection to a client that has free slots.
Requesting number of free slots for a user from the hub is only needed at first attempt to download from the client, at this point you will see if he's faking or not.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 07:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2004-05-02 17:04

Scope wrote:Remember this type of communication is only needed when starting and stopping a connection to a client that has free slots.
But in a big hub with over 3000 users that can become quite much.

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

Post by GargoyleMT » 2004-05-02 17:36

This is 95% the same as the feature requested in this post:
http://dcplusplus.sourceforge.net/forum ... php?t=8142

It's a familar topic, I think there have been earlier discussions of it as well.

Scope
Posts: 25
Joined: 2004-05-02 15:09

Post by Scope » 2004-05-02 17:42

joakim_tosteberg wrote:
Scope wrote:Remember this type of communication is only needed when starting and stopping a connection to a client that has free slots.
But in a big hub with over 3000 users that can become quite much.


I dont really care much for those 3000 if half of them are faking. The easiest way of faking is "no slots available", in DC++ you only need to change ONE line. I rather have a hub with 1500 users if they are all legit, instead of 3000 with half of them faking.

Scope
Posts: 25
Joined: 2004-05-02 15:09

Post by Scope » 2004-05-02 17:52

GargoyleMT wrote:This is 95% the same as the feature requested in this post:
http://dcplusplus.sourceforge.net/forum ... php?t=8142

It's a familar topic, I think there have been earlier discussions of it as well.



Yeah its pretty much the same idea and the multi-hub issue is hard to get around

Wisp
Posts: 218
Joined: 2003-04-01 15:58

Post by Wisp » 2004-05-02 18:54

I think this could be implemented but only as a "check" for ops to see if a user is faking, that way it wouldn't cost so much bandwidth..

foxyshadis
Posts: 15
Joined: 2004-04-13 00:53

Post by foxyshadis » 2004-05-15 16:29

Oh, how soon we forget DC++k (And its spinoff, CDM.) Its primary purpose, and nearly all of its spiffy recent features, are related to finding and stopping faking. Please, if you want to be rid of fakers, find and use the right tools, instead of coming up with wildly unusable ones.

Who is online

Users browsing this forum: Google [Bot] and 0 guests