对于Vagaa导致DonkeyServer异常的技术性分析

关于Vagaa给DonkeyServer带来了巨大的负担。而官方的解释却是“Vagaa解决了eMule的先天协议缺点”。那,是什么“优秀算法”解决了“eMule的先天缺陷”呢?

  在本文中,将使用官方版eMule,VeryCD版eMule和Vagaa通过EtherDetect Packet Sniffer软件来做一个网络利用率上的分析。

  首先,我们从官方版的eMule开始,在默认情况下,使用官方版eMule 31分钟后,数据包(TCP应该是连接?)的发送量为49个(62.241.53.2是eDonkeyServer No.1)。嗯,一切正常,看来这是eMule官方的默认设置。

  好的,下面我们来看看VeryCD所开发的eMuleMod。同样在默认配置和同样的计量时间下,使用由VeryCD版的Mod后,数据包的发送量为48个。比官方版的少一个,这应该是属于允许的计量误差范围内。看来VeryCD版的eMuleMod也是严格遵循eMule官方要求的。

  最后,我们要请本次的“主角”Vagaa上场了。同样是默认的设置和计量时间。
  让人惊讶的是,在31分钟的时间内,Vagaa居然向服务器发送了325个数据包!

  不难想象,在相同的时间内,Vagaa比其他“遵纪守法”的eMuleMod多发了6倍的数据包!假设全中国只有1000人在使用Vagaa,那么相比同等用户的普通eMule客户端,在一个小时的时间内,服务器接收到的数据包将会比正常的数据包多:
  Vagaa:325x2x1000=650000
  标准eMule:49x2x1000=98000
  相差:650000-98000=554000 个!

  原来这就是Vagaa所使用的“优秀算法”。

  补充:在分析中我还发现,Vagaa似乎对DonkeyServer情有独钟,即使没有连接到DonkeyServer服务器上,也会不停的向它发送数据包。

  而且,Vagaa似乎在数据包控制上有缺陷,在相差不到一分钟的时间内,Vagaa向DonkeyServer发送了超过230个数据包。

  这是一个数据发送控制问题,如此快速(甚至可以说疯狂)的向服务器请求数据,难怪有人会说:“没错,那1%的正在使用那种Mod的DSNO1用户消耗了80%的CPU/带宽”。

此条目发表在分类目录,贴了, , 标签。将固定链接加入收藏夹。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据