new "anti Leecher option" - not very well implemen

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

Moderator: Moderators

Locked
Sudder
Posts: 2
Joined: 2003-01-11 12:04

new "anti Leecher option" - not very well implemen

Post by Sudder » 2003-01-11 12:10

hello

I think the new "anti Leecher option" since v0.20 is not very well implemented:

I often got cut of (at least 2 times a day) I don't know if my Hub is to blame, my ISP, DC++ or my installation but that's not the point. The point is eaven I haven't done anything wrong I get punished:

1. I loose the time I'm not connected to my hub
2. when I get back in time to get my extra slot, the dl speed drops, since now there's normaly one user more at my sourche..
3. sometimes I don't get back in time (not that easy to reconnect to a 600+ user hub .. again no Idea who to blame) and then I'm totaly fucked

so why not hold the connection between the clients active for those 10min "tolerated downtime" and cut it then ?

I doubt that anyone will reconnect every 10 min to renew his 10 min and cut the line again in fact I think the timelimit could easily increased to 20, eaven 30 min and still have the same antileech effect (an Idea would be to send a pm from the source to the person who is disconnected "your line will be cut in XXmin if you don't reconnect .. blabla " .. but then there should be an Option on the reciving end to ignore those messages .. not too funny if your screen is flooded with those messages if your hub has trouble with his line ...)

as much I don't like leechers (and apreciate taking mesures against them) one thing shouldn't be overseen:

now it's much harder for a hub admin to build a big hub:
with 1,81: eaven when the hub goes down for 1 hour a day most dl's go on and the users are more willing to stay at this particular hub and "forgive" the downtime but now if a hub has a Problem for 2 weeks (again with 1 hour downtime / day) I think many users will change the hub .. which brings much Frustration along (eg. If you got 90% of a rare movie and can't find again the only source ...)

so in my Opinion the new Option is way too agressive and does more harm (pissing people of) than good (getting rid of them leechers)

to summ up my suggestions: increace the allowed "downtime" and don't cut of the connection between users instantly but at the end of the "tolerated downtime".

.. or is it just me having trouble with that function ?

Sudder

Iceman[grrrr]
Forum Moderator
Posts: 58
Joined: 2003-01-03 11:30
Location: Québec, Canada
Contact:

Post by Iceman[grrrr] » 2003-01-12 08:07

I moved it to Features forum since this is more flame against the features and not the developpers...

It could be taken for a future release...

thanks for your comments
DC++ QoS Person

joazito
Posts: 17
Joined: 2003-01-06 04:57
Location: Portugal

Post by joazito » 2003-01-13 01:07

Hmm... I kind of agree with the post... but... you can't send a message to a user that isn't connected to the hub, so there goes your alternative.
Still I agree with you: I think that if the slot could hold for those 10 minutes (or 20...) it would be better. Loosing a slot so instantaneously just seems over the edge.

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-01-13 07:03

on my line you'd have the movie in 20mins.. so I think that's way too much time. (I feel a slow vs. fast users debate in the air :P )

the dc++ should reconnect in 2 mins, so give m 5, so he has more than enough time to renew his onlineness with a $Hello.

now, for this to be fully fair, dc++ should then start watching <Hub-Security>-kick messages. for kicked ppl shouldn't hold slots.

/sed
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

Sudder
Posts: 2
Joined: 2003-01-11 12:04

Post by Sudder » 2003-01-14 11:20

@ Iceman[grrrr]: thanks for moving .. I wasn't quite shure where to post ..

@ joazito: the "message" was just a "red light" kind of an idea (so everybody would notice the new feature) and since the conection between the clients is still active I don't think that it would be too hard to implement (but I could be wrong ...)

@ Sedulus:

>on my line you'd have the movie in 20mins

lucky you, but most users have much slower lines (how many movies did you actually get within 20min)

>.. so I think that's way too much time. (I feel a slow vs. fast users debate in the air :P )

I don't think so since the 20 min/movie scenario shure isn't the standart and if you where such a "powerleecher" with 20min/movie it's not that big a deal to stay connected and cut the uploads manualy .. (normaly you won't get cought since you can watch the complaints in the chatwindow and can disapear in time ..)

>the dc++ should reconnect in 2 mins, so give m 5

again I just can envy you for your line .. my dc needs somtimes much longer (eaven more than 10 min)
.. to repeat myself: I don't konw who to blame (isp, hub, dc ..) .. but since my 2 favorit hubs have to handel many clients with many filez (min share 120/130gig with ca. 600 users = ca. 100T each ..) I tend to "blame" them ...

(the hubs could provide much better data than single users (how many times was the average user disconnected per day) ..perhaps sth to implement in the future ..)

the Problem is to find a good compromise between getting rid of the leechers and not pissing of the "normal" users

an other idea to improve the "leecher detection" is for the clients to "log" the time s.o. connects, since I figure the "normal" leecher will connect, search, start the dl and cut the connection again (all within 10min)

.. so the clients should cut the connection imediatly if the user was connected for up to 30min, hold it for 20min if he was there for up to 1h, hold it for 40 min if he was there for up to 6h ... (all in case the person who is dl-ing is disconnected from the hub)

one could improve that feature eaven more (but it's getting more complicated then) if the clients would eg log for how long each user was connected within the last 3 days .. everyone who was connected for more than 48h is probably no leecher and won't be cut of for 24 .. sth like that... (that way it wouldn't matter if s.o. reconects several times .. his list wouldn't be set to 0 again ...)

to clarify: I just made those numbers up to make my Point (I don't want to fight about how the figures should be exactly)

> now, for this to be fully fair, dc++ should then start watching <Hub-Security>-kick messages. for kicked ppl shouldn't hold slo

good idea (I forgot that aspect) .. since the kick-messages are allready "broadcasted" they just need to be processed by the clients (that goes also for the onlinetime logging thing) ..

Sudder

LordAdmiral
Posts: 13
Joined: 2003-01-03 23:25

Post by LordAdmiral » 2003-01-22 23:30

Several things actually:

Somebody mentioned PM'ing offline users. Well, if we're still connected to them through downloading/uploading, wouldn't it be possible to PM them through that IP?

Watching kick/ban messages is an interesting idea. I was wondering how the community would react to an automatic kicking of people who are publicly kicked/banned. Of course, several scripts actually kick/ban people who don't meet the share/slot criteria with the regular kick message, so that might not be a good idea. Nonetheless, I'd hate to be sharing my files to a faker or to some guy who's sharing something sick. And since most hubs have a decent leeching policy (though I've noticed some of them fail to enforce it), it isn't as if proper sharers would be unfairly cheated of a slot.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-01-24 06:08

LordAdmiral wrote:Somebody mentioned PM'ing offline users. Well, if we're still connected to them through downloading/uploading, wouldn't it be possible to PM them through that IP?

Possible, yes, but it is not supported in the DC protocol, thus leading to another extension (in the $Supports command) and will not work with a majority of clients.

LordAdmiral wrote:Watching kick/ban messages is an interesting idea. I was wondering how the community would react to an automatic kicking of people who are publicly kicked/banned.

The auto-kick feature of DC++ kicks users that leave the hub for whatever reason, including being kicked/banned. If the other client does not come back to the hub within x minutes (because it is banned) they lose their reserved slot.

LordAdmiral wrote:Of course, several scripts actually kick/ban people who don't meet the share/slot criteria with the regular kick message, so that might not be a good idea.

I smell a user-defined setting coming up, allowing people to use "soft" kicking (as it is now) and "hard" kicking which would cut off clients in a harder way if they are kicked/banned (not granting them a reserved slot, for example).

Sarf
---
If you are sitting, just sit. If you are walking, just walk. Above all, don't wobble.

mo2
Posts: 6
Joined: 2003-01-16 22:16

Post by mo2 » 2003-01-24 13:09

I generally like Sudder idea of basing the disconnect time on the amount of time the user is in the hub, but I don't think that is realistic.

First problem is, when I join a hub, how long have the people been in there before I joined? who knows...

Second problem, keeping track of 500, 1000, 2000+ users is a waste of my processor time...

I think a better alternative is to keep track of the time someone has been downloading off me. Basing the disconnect time on this value would be a better alternative.

On Kick:
Disconnect = Now

On Leave:
Disconnect = DLTime / 3
if Disconnect < 3m then Disconnect = 3m
if DLTime < 2m then Disconnect = Now

With this logic, if a person was kicked, or downloading for less then 2 min, they would be disconnected immidiately.
If they have been downloading between 2min and 9min they will be disconnected in 3min
if greater than 9min it will disconnect after DLTime / 3
ie:
1min = Disconnect Immidiately
5min = Disconnect in 3min
15min = Disconnect in 5min
21min = Disconnect in 7min
30min = Disconnect in 10min

That's the general idea anyway, the numbers could change

Neg
Posts: 20
Joined: 2003-01-19 07:05

Post by Neg » 2003-01-24 18:36

I think the ide of blocking slots is a general bad ide. Because it will lock many slots on many clients after they actulay shulde be free. If a user of some reasin get idsconnected or banned it is moast likly his own fault in some way. I have never been disconnected by chans there is always a reson for it. The serving client kicked me, i parted the hub, i was kicked out of the hub, i might have done something to screw up my internet connection or sutch.

What im trying to say is there is a little chans that some externel (none human related) problem will make your download abort. So i think the slot locking mecanism is a waste of developing time that will result in a waste of cloes slots that realy shulde be free. Once you get a slot is up to you to hang on to it.

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-01-25 10:28

Neg wrote:If a user of some reasin get idsconnected or banned it is moast likly his own fault in some way.

ehe.. random disconnects happen very often, at least in some big hubs I visit
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

Locked