Different credit systems
Official: There are two different credit modifier calculated, eMule will use the low number:
* Ratio1 = Uploaded Total x 2 / Downloaded Total
* Ratio2 = SQRT(Uploaded Total + 2)
Both ratios are compared and the lower value is used as modifier. Some boundary conditions also exist:
* > Uploaded Total < 1MB => Modifier = 1
* > Downloaded Total = 0 => Modifier = 10
* > The modifier may not be lower than 1 or higher than 10
Peace: Same as official with shorter and slower code.
Xman: This feature is an enhancement of the existing credit system. It rewards clients which gives you a high download. This clients gets a bonus factor.
On the other side, clients you upload much data and they don't give something back to you will get a penalty for the current emule session.
* Bonus = (download - upload)/10485760 - 1.0/(download/10485760)
Magic angel: Same as official, only some difference:
- it gives Credits for Upload more than 1.65MB (official 1.00MB)
- the lowest modifier is 0.1 (official 1.0)
- the highest modifier is 50.0 (official 10.0)
Magic angel +: Same as Magic Angel, but increases the modifier a bit, if the client uploaded to us more than we uploaded to him.
Ratio: Based on official cs, but lowest modifier's 0.1 not 1.0 in official. Multiplier 2x, 4x, 16x only.
Ratio by Stulle: In contrast to its name, it is not based on UL/DL ratio, but on DL, UL values and their differencies.
There is not only 1 or 2 formul for calculate it. Isn't simple to understand it... and much difficult for me to explain.
Neo: The Standard Score is 1.0. The uploaded/downloaded values are in bytes. If the Client does not has a file we need he will get a 1.0 score in any case. If the Client does not have a good SUI only Session Transfers are counted. Also this, have 2 very much complicate formules....
Pawcio: Chages from official:
* Range from 1.0 to 100.0
* Multiplier of 3 (instead of 2) ---- ratio = 3 * downloaded / uploaded
* For new clients (downloaded and uploaded data less than 1MB) ratio = 3.0 (instead of 1.0)
* If you have received more than 1MB from someone but haven't given anything back user gets ratio = 100.0
* Small bonus for clients that have given you many MB:
o if you get 100MB then user receive ratio = 50.0 till you give back 108MB
o 50MB - ratio = 25.0 - 55MB
o 25MB - ratio = 12.0 - 28MB
o 10MB - ratio = 5.0 - 12MB
Fine: punish client for downloading partial files without giving back. Is an antileech feature.
S.W.A.T.: I don't know if I remember right, but is same at official. Only max multiplier 100.
Sivka:
IS_IDNEEDED --> Ratio = 0.75
failed ident --> Ratio = 0.5
Bad client --> Ratio = 0
diffTransfer = upload - download
If udiffTransfer >= 1GB --> ratio = 32
else if 0 < diffTransfer < 1GB --> ratio = sqrt({diffTransfer in MB})
else ratio = 1
Eastshare:
- +6 per MB uploaded and -2 for downloaded;
- +100 if upload 1MB+;
- if rating < 50 and upload 1MB+, rating = 50
Lovelace: Credit Thefts will not get any credits. Only clients using the 'SecureHash' are able to get a multiplier of 100. All others will stick at 10. In contrast to the original credit system, credits are evaluated more on differences and not on quotients. Using the original system you have the best credit values shortly after generating a new userhash. With the new credit system you get good credit values faster if you already have uploaded many MB before (and did not cheat by killing the userhash). (old system: 5up/ 5down = DLModifier of 2, additional 5up = DLModifier of 4 10up/10down = DLModifier of 2, additional 5up = DLModifier of 3 -> for the same amount of additional upload you get less score (-25%) new system: 5up/ 5down = DLModifier of 1.16, additional 5up = DLModifier of 2.31 10up/10down = DLModifier of 1.85, additional 5up = DLModifier of 5.09 -> for the same amount of additional upload you get more score (+120%) because you already uploaded a certain amount before.)
l-modifier=100*((1-1/(1+exp((3*{MB uploaded to us}^2-{MB downloaded from us}^2)/1000)))^6.6667)
Client Analyzer: Assigns a score to clients based upon analysis of their behaviour, such as:
- how long one knows someone (bonus for every week that a client keeps his hash)
- upload/download ratio
- kind of up/download (complete/partial/rare)
- anti leecher options; nickthieves, modthieves, filefakers, spammers, xs exploiter or hammerer are taken into account
- avg reask time
The client analyzer will punish but NEVER BAN !
TK4: If you are sharing completed files and someone downloads data from one of these from you they probably cannot give you data back as you have all of the file. So in the TK4 system their credit rating remains unchanged. If you are downloading a file and someone takes data from you from the parts of the file you have they will be subject to the credit system and depending on how much they have given they may have their credit rating reduced. At any time if anyone gives you data they get a credit rating increase.
INVERSE CREDIT SYSTEM (LEECHER FEATURE):
Give a 10x score increase to clients in your download queue (you will be wanting something from them soon).
Penalize NoNeededParts and queuefull 2x (currently they're not needed but they might be in future, upload to them when all other sources have a score of at least 5).
Give a slight score increase if the estimated waiting time in their queue is low.
Give a slight score increase (smallest) for waiting time, just to be fair.
OK, that is what I know. If someone can explain more, or better, write here and I will add information in this guide.
THX TO eMULE WIKI !
Dynamic Upload Systems
All we, know in eMule the upload is very important, and in eMule there is a metod for control his effective speed. The dynamic upload. This will do a ping test, and with this can check if your connection is active and know the real upload speed, and eMule will limit upload in automatic.
NB: This system sometimes have some problem, and for this is better try to do some test manually and we decide the value. But if work good, use it for have the best results.
UploadSpeedSense (USS): You can set this options:
1. Minimum upload value: Explanation needed ? Set 1/2 of max speed
2. "Ping Tolerance (% less than the Table)", default = 500, my advice is set 400. More high this value, more high (but instable) upload speed.
3. Ping Tolerance (ms): Absolute value of ping tests. If you don't change it is not active, and is my advice
4."Increase Speed" and "Decrease speed": eMule will increse or decrese speed from this value. More high, more sensible (and instable...). 1000 is good, if you would slow reaction use 800.
5.Max ping to the average: Number of ping for average. 1 is good, do not change. 2 is unseless and often have problem !
Smart Upload Control (SUC): This is a different system, you can also show how it work in the log if you want. You need always to se a minimum upload limit (1/2). SUC, will give more upload to client wich can receive it and less with client wich have problem to receive it by a ping test, with know also total upload speed like USS. About the configuration, the default values are ok, do not change it. This system is inferior at USS and NAFC !!!
Network Adapter Feedback Control (NAFC): The NAFC not need configuration, and know the real traffic between modem and pc. The advantage are: More accurate, faster reaction time, no hoverhead.
Disadvantage: Don't work on some operative system like win 95, administrator permish are requested and see the traffic of all computer in the LAN. Explanation of NAFC by Maella for the curious:
Code:
NAFC (Network adapter Feedback Control)explanation by Maella:
Zitat:
Introduction
All applications that need to regulate their upload bandwidth face the same problems. When you ask the operating system (OS) to send data to a remote client, three different things could happen:
- The sending could be proceed immediately
- The sending could be delayed by the OS (e.g. remote client not ready, limit of the capacity of the network already reached)
- The sending could be never proceed by the OS (e.g. connection with the remote client is lost)
Another problem is that a part of the traffic on the network is generated by the protocol itself. So typically when data are received from a remote client, the OS must send some acknowledge (ACK) packets to the remote side to validate the transfer. These ACK will increase the overall traffic as well. The protocol creates an overhead that an application can not fully control.
And finally, others applications can generate traffic for their own purposes (e.g. ftp, browser).
In summary: when an application attempts to regulate its traffic, it knows what it's trying to send, but it doesn't know exactly when it is sent and what it is sent.
Ideal Solution
In the case of eMule, the ideal solution would be to know in real time the current level of the traffic though the modem (e.g. K56, ADSL, etc..). So if an application was award of it, it would be piece of cake to regulate the bandwidth. Keep in mind that the goal is to use all the time 100% of the capacity of the modem. Nothing more, nothing less!
Unfortunately, there is no easy way to retrieve this information from the modem.
Current solutions
There are different approach to solve the above problem. Here it a list with some of them:
1. Under use the bandwidth to insure having enough rooms for the protocol overhead (e.g. the official eMule).
Disadvantage:
-all bandwidth is not used
2. Try to send periodically packets (ping) with the purpose of measuring the reaction time of the modem. So if the reaction time gets too high, it could indicate a beginning of saturation of the modem (e.g. ZZ UploadSpeedSense).
Disadvantage:
-add overhead to the traffic for the measure
-limited reaction time > 1s
-medium accuracy
3. Try to measure the reaction time of the remote clients. (e.g. SUC).
Advantage:
-no overhead
Disadvantage:
-limited reaction time >1s
-medium accuracy
-depends on the capacity of both the local and remote modems.
4. Measure the traffic at the network adapter level (Ethernet card) and not at the modem level. If all the traffic is only exchanged with the modem, then the network adapter will have a 1 to 1 image the modem's traffic => NAFC
Advantage:
-no overhead
-reaction time very fast <100 ms
-very accurate
Disadvantage:
-not available with all OS (e.g. win95)
-might require administrator right (could be change somewhere in settings)
-measure all the traffic sent or received by the local computer on the network (e.g. traffic with the modem + traffic with other computers on the local network)
5. Use the Layered Service Provider of windows....
Summary
The NAFC is certainly the best solution, but only if the network adapter is only used to exchange data with the modem.
Final infos: IMHO, the USS and the NAFC are the only solution, but is often is better set our own personal limit, in base our connection type and our speed test for effective speed and test (also experience) with eMule.
Antileecher Systems
The antileecher are "tools" in different MOD and serve to counteract (through penalties or ban) clients harmful to the network.
The Client Analyzer is a function designed by WiZardofDoS an antileecher system that is based on the behavior of a client to us. The client analyzer never ban and decide the punishiment from these factors:
Nick Thief - Mod Thief - File Fakes - UDP-FNF Fakes - Fast Asks - Spams - FastXS - Mod Fakes - Ratio UP : DL to us - Bonus wich who conserve userhash.
The Dynamic Leecher Protection use a .dll wich is needed update constantly wich can detect the leecher mods by their string. You can find the last version here: Browse emule Xtreme Mod Files on SourceForge.net
download it and change the old dll with the new.
FineCS will punish the clients if it have downloaded 4 chunks and never uploaded anything. His score will decrease if he don't upload never to us.
The Argos Was ideated by David Xanatos and is 1 of the more complete antileecher. It use also the DLP libary. He can detect and punish:
Nick thief - Mod thief - Hash thief - Credit hack - Hash changer - Ghost mods - Fake client - Aggressive client - File scanner - File faker - Bad sender - Rank flooder - Failed uploader - XS-Exploiter - Nick changer - Mod changer - NULL-Nick sender - Spammer - Suspect hello - Protocol violation.
The S.N.A.F.U. is a very aggressive antileech, which analyzes our upload queque.
This tool bans the leecher mod is largely based on identifying their specific tags.
The Sivka ban you can ban aggressive client. You can ban if they reask you X times every Y minutes wich you can select.
ALL IS EXPLAINED. FOR THE OTHER ASK UNDER THIS GUIDE !
Bookmarks