[參考] 官方、Lovelace、EastShare、MagicAngel等積分系統的比較

關於裸騾的信用系統,請感興趣的朋友先看這兩個帖子:
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。超出範圍的取相應的極值。
Lovelace演算法
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~∞ Ratio演算法
演算法幾乎看暈了……最後才發現本質上是分段曲線拼接在一起。也是「量」「比」兼重的演算法。
獎勵的增長很平緩,不過對上傳的要求很嚴苛,只要下載開始少於上傳,就毫不留情地開始降分,下手相當狠辣。

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。超出範圍的取相應的極值。
Pawcio演算法
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。超出範圍的取相應的極值。
Eastshare演算法
Ejack的個人解讀(一家之言僅供參考):
鼓勵上傳、限制過量下載。以「量」作為唯一衡量標準的典範。如果你不喜歡用戶的評分在較短的時間內發生巨大的變化,可以考慮使用這種積分系統。

Sivka

未認證用戶在開啟加密的情況下評分係數 = 0.75;認證失敗用戶評分係數 = 0.5;不良用戶評分係數 = 0(一腳踢飛);
若{上傳總量} – {下載總量} >= 1023MB,則評分係數固定為32;
若0 < {上傳總量} – {下載總量} < 1023MB,則評分係數 = SQRT({上傳總量} – {下載總量} + 1); 其它情況,評分係數固定為1.0。 Sivka演算法
Ejack的個人解讀(一家之言僅供參考):
演算法很簡單,完全以上傳與下載的差值來評價用戶。
只針對可識別的惡意用戶進行懲罰。

SWAT

基本上和官方的積分系統相同,只是有以下三個小修正:
 官方系統中考核「比」的公式中,比例係數門限由2提高到2.2;
 官方系統中考核「量」的公式中,全部按照指數公式SQRT(給我們上傳的MB數+2)計算;
 評分係數的上限從10改為100;
SWAT演算法
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。
XMAN演算法
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;
TK4演算法
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。超出範圍的取相應的極值。
ZZUL演算法
Ejack的個人解讀(一家之言僅供參考):
1. 跟官版積分系統基本相同;
2. 演算法本身沒有懲罰措施;
3. 上傳獎勵比官版系統微微削減;

MagicAngel

基本上和官方的積分系統相同,只是有以下三個小修正:
 如果開啟了加密,則所有未認證用戶、認證失敗用戶、惡意用戶的評分係數固定為1.0(官方是0.8)。
 上傳超過1.57MB或者下載為0的就開始有上傳加分(官方為1MB);
 評分係數的下限從1改為0.1,上限從10改為50;
MagicAngel演算法
Ejack的個人解讀(一家之言僅供參考):
但是……從Excel中出圖後發現上限實際上還是10!仔細核對源碼後發現是因為在取指數係數時的默認上限沒有改(仍然是10),導致最終取較小值時上限仍然被封在10.0。我不知道這是怎麼回事,我拿到的源代碼是【eMule-0.49b-MagicAngel-v3.6-src.rar】。難道真的讓我發現個bug?請明白人指點迷津……

9條評論隱藏

  1. #1 zhouxinyi
    2012年12月21日 周五 21:58 | 回復

    連迷惑協議都有加成,那現在國內開啟迷惑協議之後根本就連接不上國外伺服器了,不是很吃虧嘛。

  2. #2 孫山
    2012年12月24日 周一 17:03 | 回復

    圖片加個 width 屬性吧

  3. #3 XD
    2012年12月24日 周一 19:34 | 回復

    @zhouxinyi
    記得迷惑協議是傳文件用的加密,跟連伺服器關係不大吧,而且國外版權嚴格,很有必要

    文章大好,博主辛苦

  4. #4 Ejack
    2012年12月25日 周二 08:56 | 回復

    @孫山
    已經添加width標籤,應該不會再出現撐破邊框的情況了。
    @XD
    這是篇老文了,以前在ieD2k發的。感謝BB9z搶救的備份。

  5. #5 lyc256
    2013年1月1日 周二 08:57 | 回復

    @zhouxinyi
    設置自動連接靜態伺服器 ,把國內的移除靜態,就能開啟模糊連接到國外的

  6. 2013年1月1日 周二 20:15 | 回復

    把老文章又挖出來了。。

  7. #7 asp502010
    2013年1月19日 周六 09:12 | 回復

    要頂,粗看了幾遍都沒看透,決定認真研究一遍。

  8. #8 rara
    2013年8月16日 周五 15:41 | 回復

    2個不同演算法的client發生數據交互,按誰的規則來?演算法是給自己還是給別人?

  9. #9 reduce
    2013年8月16日 周五 23:04 | 回復

    @rara
    演算法的目的是決定自己上傳的對象,和其他人沒有任何關係
    也就是說,事實上別人是完全不知道你用什麼演算法的,對方只管問你要數據,你通過演算法算出對方有資格了就給對方上傳

發表評論

您的Email將不會顯示出來。頭像請至Gravatar.com註冊上傳。*號標註項為必填。

*
*
*
標籤用法
字數:0