關於Vagaa給DonkeyServer帶來了巨大負擔
 

關於Vagaa給DonkeyServer帶來了巨大負擔

關於Vagaa給DonkeyServer帶來了巨大的負擔。而官方的解釋卻是「Vagaa解決了eMule的先天協議缺點」。那，是什麼「優秀算法」解決了「eMule的先天缺陷」呢？

　　在本文中，將使用官方版eMule，VeryCD版eMule和Vagaa通過EtherDetect Packet Sniffer軟件來做一個網路利用率上的分析。

　　首先，我們從官方版的eMule開始，在預定情況下，使用官方版eMule ３１分鐘後，資料包（ＴＣＰ應該是連接？）的發送量為４９個（62.241.53.2是eDonkeyServer No.1）。嗯，一切正常，看來這是eMule官方的預定設置。


　　好的，下面我們來看看VeryCD所開發的eMuleMod。同樣在預定配置和同樣的計量時間下，使用由VeryCD版的Mod後，資料包的發送量為４８個。比官方版的少一個，這應該是屬於允許的計量誤差範圍內。看來VeryCD版的eMuleMod也是嚴格遵循eMule官方要求的。


　　最後，我們要請本次的「主角」Vagaa上場了。同樣是預定的設置和計量時間。
　　讓人驚訝的是，在３１分鐘的時間內，Vagaa居然向服務器發送了３２５個資料包！


　　不難想像，在相同的時間內，Vagaa比其他「遵紀守法」的eMuleMod多發了６倍的資料包！假設全中國只有１０００人在使用Vagaa，那麼相比同等用戶的普通eMule客戶端，在一個小時的時間內，服務器接收到的資料包將會比正常的資料包多：
　　Vagaa：325x2x1000=650000
　　標準eMule：49x2x1000=98000
　　相差：650000-98000=552000 個！

　　原來這就是Vagaa所使用的「優秀算法」。

　　補充：在分析中我還發現，Vagaa似乎對DonkeyServer情有獨鍾，即使沒有連接到DonkeyServer服務器上，也會不停的向它發送資料包。

　　而且，Vagaa似乎在資料包控制上有缺陷，在相差不到一分鐘的時間內，Vagaa向DonkeyServer發送了超過２３０個資料包。


　　這是一個資料發送控制問題，如此快速（甚至可以說瘋狂）的向服務器請求資料，難怪有人會說：「沒錯，那1％的正在使用那種Mod的DSNO1用戶消耗了80％的CPU/帶寬」。

本文已同步發表在： CnBeta 上。