[taz-me]

Leecher treatment was (more or less) divided into 2 methods :

1. banning
2. identify and "reduce score"

From the "school" I'm coming from leecher is given the benefit of the doubt, i.e. since potentially he might become a source I prefer the identify and "reduce score" approach.

Here is my new idea :

Until now identified leechers data was preseved between mod activation so that known leechers can be treated as such "on sight".

My idea :

embedded SUQWT with "no SUQWT" for leechers and each activation of mod starts with clean (or none) collected data (can be done otherwise with altered constructor - however for a demo it proves my point) :

@BaseClient.cpp :

// By Taz - no SUQWT for ModThief or NickThief
			bool was_thief = pAntiLeechData->GetBadForThisSession(AT_NICKTHIEF);
// <------- no SUQWT for ModThief or NickThief

		pAntiLeechData->Check4NickThief();  //collector

// By Taz - no SUQWT for ModThief or NickThief
			if (Credits() && !was_thief && pAntiLeechData->GetBadForThisSession(AT_NICKTHIEF)) // 1'st identify
				Credits()->ClearUploadQueueWaitTime();
// <------- no SUQWT for ModThief or NickThief

same goes for identify mod thieves.

Newly detected thief leechers do not earn their wait in queue from previous sessions thus are inferior and upload queue sure seems cleaner ...

BTW: ideally working reduce score system should have caused leechers to be longest waiting, "least" getting anyway ...

[CiccioBastardo]

Any mean to make "leechers" download less is valid.
BTW, I think it is much better an immediate score divider than using a system as the one you presented. In my personal case, for example, that method would have very little impact, as my sessions usually last for weeks. Losing an unpload slot every 15/21 or more days is not that bad for a leecher, IMHO. While if I make you wait 10 days instead of 1 for each chunks you request me, it has a major impact.
That's much simpler, doesn't require to use an advanced feature like SUQWT and has a bigger impact.
It also may recover faster once you decide the other client is not really a "leecher" anymore, whatever the definition and the methods used to "discover" it are.

This post has been edited by CiccioBastardo: 02 August 2008 - 12:18 AM

[taz-me]

1. It's not a replace meant for score reduction / divider rather than an "enhancer".

2. Further more, let us assume that score divider or any other measure used by a mod is working :

leechers will become the longest waiters on queue that didn't "get any" thus eventually their score due to wait will have a weight (even more when mod is re-invoked after a long session) ...

[Dick_Manitoba]

From what you are proposing, the result would be equal to a ban if...

1) The client punishing is regularly restarted daily or only run for short durations of time and,
2) Has a share which has many hundreds or thousands of clients requesting downloads at all times.

The leecher has no hope of getting a download unless everyone in the saved queue happens to be offline, and there is little chance of that There are plenty of people whose mules run this way.

[taz-me]

Dick_Manitoba, on Aug 2 2008, 07:54 PM, said:

From what you are proposing, the result would be equal to a ban if...

1) The client punishing is regularly restarted daily or only run for short durations of time and,

I hope "my" (I'm involved in coding them) mods are not to be used only for short sessions (besides - leechers loosing time on queue occurs only when identified as thieves for the first time, or due to the nature of user / leecher mod shifting to clear and being re-identified).

Quote

2) Has a share which has many hundreds or thousands of clients requesting downloads at all times.

and why non leechers should suffer on such scenario ...

Quote

The leecher has no hope of getting a download unless everyone in the saved queue happens to be offline, and there is little chance of that There are plenty of people whose mules run this way.

I do wish to express my sympathy with the ones using leecher mods - this is why on my mods SUQWT is embedded (i.e. forced on).

BTW: it's not a single sided ban - since queue time is preserved as long as leecher is not switching identities ... It is just that if leecher detection works and score reduction or credit system shift leechers down the queue - there's no reason for them to "get any" just because they wait. If queue is empty or short they'll get if not - well using a leecher mod might turn to be a wrong choice

and yeh, I forgot but my mods also include another gift for leechers :

no queue bypassing - power shared files (since no session ratio on all my mods - power share can be only for completed files) are calculated as normal priority for leechers (I got a non complimentary on that one), however I do prefer that files power shared by users of my mod be downloaded mostly by non leechers

This post has been edited by taz-me: 03 August 2008 - 05:15 PM

[CiccioBastardo]

taz-me, on Aug 3 2008, 07:02 PM, said:

It is just that if leecher detection works and score reduction or credit system shift leechers down the queue - there's no reason for them to "get any" just because they wait.

This is a point I disagree. Whatever are your, my, or anyone else's rules to mark a client as leecher, waiting time should be used as a compensation (this excludes one way banned ones for GPL violation, of course). In my mod, with SUQWT and FineCS, any client has a chance to get a chunk if it waits enough. Enough may mean waiting 10x, 20x or even more the time of other "well behaving" clients. If all clients would serve them this way, their download speed would be slow enough to users of such clients think twice before using them. They are allowed to use them for whatever reasons, but with much worse performances.

BTW, your mod is not the only one not powersharing files to so recognized "leechers"

[LorenzoC]

There is something I don't understand here. What is the difference between the "string detection" and the "by behavior" about this permanent score reduction? It looks exactly the same as in the Xtreme mod.

[taz-me]

LorenzoC, on Aug 4 2008, 11:57 AM, said:

There is something I don't understand here. What is the difference between the "string detection" and the "by behavior" about this permanent score reduction? It looks exactly the same as in the Xtreme mod.

"string detection" means dealing with either unaware or very arrogant users : those that uses leecher mods and don't change (although on most leecher mods they can) sent modstr or nick ...

If an official user will chose a leecher mod default nick he is very likely to be "string detected" ...

and :

the thread is not about score reduction - it is about not counting wait time of leecher mods users (my current implementation is currently applies the "no suqwt" only for mod and nick thieves - since this is a certified detection and is not counter oriented) in our upload queue from previous sessions (of our mod).

I know the next line is not very scientific, however an Israeli releaser reports a drop from 60-70% of downloads by mod and nick thieves to 5-10% using a combined "no suqwt" and "no powershare" for leechers private (non public beta).

I'm aware that in term of statistics this data is worthless - however it might supply a point to think about.

[LorenzoC]

Yes but "mod/nick thieves" are only most the stupid leechers you could simply ban, don't you think? It is one of the few obvious "bad signs" you can catch. It is more or less the same as banning upon mod string, what stupid leecher would send you the real mod string to be detected? My doubts were about those clients that are more difficult to indentify as "bad" because they act the same as the official or other "legit" mods. If you are a releaser I can download the whole file you are releasing without being asked to reciprocate so how can you tell if I am bad or not, unless I do something stupid like giving you your own nick/mod or hammering you with requests? I also suspect one can be bad even when reciprocating the bare minimum in the credit system "trading".

Ok, sorry if I went OT.

This post has been edited by LorenzoC: 04 August 2008 - 01:30 PM

[CiccioBastardo]

Quote

the thread is not about score reduction - it is about not counting wait time of leecher mods users

You're right, of course. Mine was just a suggestion that a better results can be achieved with an easier method than with one like yours. Of course, you're free to use whatever method you like, like stated in post 2, line 1.

[taz-me]

LorenzoC, on Aug 4 2008, 03:28 PM, said:

"mod/nick thieves" are only most the stupid leechers you could simply ban, don't you think?

Why ban a potential source ??? (just because he is detectable is not good enough, at least not for me)

My suggestion is sort of "poetic justice" - give the guy what he wants :

If one wants to change / disguise himself well let give him what he asks for - re-enter of queue (since he's a new guy now - or so he claims ...)

BTW final implementation code for CA based mods (should work for CA based mods without SUQWT as well, however with reduced efficiency - since the gain of queue wait time for non leechers is smaller) :

void CAntiLeechData::SetBadForThisSession(const UINT i, const CString& strDetail)
{
	SetBadTimer(); //keep bad status for some time
	if(parent && (bBadForThisSession&i)==NULL)
	{
		CString reason = L"none";
		if(i == AT_NICKTHIEF)
		{
			theApp.antileechlist->IncBadActionCounter(BAD_ACTION_NICKTHIEF);

// By Taz - no SUQWT for ModThief or NickThief
			if (parent->Credits()){ // 1'st identify
				parent->Credits()->ClearUploadQueueWaitTime();
				theApp.QueueDebugLogLineEx(LOG_CA | LOG_WARNING, L"Analyzer: Nick thief (%s) loses wait time", parent->DbgGetClientInfo());
			}
// <------- no SUQWT for ModThief or NickThief

			reason = L"NickThief";
		}
		else if(i == AT_MODTHIEF)
		{
			theApp.antileechlist->IncBadActionCounter(BAD_ACTION_MODTHIEF);

// By Taz - no SUQWT for ModThief or NickThief
			if (parent->Credits()){ // 1'st identify
				parent->Credits()->ClearUploadQueueWaitTime();
				theApp.QueueDebugLogLineEx(LOG_CA | LOG_WARNING, L"Analyzer: Mod thief (%s) loses wait time", parent->DbgGetClientInfo());
			}
// <------- no SUQWT for ModThief or NickThief

			reason = L"ModThief";
		}
		else if(i == AT_FILEFAKER)
		{
			theApp.antileechlist->IncBadActionCounter(BAD_ACTION_FILEFAKE);
			reason = L"FileFaker";
		}
		else if(i == AT_UDPFNFFAKER)
		{
			theApp.antileechlist->IncBadActionCounter(BAD_ACTION_UDPFNF);
			reason = L"UDPFNFFaker";
		}
		else
			ASSERT(0); //this should not happen...
		if(parent && thePrefs.GetLogAnalyzerEvents())
		{
			if(!strDetail.IsEmpty())
				reason.AppendFormat(L" - %s", strDetail);
			theApp.QueueDebugLogLineEx(LOG_CA | LOG_ERROR, L"Analyzer: Marked as %s: (%s)", reason, parent->DbgGetClientInfo());
		}
	}
	bBadForThisSession |= i;
	ReCheckScore();
}

The code in BaseClient is not needed (non CA mods modders might want to look at it for a reference).
The changed code also "solves" the issue with stored leecher information that is loaded when mod starts.

This post has been edited by taz-me: 05 August 2008 - 05:15 AM