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？請明白人指點迷津……