eMule Fans 电骡爱好者

关于裸骡的信用系统，请感兴趣的朋友先看这两个帖子：
AUG大的帖子《EM的信用制度介绍与常见误区答疑，作者：pennyliu123》
常见eMule积分系统介绍——出来混，总是要还的！[原作者:SuperVirusQ]

　　之前看过SuperVirusQ的帖子，对于各种积分系统进行了比较详细的介绍。之后自己看了一下ScarAngel 3.1的源码，对照着源码进行了一些修正，顺便加上些个人的理解吧。希望有助于大家了解各积分系统的算法。
　　说明：这里的“上传”指该用户对我们的上传，“下载”指该用户从我们的下载。　
　　Sostan提供了MagicAngel、MagicAngel+、Neomule的积分系统算法说明。由于没有完全看明白，所以上网找了MagicAngel 3.6源码。不知道此版本是否老旧，不过积分算法应该不会有太大变化吧我估计……
　　另外原来的图有些短，有些朋友反映上传后期的积分变化没有表现出来，所以拉到200MB重新生成了Excel图表。

官方

如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为0.8。
凡是上传小于1MB的客户，评分系数固定为1.0；
对于上传超过1MB的客户，则综合考量以下两种情况的较小值：
　A：上传/下载比：评分系数A = 2 * {上传字节数} / {下载字节数}，若无下载则取10.0；
　B：上传量：对于上传小于一个文件块（9.2MB）的，取线性评分系数B = (({上传MB数} – 1 ) / 8.2 ) * 2.34 + 1；对于上传超过一个文件块的，取指数评分系数B = SQRT（{上传MB数}+2）；
最后，评分系数的有效范围是1～10。超出范围的取相应的极值。

Ejack的个人解读（一家之言仅供参考）：
1. 只有奖励，没有惩罚；
2. 奖励的幅度在“量”和“比”之间寻求平衡；
3. 修正值的范围小，变化速度较慢；
4. 由于没有惩罚措施，吸血骡无论怎么吸都始终是1，就如同洁白的新人一样，因此算法本身不具备任何反吸血能力；

Lovelace

如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为0.8。
首先确定一个临时参数：
temp = 3*{上传MB数}^2-{下载MB数}^2
temp的有效范围是-20000～+20000，超出则取有效极限值。
而后计算出评分系数：
评分系数 = 100*((1-1/(1+exp((temp)/1000)))^6.6667)
对于未开启迷惑协议的用户，评分系数的有效范围是0.1～10；对于通过安全认证的用户，评分系数的有效范围是0.1～100。超出范围的取相应的极值。

Ejack的个人解读（一家之言仅供参考）：
1. 与官版相比，增加了惩罚机制，同时加大了奖励的力度，更加重视对上传者的回馈；
2. 奖惩的幅度在“量”和“比”之间寻求平衡；
2. 在奖励方面，在特定区间内评分系数上升很快，最高能奖励到新人的100倍，因此上传大户将具有新人难以企及的高评分；
3. 在惩罚方面，最高能惩罚到新人的1/10，因此能够有效地逐渐疏远只下载不上传的客户，算法本身应能起到一定的反吸血作用；

Ratio

如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为0.8。
若上传总量≤1MB，下载总量≤1MB，则评分系数固定为1；
若上传总量≤1MB，下载总量> 1MB，则评分系数 = 1 / SQRT({下载总量})；
若上传总量> 1MB，下载总量≤1MB，则评分系数 = {上传总量}；
若上传总量> 1MB，下载总量> 1MB，则进一步划分以下情况：
　若上传总量 > 下载总量，则评分系数 = SQRT({上传总量}+1) + SQRT({上传总量} – {下载总量})；
　若0≤{下载总量} – {上传总量}≤1，则评分系数 = SQRT({上传总量}+1)；
　若{下载总量} – {上传总量} > 1，{上传总量}≥9，则评分系数取以下两个的较大值：
　　A = SQRT({上传总量}+1) / SQRT({下载总量} – {上传总量})；
　　B = 0.7 + SQRT({上传总量}+1) / 10；
　若{下载总量} – {上传总量} > 1，{上传总量} < 9，则评分系数取以下两个的较大值： 　　A = SQRT({上传总量}+1) / SQRT({下载总量} – {上传总量})； 　　B = {上传总量} / 9； 因此，其评分系数的有效范围是0.1～∞
算法几乎看晕了……最后才发现本质上是分段曲线拼接在一起。也是“量”“比”兼重的算法。
奖励的增长很平缓，不过对上传的要求很严苛，只要下载开始少于上传，就毫不留情地开始降分，下手相当狠辣。

Pawcio

如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为0.8。
对于上传下载都小于1MB的客户（新人），评分系数为3；
对于上传小于1MB、下载已经超过1MB的，评分系数为1；
对于上传大于1MB、下载小于1MB的，评分系数 = 10 * {给我们上传的MB数}；
对于上传大于1MB、下载大于1MB的，评分系数 = 3 * {给我们上传的MB数} / {从我们下载的MB数}；
而后通过以下算法对评分系数进行分段：
若上传大于100MB、下载小于上传+8MB，则评分系数最小为50；
若上传在50～100MB之间、下载小于上传+5MB，则评分系数最小为25；
若上传在25～50MB之间、下载小于上传+3MB，则评分系数最小为12；
若上传在10～25MB之间、下载小于上传+2MB，则评分系数最小为5；
最后，评分系数的有效范围是1～100。超出范围的取相应的极值。

Ejack的个人解读（一家之言仅供参考）：
没有特殊惩罚，只有特殊奖励。梯田……
非常重视上传的鼓励，尤其重视对亏欠的回馈。

EastShare

如果是不支持迷惑协议的用户，评分系数由0.8开始计算，其它用户评分系数由1.0开始计算（糊涂了，难道连恶意用户都不管了？也许是推荐DLP）；
每上传1MB，评分系数加0.06；每下载1MB，评分系数减0.02；
如果上传总量大于1MB，则评分系数+1；
如果上传总量大于1MB、评分系数小于0.5、上传大于下载的1/10，则评分系数取0.5；
最后，评分系数的有效范围是0.1～50。超出范围的取相应的极值。

Ejack的个人解读（一家之言仅供参考）：
鼓励上传、限制过量下载。以“量”作为唯一衡量标准的典范。如果你不喜欢用户的评分在较短的时间内发生巨大的变化，可以考虑使用这种积分系统。

Sivka

未认证用户在开启加密的情况下评分系数 = 0.75；认证失败用户评分系数 = 0.5；不良用户评分系数 = 0（一脚踢飞）；
若{上传总量} – {下载总量} >= 1023MB，则评分系数固定为32；
若0 < {上传总量} – {下载总量} < 1023MB，则评分系数 = SQRT({上传总量} – {下载总量} + 1)； 其它情况，评分系数固定为1.0。
Ejack的个人解读（一家之言仅供参考）：
算法很简单，完全以上传与下载的差值来评价用户。
只针对可识别的恶意用户进行惩罚。

SWAT

基本上和官方的积分系统相同，只是有以下三个小修正：
　官方系统中考核“比”的公式中，比例系数门限由2提高到2.2；
　官方系统中考核“量”的公式中，全部按照指数公式SQRT（给我们上传的MB数+2）计算；
　评分系数的上限从10改为100；

Ejack的个人解读:
更改的内容明显是更加注重对于分享的回报。

XMAN

（顾名思义，这应该是Xman琢磨出的算法修正吧）
如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为0.8。
如果上传小于1.65MB，则评分系数分段处理：
　若本次连接的下载量与上传量之差超过16MB，则评分系数固定为0.8；
　若在8～16MB之间，则评分系数固定为0.9；
　小于8MB，则评分系数固定为1.0；
如果上传大于1.65MB，则参照官版综合考量“量”“比”的较小值：
　A：上传/下载比：评分系数A = 2 * {总共上传字节数} / {总共下载字节数}，若无下载则取10.0。若采用“比”则有额外的加成：如果该用户的上传总量大于下载总量，则进行正向修正；如果下载总量大于上传总量，则进行负向修正：下载总量与上传总量之差大于16MB，且当前连接的下载上传差大于16MB，扣0.2；下载总量与上传总量之差大于8MB，且当前连接的下载上传差大于8MB，扣0.1；否则无修正；
　B：上传量：对于上传小于一个文件块（9.2MB）的，取线性的评分系数B = ((上传数 – 1M ) / 8.2M ) * 2.34 + 1；对于上传超过一个文件块的，取指数的评分系数B = SQRT（给我们上传的MB数+2）；
最后，评分系数的限定范围是1～10。超出范围的取相应的极值。实际有效范围是0.8～10。

Ejack的个人解读（一家之言仅供参考）：
1. 总体来说是官版积分系统的一个变种；
2. 增加了一点点惩罚的措施，最低能罚到0.8；
3. 奖惩在官版系统上略有加成；

TK4

所有用户默认的评分系数都是10。
如果开启了加密，则对未认证用户、认证失败用户、恶意用户进行如下处理：
　一旦{当前下载量} > 1.25 * {当前上传量} + 1，并且是请求已存在的文件块，则计算SQRT({当前下载量} – 1.25 * {当前上传量})，若值大于9，则评分系数 = 9 / x；若值小于9，则评分系数 = 10 – x；
对于正常用户，一旦{当前下载量} > 1.25 * {当前上传量} + 1：
　一旦是请求已存在的文件块，则计算SQRT({当前下载量} – 1.25 * {当前上传量})，若值大于9，则评分系数 = 9 / x；若值小于9，则评分系数 = 10 – x；
否则：
　如果总上传量大于总下载量，则评分系数 = 10 + log(2.72 + 4 * ({总下载量} – {总上传量})) + {总上传量} / 12；

Ejack的个人解读（一家之言仅供参考）：
1. 非常重视惩罚，但是惩罚的条件偏严格（系数超过1.25），自我保护意识很强烈；
2. 奖励的依据是总量，奖励既考虑总量也考虑差值；
3. 不设上下限，评分差距可能超级悬殊，十分有个性；

ZZUL

如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为1.0（我猜想可能是推荐通过DLP封杀主流吸血骡）。
如果上传小于1MB，则评分系数固定为1.0。
对于上传超过1MB的客户，则综合考量以下两种情况的较小值：
　A：上传/下载比：评分系数A = 2 * {给我们上传的字节数} / {从我们下载的字节数}，若无下载则取10.0；
　B：上传量：始终取指数的评分系数B = SQRT（给我们上传的MB数+1）；
最后，评分系数的限定范围是1～10。超出范围的取相应的极值。

Ejack的个人解读（一家之言仅供参考）：
1. 跟官版积分系统基本相同；
2. 算法本身没有惩罚措施；
3. 上传奖励比官版系统微微削减；

MagicAngel

基本上和官方的积分系统相同，只是有以下三个小修正：
　如果开启了加密，则所有未认证用户、认证失败用户、恶意用户的评分系数固定为1.0（官方是0.8）。
　上传超过1.57MB或者下载为0的就开始有上传加分（官方为1MB）；
　评分系数的下限从1改为0.1，上限从10改为50；

Ejack的个人解读（一家之言仅供参考）：
但是……从Excel中出图后发现上限实际上还是10！仔细核对源码后发现是因为在取指数系数时的默认上限没有改（仍然是10），导致最终取较小值时上限仍然被封在10.0。我不知道这是怎么回事，我拿到的源代码是【eMule-0.49b-MagicAngel-v3.6-src.rar】。难道真的让我发现个bug？请明白人指点迷津……