关于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=554000 个！
原来这就是Vagaa所使用的“优秀算法”。
补充：在分析中我还发现，Vagaa似乎对DonkeyServer情有独钟，即使没有连接到DonkeyServer服务器上，也会不停的向它发送数据包。
而且，Vagaa似乎在数据包控制上有缺陷，在相差不到一分钟的时间内，Vagaa向DonkeyServer发送了超过２３０个数据包。
这是一个数据发送控制问题，如此快速（甚至可以说疯狂）的向服务器请求数据，难怪有人会说：“没错，那1％的正在使用那种Mod的DSNO1用户消耗了80％的CPU/带宽”。
