解决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/带宽”。

作为中国P2P的一员，我们只能督促Vagaa改进现有的“算法”，否则，中国eMule用户被DonkeyServer封杀将指日可待！

－－－－－－－－－－－－－－
投递人:陈少举
这篇文章是我原创的,我放弃此文章的版权,此文章和图片属于公共领域,任何人都可以免费使用,而且可以用于任何合法的目的.
同时,感谢 mmmxxx < cdmmx@hotmail.com > 提供图片.
文章中有一些连接,也还麻烦编辑能否尽量保留.
此文章已经粘贴在我的Blog上: http://www.vnnfans.org/article.asp?id=4 .

本文地址：http://www.45fan.com/a/question/72476.html