關于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/帶寬 ”。

　　作為中國P2P的一員，我們只能督促Vagaa改進現有的“算法”，否則，中國eMule用戶被DonkeyServer封殺將指日可待！

－－－－－－－－－－－－－－
投遞人:陳少舉
這篇文章是我原創的,我放棄此文章的版權,此文章和圖片屬于公共領域,任何人都可以免費使用,而且可以用于任何合法的目的.
同時,感謝 mmmxxx < cdmmx@hotmail.com > 提供圖片.
文章中有一些連接,也還麻煩編輯能否盡量保留.
此文章已經粘貼在我的Blog上: http://www.vnnfans.org/article.asp?id=4 .

對于Vagaa導致DonkeyServer異常的簡單技術性分析