Official eMule-Board: Clientanalyzer Questions - Official eMule-Board

Jump to content


  • (2 Pages)
  • +
  • 1
  • 2

Clientanalyzer Questions

#1 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 23 June 2011 - 10:37 PM

I saw the code of ZZUL TRA 2.3 with CA of TS 2.1 (i guess), that should it be the lastest CA code. If i understood correctly, fast source exchange and fast reask are counted (and that is good, thanks wiz.) for bad clients, anyway these stats are not saved with timings. So it is possible that an user can use, for some sessions, a bad client and thus we store a lot of "bad" statistics about him. After a while the user can switch back to plain emule and anyway he must wait a lot (for example 100 fastXS needs 100 goodXS that are not done for sure in few sessions, maybe because the remote client doesn't wait for a long time (e.g: 8-12h) in our queue for each session) before that he can consider again a "good client".
So, why not store the stats about fastXs and reask with timestamps? Sure it needs more ram and disk space but is more accurate (so CA can choose which stats are good and fresh and which not). Anyway the fastest (in terms of code change) and less harsh solution that i found is to not store any data about fastXS and fats reask between sessions.
>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#2 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 24 June 2011 - 07:22 AM

Well the thing is that you want to get some protection in advance (i.e. as soon as you get the corresponding CA entry for a client).
I thought of different solutions but discarded them:
  • Store only the last X entries - discarded as a user *could* do a proper reask/XS every X times and go on with fast asks otherwise
  • Reset between sessions - discarded you won't have protection in advance and I also didn't come to a conclusion on how to define a "session" (local/remote restart of eMule, local/remote ip-change, etc.)

The punishment for fast asks isn't that bad and also not that common... I only found real bad mods doing that a lot.
1

#3 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 24 June 2011 - 12:17 PM

View PosttHeWiZaRdOfDoS, on 24 June 2011 - 09:22 AM, said:

Well the thing is that you want to get some protection in advance (i.e. as soon as you get the corresponding CA entry for a client).
I thought of different solutions but discarded them:
  • Store only the last X entries - discarded as a user *could* do a proper reask/XS every X times and go on with fast asks otherwise
  • Reset between sessions - discarded you won't have protection in advance and I also didn't come to a conclusion on how to define a "session" (local/remote restart of eMule, local/remote ip-change, etc.)

The punishment for fast asks isn't that bad and also not that common... I only found real bad mods doing that a lot.



the second one is "simple" (of course if you accept it): define a session as session for U:D ratio - the elapsed time with our emule open. (i know that there can be disconnections on our side, but the client is removed after a while and anyway these happen also now).

To store "last X entries", i do't agree with your statement. Also now a client can do a series of proper and fast reast like:
bad - good - bad - good
or
10 bad - 10 good
etc..
Anyway better than store X entries is store entries with max 'X' days of age (then: store a list of pairs of <badTimeBetweenReask,timeOfDetection>).

About fastXS. I see a lot of clients punished for fastXS i don't know why (a lot of them have lowid).

[1] i don't like so much the attitude of consider very few cases in RL as normal cases when these can be consider negligible or at least there are bigger problems with actual implementations (is a general consideration not for CA only)

This post has been edited by pier4r: 24 June 2011 - 12:19 PM

>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#4 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 24 June 2011 - 12:58 PM

View Postpier4r, on 24 June 2011 - 02:17 PM, said:

the second one is "simple" (of course if you accept it): define a session as session for U:D ratio - the elapsed time with our emule open. (i know that there can be disconnections on our side, but the client is removed after a while and anyway these happen also now).

So you have 100 "bad" clients, restart your mule (e.g. for an update) and upload to all of them because you haven't enough data... naaaah, that, I don't like :P

Quote

To store "last X entries", i do't agree with your statement. Also now a client can do a series of proper and fast reast like:
bad - good - bad - good
or
10 bad - 10 good
etc..
Anyway better than store X entries is store entries with max 'X' days of age (then: store a list of pairs of <badTimeBetweenReask,timeOfDetection>).

Yes, but in that case, he would "behave" at least 50% of the time while otherwise he could behave only (1/X)*100%...
Storing the date of the entries is - IMHO - quite an overkill. Reasks are usually no problem except for very bad clients but FastXS seems to be popular...

Quote

About fastXS. I see a lot of clients punished for fastXS i don't know why (a lot of them have lowid).

Well, that's really strange... it also happened to me that I saw quite a lot of FastXS requests but it's FAR from any number some of my testers posted. Maybe some stats about the different clients (high/low, etc.) would be interesting... I'll keep it in my head for the next release.

Quote

[1] i don't like so much the attitude of consider very few cases in RL as normal cases when these can be consider negligible or at least there are bigger problems with actual implementations (is a general consideration not for CA only)

I don't understand that :(
1

#5 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 24 June 2011 - 01:52 PM

View PosttHeWiZaRdOfDoS, on 24 June 2011 - 02:58 PM, said:

So you have 100 "bad" clients, restart your mule (e.g. for an update) and upload to all of them because you haven't enough data... naaaah, that, I don't like :P

Sure but think about a bit different case. I open emule after a week, and i start to punish all clients that **maybe** have tried a bad emule version. For reboots in a short time a bad client is recognized after short time anyway.

For the storing... if you don't want to store much data, the you can weight the "old data". For example old data can be evalued by a 0.8 factor, so really old data, after some reboots (problem: short reboots kill all data even if this is really fresh), can be cleared.

Quote

I don't understand that :(


Sorry for my bad grammar, i try to explain again my thoughts: "the current implementation is bad, can be cheated in different ways so i propose this new one" - "No! in a case a bad client can exploit also this new feature, so this feature is bad!" - "Ok but this case is most rare than current cases so..." - "No it's bad, we reject this proposal to keep the current!"
>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#6 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 24 June 2011 - 05:28 PM

View Postpier4r, on 24 June 2011 - 03:52 PM, said:

Sure but think about a bit different case. I open emule after a week, and i start to punish all clients that **maybe** have tried a bad emule version. For reboots in a short time a bad client is recognized after short time anyway.

Well, I somehow think about it from a different POV.
1. If someone tried a bad mod, then I'd suggest to get a new hash with the new mule - AFAIK that's already the case for most ppl as it's usually n00bs that fall into that category.
--> no problem
2. If they don't get a new hash, then they will be punished until they repent.
--> we can discuss this... you have to keep in mind that the client did (not so?) considerable damage to the network. IMHO, there's nothing wrong if he pays for it, now.

Besides, you have to keep in mind that there are only few clients out there that automatically harm the network but a LOT more that allow its users to do so manually...

Quote

For the storing... if you don't want to store much data, the you can weight the "old data". For example old data can be evalued by a 0.8 factor, so really old data, after some reboots (problem: short reboots kill all data even if this is really fresh), can be cleared.

Well, you don't know the code, I guess... and I don't blame you :)
But let it suffice to say that there are already a lot of ppl complaining about the increased RAM usage for the CA (which isn't that high, IMHO) and adding a timestamp to each entry would drastically and noticeably increase the memory we need.
Weighing the data would be a (nice) possibility... I could think of a version that allows to adjust it - I could make one for you to test if I find some time.

Quote

Sorry for my bad grammar, i try to explain again my thoughts: "the current implementation is bad, can be cheated in different ways so i propose this new one" - "No! in a case a bad client can exploit also this new feature, so this feature is bad!" - "Ok but this case is most rare than current cases so..." - "No it's bad, we reject this proposal to keep the current!"

Well, if I get that correctly you think I'm denying your proposal?
I think I've properly answered your questions and requests and I'm open to criticism (that's why I also noted my mail address in the CA files) but though I understand the issue I don't think about it being as worse as you think it is.
1

#7 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 24 June 2011 - 11:12 PM

View PosttHeWiZaRdOfDoS, on 24 June 2011 - 07:28 PM, said:

Well, I somehow think about it from a different POV.
1. If someone tried a bad mod, then I'd suggest to get a new hash with the new mule - AFAIK that's already the case for most ppl as it's usually n00bs that fall into that category.
--> no problem
2. If they don't get a new hash, then they will be punished until they repent.
--> we can discuss this... you have to keep in mind that the client did (not so?) considerable damage to the network. IMHO, there's nothing wrong if he pays for it, now.


For the second, also i thought that, but then i do some math and, next time the math that inspire these questions.


Quote

Well, you don't know the code, I guess... and I don't blame you :)
But let it suffice to say that there are already a lot of ppl complaining about the increased RAM usage for the CA (which isn't that high, IMHO) and adding a timestamp to each entry would drastically and noticeably increase the memory we need.

I admit that i ddidn't analyze all the code, but i know the calculation about it. e.g: a node of the list is X byte so the entire list structure in the average case needs X*Y bytes, etc... For example my antileech data store infos about 149000 clients, if we use only ~1kb for each client, we need 149 mb.
I'm aware (maybe not fully aware) of the ram & disk capacity needed, but i think that a (not quick) solution is possible.

Quote

Weighing the data would be a (nice) possibility... I could think of a version that allows to adjust it - I could make one for you to test if I find some time.

Thanks but don't worry, is enough to do a discussion with some simulations (so in the meantime i try to raise my C++ skill to gather statistics and do trials by myself).

Quote

Well, if I get that correctly you think I'm denying your proposal?


Absolutely not, as i stated before, it was a general consideration about the average attitude on a proposal/discussion on EP forum.

This post has been edited by pier4r: 25 June 2011 - 12:22 AM

>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#8 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 01 July 2011 - 12:14 AM

for example, some stats (for this i said: fastXS is a goo punishment, but bad clients will do enough fastXS also in a single session), after 2 days and 11 hours


ClientAnalyzer
 Nickthieveries: 6
 Modthieveries: 0
 File fakes: 16
 UDP-FNF fakes: 2
 Fast asks: 3093
 Spams: 2
 FastXS: 51467
 Mod fakes: 499

>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#9 User is offline   morph4u 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 147
  • Joined: 10-October 08

Posted 06 July 2011 - 09:07 PM

hi, i have also a question.

wiz, you have in CA:

Quote

if(time + AT_REASKBUFFER < m_uiReaskTime) //FiX too many "fast reask" entries in stat, only count the really bad ones


should this not be ?

Quote

if((time + AT_REASKBUFFER) < m_uiReaskTime) //FiX too many "fast reask" entries in stat, only count the really bad ones

1

#10 User is offline   Ejack79 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 155
  • Joined: 25-August 09

Posted 07 July 2011 - 12:17 AM

'+' is an operator with priority of 3,
'<' is an operator with priority of 5,
So basically it would not misfunction. Of course brackets are always preferred.
1

#11 User is offline   James R. Bath 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 790
  • Joined: 02-August 04

Posted 17 September 2011 - 12:07 PM

Since this jumps to the top of the list when searching on either antileech.met or clientanalyzer, and it has a nice general topic name, posting here as if it's the official ClientAnalyzer topic.


Combining/merging Antileech.met files

Is this possible? If I simply join 2 antileech.met files, will the entries get sorted out and combined when I run a CA mod or will it cause problems? Any known/potential safe ways to combine them?
Currently recommending and using: eMule beba 2.63
For slot control only, currently recommending: Tombstone Xtended 1.0 (or higher) if you absolutely must have slot control


Posted Image

Quote

Where there is a mule there is fuel. Where there is a stool sits a fool. - Winston Churchill

-2

#12 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 17 September 2011 - 12:28 PM

No, that's not possible (yet) - what do you need that for?
Basically, you'll have 2 or more .met files when using different hashes/clients - thus the data would be invalid for another client.
1

#13 User is offline   James R. Bath 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 790
  • Joined: 02-August 04

Posted 18 September 2011 - 12:32 AM

No devious plans yet. When I test a mod with CA, it's sad :cry: to lose the antileech intelligence. So you're saying that if I started up a new mod with a brand new hash, I couldn't use an existing antileech.met with it?
Currently recommending and using: eMule beba 2.63
For slot control only, currently recommending: Tombstone Xtended 1.0 (or higher) if you absolutely must have slot control


Posted Image

Quote

Where there is a mule there is fuel. Where there is a stool sits a fool. - Winston Churchill

-2

#14 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 18 September 2011 - 06:38 AM

Well you CAN use it but it's not intended that way... there is some data (e.g. the up/down stats) that doesn't make sense when used with a different hash... we may punish someone for leeching while he can't "know" that he should upload to us because of our different hash, you see?
1

#15 User is offline   James R. Bath 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 790
  • Joined: 02-August 04

Posted 18 September 2011 - 09:00 AM

I see. The UL/DL stats of the imported/non-primary antileech files would need to be zeroed before combined.
Currently recommending and using: eMule beba 2.63
For slot control only, currently recommending: Tombstone Xtended 1.0 (or higher) if you absolutely must have slot control


Posted Image

Quote

Where there is a mule there is fuel. Where there is a stool sits a fool. - Winston Churchill

0

#16 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 04 April 2013 - 12:12 PM

Wiz, if you are trying to make eMule a bit easier for noob users then I suggest some simple changes to CA. The anti-leech info either says unknown or will give a reason for being bad. It seems kinda funny that it says unknown so often - like just because it cant figure out how they are leeching doent mean that they are not. :ph34r:

I know what it means, but some inexperienced users might think unknown means that CA doesnt know, or its not working. Why not have it say unknown (or N/A) only for newly connected clients that it hasnt figured out yet, and have clients that arent bad say something different like neutral. Also, currently its just anti leech to punish right? Why not even extend CA to have it say good and reward clients?
0

#17 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 04 April 2013 - 12:19 PM

Yes, you're right... minor change, "big" impact - I like it :)
"Good" clients (upload a lot) and long known good clients will get a slight bonus, already.
0

#18 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 04 April 2013 - 10:43 PM

View PosttHeWiZaRdOfDoS, on 04 April 2013 - 08:19 AM, said:

Yes, you're right... minor change, "big" impact - I like it :)
"Good" clients (upload a lot) and long known good clients will get a slight bonus, already.


Oh, I wasnt sure. The end user cant see that so its hard to tell because theres not something like a happy face icon for clients that play nice nice with others.

Hmm, odd, I just noticed this and have no clue what it means: very bad UDPFNFFaker

What aboot adding some different skull & bones icons for bad clients to show the different severities of their bad behavior? i.e. clients that are doing a lesser leech behavior would get a white & black skull n bones icon, and more serious offenses (or multiple lesser behaviors) get a white & grey filled skull n bones, and the worst leech behavior gets a red skull n bones.

Also you might want to rename in client details the anti-leech info to something more appropriate like Client Analyzer results.
0

#19 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 05 April 2013 - 10:15 AM

UDP FNF Faker: there are some mods out there that DO request files from you and are sharing them but reply to your requests with a "file not found" message.
Out different icons and/or text... maybe... not a priority.
0

#20 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 06 April 2013 - 08:37 AM

Ya, you are right, its just a visual not necessary to work idea that would only make it look nice. I guess you have somewhat adopted Tuxmans beba philosophy with requests for function only. No problem.

Well, tbh I would like to see CA work totally differently. I have never been a fan of the multiplier "score" concept.

Heres my suggestion:

Have different CA rankings (Client Priority) with the corresponding handling for each:
great - clients with ul:dl ratio < 3:1 + every chunk they have is well shared = keep UL to 1st (there wont be many great clients out there, but might as well use em if ya find em)
very good - clients with ratio < 2:1 = UL to 2nd
good - clients with ratio < 1:1.5 = UL to 3rd
neutral - clients with best ratio < .5:1 = UL to 4th
suspicious - gpl breakers, with ICS enabled = UL to them only 1 chunk, then tft
bad - clients with lesser bad behaviors or bad ratio = tft (they must UL to you 1st, then return same amount)
very bad - clients with more severe bad behaviors or multiple lesser behaviors + bad ratio (+ICS) = tft (they must UL to you 1st, then you will return same amount) & never UL rare chunks (if others need same chunks, UL rare chunks to the others)
extremely bad - clients with most severe bad behaviors or multiple very bad behaviors (+ICS) + bad ratio = ban

I recommend that it works as a float, where the client priority over time will move up or down depending on how the client they choose to use behaves.

IMHO to fully utilize CA it would work best with a queue/file. When its time to UL a file you UL 1st to the clients who have UL to you the most. This is especially important for rare chunks to give to users with the greatest UL who are sharing the file the most. Try to find and utilize 100MB lines, while checking to see if the chunks are being well shared, if yes keeping UL to the Greats 1st. If no they drop down to being Very Good. Then cycle through the Q UL to the clients with the next highest Client Priority. i.e. next time you UL that file the next highest Client Priority gets a chunk, etc.
1

  • Member Options

  • (2 Pages)
  • +
  • 1
  • 2

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users