[James R. Bath]

p!ll3.p4ll0, on 05 July 2010 - 06:55 PM, said:

all of those mods getting a skull here for XS/ReAsk are also marked as modfakers.

Not in the matches I listed here. Are you talking about tests/matches you've done personally or do I need to rewrite the matches above to be clear that essentially zero have been marked as modfakers? Or do I need to mention that I keep a very up-to-date and relatively aggressive blocklist that's enforced at the firewall level as opposed to eMule's ipfilter?

[pier4r]

Stulle, on 05 July 2010 - 08:44 PM, said:

However, having figured out that there is indeed a minor flaw in the official code it is noteworthy, that we basically the CA is detecting a bug rather than actual bad behavior in a number of times.

I can say that this thread is not useless at all, because, as you said, it (re?)showed a flaw in official code (thanks to CA ) and underlined how to product a bad (imo) statistical work.

This post has been edited by pier4r: 05 July 2010 - 07:21 PM

[Stulle]

No, James made the thread pointless because his assumption is not there might be a bug, his objective is to further his smear campaign against MorphXT regardless of how wrong his assumptions and arguments are/were. He is further blackmailing and playing child's games. Nope, nothing a sane, intelligent person would do. And this makes this entire thread redundant.

As for the error, actually, it's kind of bad when clients get punished for a bug. So until this is resolved it would be best to make the CA not punish this.

This post has been edited by Stulle: 05 July 2010 - 07:57 PM

[tHeWiZaRdOfDoS]

Hm, as stated before: it *shouldn't* happen that this bug is punished so hard, fastXS and normalXS should be balanced then, that's why I think there may still be some issue elsewhere. I guess I'll add some Xtended logging

[p!ll3.p4ll0]

James R. Bath, on 05 Juli 2010 - 06:30 , said:

• Morph: 9 skulls out of 37 total (24.32% - all FastXS)

Stulle, on 05 Juli 2010 - 08:44 , said:

PS: pP, what MorphXT problem are you referring to? James spreading shit about MorphXT or something code wise?

I did refer to the quote above. Lately there are a lot (mods pretending to be) MorphXT clients, which get skulled or a score reduce. Almost all of those with a skull for fast xs and/or reasks are modfakers, and thus the problem is not related to "official" MorphXT mod in the extend James is selling us in every post.
And as I wrote "almost all", the rest (none-modfaker Morphs) gets skulls for a bad ul/dl, which will level out again sooner or later. So not a big matter aswell.

This post has been edited by p!ll3.p4ll0: 06 July 2010 - 06:29 AM

[Stulle]

well, if it's actually a leecher problem I would prefer you to refer to it as such. the Morph team has no affiliation with any of the leechers and although it is regrettable that our work is misused for them i would rather not have this confused, especially in the light of James' campaign. anyway, thanks for clearing up what you meant.

wiz: true, it should prolly not happen but there are cases where this can happen and this should be taken care of because it is, as of now, proper behavior, even though it may be a bug.

[tHeWiZaRdOfDoS]

Bug or not - as described here this shouldn't happen with CA as every 2nd request wouldn't be counted as "fast".

[Stulle]

true but if i am not mixing something up right now - which is well possible with all the things on my mind right now - it could still punish unmodified clients. the scenario i am thinking for is that we have only two downloaders and one of them only downloads this one file. IMO this would eventually cause at least slight punishment for FastXS, right?

i think it could be beneficial to check if you added a small switch that ensures it's not counted as FastXS if the last request you got was not replied to. this way you might miss a FastXS or so but it also serves the "in dubio pro reo" mentality of the CA. how about it?

edit: also, for this logging, it would be nice to see the number of XS requests in this log line so we can see how many of the XS reqs were actually send too fast. it's not exactly helping a lot but it might help understand how the remote client operates.

This post has been edited by Stulle: 06 July 2010 - 11:50 AM

[tHeWiZaRdOfDoS]

Stulle, on 06 July 2010 - 01:47 PM, said:

true but if i am not mixing something up right now - which is well possible with all the things on my mind right now - it could still punish unmodified clients. the scenario i am thinking for is that we have only two downloaders and one of them only downloads this one file. IMO this would eventually cause at least slight punishment for FastXS, right?

Hardly... basically you are being punished after 3 too fast XS requests. With the code described above you will add ONE, subtract ONE, etc. - you will never get above that limit, except in rare cases... but you should NEVER EVER reach values as seen in the logs that James posted.

Quote

i think it could be beneficial to check if you added a small switch that ensures it's not counted as FastXS if the last request you got was not replied to. this way you might miss a FastXS or so but it also serves the "in dubio pro reo" mentality of the CA. how about it?

As described earlier: I'll add sending of a "0 source packet" so the remote client won't hammer us.

Quote

edit: also, for this logging, it would be nice to see the number of XS requests in this log line so we can see how many of the XS reqs were actually send too fast. it's not exactly helping a lot but it might help understand how the remote client operates.

That'll be a bit hard because I don't save that value right now.

[Stulle]

oh, i overlooked the decrease line. sorry.

about the last thing, i was thinking of just displaying IncXSAsks() in the same line.

[James R. Bath]

p!ll3.p4ll0, on 06 July 2010 - 07:27 AM, said:

I did refer to the quote above. Lately there are a lot (mods pretending to be) MorphXT clients, which get skulled or a score reduce. Almost all of those with a skull for fast xs and/or reasks are modfakers ... rest (none-modfaker Morphs) gets skulls for a bad ul/dl,

What is that based on? I make it very clear in the "testing conditions" area on each match that I exclude fakes/thieves and bad ul/dl from the stats. Do you (or the official Morph technical expert on Morph source) have fake detection code not yet shared in your mods?

[Stulle]

Yeah, it's called common sense. We got the code which is same as official and we got at least two leecher mods based on MorphXT which are updated regularly for well over a year now. Again James, even though you seem ignorant to any kind of common sense, you finally need to acknowledge that you just don't know anything about the remote clients except the things they make you believe and you got no way to confirm those claims! Thus, you can't say all clients identifying as MorphXT - excluded the obvious fakes - are in fact MorphXT because you got no real evidence for that. On the contrary, we got not just good reason to say not all MorphXT are likely real MorphXT but we also got evidence of that.

[James R. Bath]

Stulle, on 06 July 2010 - 08:55 PM, said:

Yeah, it's called common sense. We got the code which is same as official and we got at least two leecher mods based on MorphXT which are updated regularly for well over a year now. ... you can't say all clients identifying as MorphXT - excluded the obvious fakes - are in fact MorphXT....

So scientific, so reproducible. The methodology is so technical. I'm sure all the leechers appreciate this CS. Now when they post their BS mod and it leeches, they can just point to your post and say "Look, we don't need evidence, you need CS. It's clear that those clients are just identifying as our mods." What a beautiful excuse for leechers and buggy programmers everywhere. A masterpiece of BS.

[Stulle]

Okay, Mister Super Smart, if you think you know better than me tell me the following: how do you identify a client which has no ratio? How do you figure out the difference between a MorphXT client with a 1:3 ratio like it should be and a crappy MorphXT+ which has a 1:7 ratio and still sends the same name tag?

Until you answer these two you better shut your moronic trap because you are about as intelligent as my friends three year old daughter with the one major difference that she is able to learn and does what she are told. Freaking idiot...

[James R. Bath]

Stulle, on 07 July 2010 - 08:00 AM, said:

Okay, Mister Super Smart, if you think you know better than me tell me the following: how do you identify a client which has no ratio?

Within the context of this topic, you identify it based on what it does. If it reasks too often, sends bad hashes, shares fake files, etc., you identify it with an empty skull.

Quote

How do you figure out the difference between a MorphXT client with a 1:3 ratio like it should be and a crappy MorphXT+ which has a 1:7 ratio and still sends the same name tag?

That's a session ratio, correct? How is that relevant across sessions? Or are you saying that tHeWiZaRdOfDoS should add code to CA that does the following:
IF client = Morph AND ratio < 1:3, THEN client = modfaker.

[Stulle]

No, I am saying you pretend anything that appears to be MorphXT at your end is the exact client I am publishing. I tell you, however, that this assumption is pure wrong because you just can not say this. In fact, any "MorphXT" behaving badly is a lot more likely to be a leecher because until the date you could not actually prove any code in MorphXT is bugged or otherwise bad.

So what I am getting at; STOP SAYING MORPH IS BAD UNLESS YOU HAVE REAL PROOF, MORON!

PS: And no, I am not speaking about the session ratio attained but the session ratio possible. You will never possibly figure that out for another client and thus you can not possibly distinguish good MorphXT client from tempered bad "MorphXT" clients that both send, say, "MorphXT 12.3". AND THIS IS WHAT I, AS MUCH AS SOME OTHERS, TRY TO GET THROUGH TO YOU FOR FIVE F'ING PAGES NOW!

This post has been edited by Stulle: 07 July 2010 - 03:38 PM

[James R. Bath]

Stulle, on 07 July 2010 - 04:35 PM, said:

In fact, any "MorphXT" behaving badly is a lot more likely to be a leecher because until the date you could not actually prove any code in MorphXT is bugged or otherwise bad.

So, IF client ID = MorphXT and behavior = bad, THEN client = modfaker

Quote

PS: And no, I am not speaking about the session ratio attained but the session ratio possible. You will never possibly figure that out for another client and thus you can not possibly distinguish good MorphXT client from tempered bad "MorphXT" clients that both send, say, "MorphXT 12.3".

Yet CA does identify clients that identify as MorphXT versions as fakes. Apparently it's currently able to do what you claim is impossible. So now you're saying CA should never identify a mod identifying as MorphXT as a fake? Or are you back to your "common sense" methodology that you and only you can identify whether a Morph mod is a real Morph mod?

[pier4r]

James, i have a question to you.

If i take a morphx and i change some code (mostly about upload and credit shaping) without change the mod string // mod identification procedure and eventually CA mark with a skull this client, can you state that "this is a bad morphxt *"?

* morphtx as official morphtx, so you will not state "this is a bad leecher modification of morphtx".

This post has been edited by pier4r: 07 July 2010 - 04:13 PM

[James R. Bath]

pier4r, on 07 July 2010 - 05:11 PM, said:

If i take a morphx and i change some code (mostly about upload and credit shaping) without change the mod string // mod identification procedure and eventually CA mark with a skull this client, can you state that "this is a bad morphxt *"?

* morphtx as official morphtx, so you will not state "this is a bad leecher modification of morphtx".

If you mean under a CA that coded Stulle's latest fake excuse, yes, any client that has an official MorphXT ID that has a skull for any reason would than also be marked as a mod faker. It wouldn't matter if it was your changed MorphXT or an official MorphXT. You (we) need to ask tHeWiZaRdOfDoS if CA is currently able to distinguish between such a changed Morph and an official Morph and what conditions would allow it to currently ID a client claiming to be a Morph to actually be a mod fake/thief.

[SS1900]

about the CA from wiki source :

The Client Analyzer (or CA) is a project of the German modder Wizard. This system has the goal of recognizing Leecher as do alternative systems to the IC, such as AntiLeechClass always wizard (for example, contained in Ionix), the DLP Xman (Xtreme) or the Argos to Xanatos (NeoMule) .
The CA creates a ranking of conduct based on heuristics which is to give a more complete picture on the clients and their real identity.
[edit] Operation

The Client Analyzer does not block tags, nicknames or modstrings, analyze first the behavior of the client, thus making possible a fair treatment of all customers by behavior. So, for example-Spammer Mod as ketamine, but also customers, who download a lot without posting, will be punished by the CA.


Some aspects of the CA Exchange:

* How long a client is known someone (who retains his Hash-user gets a small bonus);
* Report DL: UL;
* What kind of UL / DL's state (files complete, incomplete, rare);
* If you use a nickname stolen, a sequence mod stolen or corrupted files are sent;
* If requests are made too quickly (client-aggressive);
* If requested source can be done too often and / or ignoring the requests received.


Each client has a chance to be punished, rehabilitated, this is one of the biggest advantages of CA, in practice, a client identified as incorrect, if you send files to upload to the network is rehabilitated and no longer banned / penalized (this does not happen in other systems other than CA where clients are banned inevitably "lost" even if they could send files to upload, this is both unfair and unnecessary).

Rehabilitation is effective when we receive from these clients banned / penalized for chunks, which vary according to the penalty in the case of Mod that steal Nick, the penalty is 5 chunk to return to 'normal' level.


The idea behind the CA was a Wizard and update the list leecher for the umpteenth time. Alternative systems to the IC have some disadvantages:

* Must be constantly updated;
* High consumption of CPU (because of continuous monitoring);
* Block / sanction to all Bad-Mod blacklisted in some cases even if they are "useful" to the network (sending files to upload).
* Are sometimes punished releaser.


Relative to AC 1.4 and 1:55
[edit] Clients that implement the Client Analyzer