关于kMule的访谈

很荣幸邀请到tHeWiZaRdOfDos以及Tuxman两位参与本次由Emule-Mods.it主办的访谈,他们是新客户端kMule的开发者。
首先感谢两位孜孜不倦的宝贵工作,其次要感谢两位欣然接收我们的采访并表现出的深情厚谊。
如果您想更加详细地了解这两位程序员,可以阅读之前的访谈内容:tHeWiZaRdOfDosTuxman

 

1) 可能有人对两位还不熟悉。两位能先介绍一下自己吗?简单说说您在eMule项目的经历。

Tuxman:
嗨,我是Tuxman(也可以简写为“tux”、“tux-”或者“tux.”)。我最初是一名普通的eMule LSD用户,那真是一个美好的时代,后来另一个普通用户提议说“嘿,咱俩试着在Pawcio的基础上做个mod吧”,于是我就走上了开发之路。
对我俩来说,那次经历主要就是积累经验,因为我们之前都没怎么搞过C++。我们的项目始终处于初级阶段,唯一发布一个版本还是在eMule 0.44d新发布的时候。这款mod到现在还能从网上找到,不过现在来看颇令我汗颜。

出于个人原因,从2005年上半年起,我又开始开发eMule Beba。没过多久,我就再也联系不上Beba的最初作者了,不过我还是坚持了下来。首个能比较正常地运行、不会立马崩溃的版本是0.2a。由于(著名的)VipeR mod(Beba的图标便是来自它的)那时停止开发了,人们很快开始喜欢上eMule Beba——因为它小巧轻便,而且每次升级都能得到持续不断地改进。eMule Beba是目前最活跃、传播最广泛的非发布用mod之一。我为此深感自豪。

我开发的另一个mod是AnalyZZUL(这是应eMuleFuture.de的一位用户的要求而开发的),实际上就是ZZUL与Client Analyzer的结合体。不过,由于ZZUL貌似已经停止开发,我也已经停止AnalyZZUL的相关工作。

WiZaRd:
嗨,我的昵称是WiZaRd或者tHe WiZaRd of Dos。我刚开始是个eMule用户,而且还用了一段时间吸血客户端,主要测试各种吸血客户端的各种功能。
某天风和日丽,我瞅了一下吸血客户端的代码,觉得我也可以开始编客户端了——那应该是2000年前后——通过阅读吸血客户端的教程,我获得了充足的关于eMule的基础知识,并开始着手写第一个(吸血)mod——也就是说,这款mod包含一些被官方明令禁止的功能,例如手动踢人、手动封禁等等,不过我可没打过上传/下载比例的主意。
这款mod名为DaRkMaGic,一度非常流行,时至今日也能在网上找到。不过我不会再为其感到那么自豪了。

很长时间里我一直持续开发这款mod的v2版本,也试图通过写教程来帮助其它有心的程序员所遇到的编程问题。我还给几个圈内的大水管写过发布用mod。
不过,过了一段时间,这种在吸血客户端圈内所泛滥的“复制/粘贴”式编程开始让我感到厌烦。你不妨想象一下,有好多人对C++或者编程技巧基本上没什么了解,仅仅是把代码复制粘贴一下就敢编写mod(这种情况持续至今)……更匪夷所思的是,有些这样的mod居然还非常流行?所以,我退出了这个圈子,加入iONix mod的开发团队并呆了好一段时间。刚开始有些人对我的意图抱持怀疑态度(可能直到现在也是),但也有些人给了我第二次机会。
我创建出好几种独特的功能,同时陆续修正了官方代码库中的多处bug。最后,我开发了Client Analyzer功能并且发表了相关的mod(Tombstone / Tombstone Extended)。CA系统是为了帮助用户从许多“稍有”恶意的客户端中甄别出“真正”恶意的客户端。后者是篡改上传/下载比例、下完就跑、只取不予的客户端,前者则是某些发布人员视情况使用了被官方明令禁止的功能。
CA系统遭受了很多的质疑和猜忌,但我觉得CA系统还是找到了它的粉丝、它的用户群,这也是我不需要再打造新版本的Tombstone的原因。

2) 现在已经存在eMule和许许多多的mod了,是什么促使两位开发全新的kMule?

Tuxman:
kMule的思路跟eMule完全不同。我们的想法是做一款只支持Kad的轻便客户端,它不需要过分复杂的GUI界面、不需要太多手动配置,并且能更安静地在后台运行。从“服务器”到“仅Kad”是一条必由之路:服务器实在是问题太多,已经没有理由继续使用了。

WiZaRd:
呃,其实我很久以来就一直打算开发一款简单且用户界面良好的客户端,但是直到2012年年中才有时间着手实施。我邀请tux来帮我干是因为我觉得多人合作的项目搞起来更有意思。我还向另外几位(前)modder发出过邀请,不过那时他们都没时间。我衷心希望他们有时间的话能再考虑考虑!
立项之初,我们将这款客户端命名为ed2kloader。但是为了让我们的客户端与众不同,同时为了凸显出Kademlia是如此优异的网络,我们便将与服务器相关的部分彻底剔除掉了,集中精力打造世界上首款仅Kad网络的客户端。此外,我们还剔除了许多没太大用处的功能和设置,改善了默认配置,等等,这样我们的用户凭默认设置就能用起这款客户端,不需要花几个小时研究各项设置。
kMule的志向是自立门户,而不仅仅是做一款mod。也许目前kMule看起来跟eMule差不多,但这是为了方便eMule用户的切换。

3) 两位能介绍一下kMule客户端的主要特点吗?

Tuxman:
当然。看这个链接就行了:
http://sourceforge.net/p/kmuleproject/code/72/tree/trunk/Mod/main%20features.txt
wink

WiZaRd:
当然。虽然上面我已经列过一些了,不过kMule
*…可以作为aMule用户的另一种选择,因为我们改进了客户端对WINE的支持。
*…是世界上首个仅支持Kad网络的客户端:我们不再依赖于饱受诟病且安全性差的服务器系统了。
*…采用最新的库编译,确保我们的用户不会受到一些老旧的安全问题的威胁。
*…具有(半)自动上传管理系统,可以自动检查版本变化并下载升级包——一旦发生了严重bug,我们甚至可以强制升级以消除过期版本的隐患。
*…能够自动升级各个重要组件(ipfilter、mediainfo、modicons等等)。
*…内置采用CA技术的动态反吸血防护。
*…内置搜索虚假结果检测(采用Netfinity的FakeAlyzer的改进版本)。
*…内置下载虚假文件检测(采用BlueSonicBoy的文件名差异性校验的某个版本)。
*…具有更加清爽简洁的用户界面。
*…对eD2k链接和收藏集进行了改进,使其支持文件夹(这是一个真正重要的功能!)。
*…可针对每个文件夹设置共享权限。
*…可通过7z.dll库实现自动解压。
*…支持SNARL系统,不论何时何地、即刻获取重要提醒。
*…包含ICS(智能文件块选择)、SOTN(仅显示所需文件块)、强力发布以及反HideOS等重要发布功能,确保提高文件发布效率。
*…经细心调校,可找到更多来源。
总而言之,kMule期望成为一款“易上手”的骡子。

4) eMule-project的整个社区对kMule是否持欢迎态度?

Tuxman:
eMule社区对kMule印象深刻,它提供了另一个更有说服力的开发思路,指明了eMule的未来发展方向。

WiZaRd:
eMule-project社区分裂成了两派。一方面,人们喜欢这种仅Kad的形式;另一方面,很多高级用户希望我们把一些功能(例如独立的记录窗口)重新加上。
就我个人看来,总体反应还是良好的,Some Support(注:目前eMule仅剩的开发者)也允许我们把这个客户端发布在eMule-Project.net网站上——虽然我们是想自立门户的,某种程度上将会成为eMule的竞争对手。

5) 两位将来打算对kMule进行哪些方面的改进?预期达到一个什么状况?

Tuxman:
等着瞧、别吃惊,伙计。

WiZaRd:
改进的余地是无处不在的。当然首先我们要力求消除bug和各种不稳定因素。
用户界面将会进一步改进并简化。我也在考虑要不要添加一些NAT-T功能,如果加上的话当然很好,不过目前我没时间进行调研,并且我也不打算在没有完全弄懂的情况下采用其它开发人员的代码,所以目前这部分内容还得搁置——除非Tux愿意搞。
我还打算改善网络的传输速度,以及提高文件(来源)的可用性,尤其是稀有文件。目前eMule面临的最大问题在于:网络中的大多数用户都还在使用eMule官方客户端或者基于官版的mod,而eMule官版是有缺陷的,例如其文件块选择算法、默认上传速度(每个用户3kB/s,这在今天来看简直就是搞笑,不过将来应该会改变的)等等。不管怎样,即便我们对客户端进行一些调整,也不会对网络的现状造成太大影响,除非eD2k中的大部分用户也都采纳这些修改内容。某种程度上来说这可能会导致产生一个独立的kMule Kad网络,不过再看看吧……

6) 很多人对eMule(官版)目前开发停滞的现状感到十分失望。kMule会不会也在几个月或者几年之后面临同样的结局?

Tuxman:
首先,你的提问不成立。所谓“死亡”和“成熟”是有区别的。eMule目前的状态是成熟而不是死亡。没有进行持续开发,是因为没有太多需要增加的东西了。

我们当然希望kMule也达到成熟;不过即使某天我们不再开发kMule了,也并不意味着kMule的消亡——它仍然会被继续使用。
wink 再者说来,我们还是会继续开发kMule的。

WiZaRd:
实际上,对升级的“执念”也是kMule产生的原因之一。今天,如果一个项目不会在每年升级个十次八次的,人们就会以为这个项目完蛋了。这些家伙根本不知道,一个项目开发到一定程度以后,会到达一个相对成熟的阶段,此时就没有太多需要修改/添加的东西了。
kMule也会到达那个阶段的(但愿如此),不过在接下来的几个月里,我们会把许许多多的新想法(遗憾的是时间不够)逐步落实,以期到达那个阶段。

7) kMule是否打算成为一个独立的项目、就像eMule Plus那样?

Tuxman:
总体来说是的。不过eMule Plus可不是一个好例子,这东西连Kad都还没有呢……
wink

WiZaRd:
实际上kMule已经是一个独立的项目了,所以,“是的”。
当然我们也会虚心汲取其它项目的先进理念和经验,如果eMule新版本有良好的变化我们也会跟进——我们可绝对不想变成eMule Plus那样(好久之后才支持Unicode,而且直到现在居然还没有Kad,等等)。

8 ) 你们是否认为kMule已经进入成长阶段,足以成为其它开发人员创建自己项目的基础?

Tuxman:
kMule当然可以为对之感兴趣的程序员提供程序基础。
这对于我所知道的所有mod都成立。我不确定“成长”对于这类决定是否算是重要因素。

WiZaRd:
对于所有版本和mod来说,是的。尽管我不太明白你所说的“成长”是指什么……
我觉得kMule会是一个有趣的代码库基础,因为它功能完善、升级频率高并且开发团队活跃。

9) 你们对NeoLoader怎么看?你们会从NeoLoader吸取一些创新性的点子添加到你们的kMule中吗?

Tuxman:
NeoLoader看起来是个挺有趣的项目,不过目前为止我个人还是持怀疑态度。
其主要开发人员David Xanatos多年来都是eMule社区中非常活跃的开发人员,不过现在他更出名了,因为他持续不断地炮轰eMule。不知出于什么原因,Xanatos将NeoLoader的主要代码都给闭源了,我还不清楚这是为什么。

从技术角度而言(仅从我能看到的代码),NeoLoader可以描述为“支持P2P的jDownloader”,这跟kMule南辕北辙——看起来NeoLoader主要是给下载者而不是分享者使用的。我觉得这不是一个好苗头。

我对NeoLoader比较欣赏的地方是它的插件系统(跟jDownloader一样)。NeoLoader的核心功能模块是自动升级的,无需每次升级都全部重装,这是个非常有趣的想法,好多年前就有人建议eMule这么整了。看看有没有人决定在eMule中实现这个吧。

WiZaRd:
NeoLoader中的确包含许多很好的想法……例如插件系统,例如平台无关性(理论上来说)。不过除了这些,我并没有在NeoLoader中看到称得上“创新性”的东西,除了有些Kad的相关修改。
我不太想把NeoLoader拿来跟kMule或*Mule进行比较。总体而言,eD2k关注于分享,而NeoLoader关注于下载……是的,NeoLoader也有P2P插件,但总体而言它仍然是面向下载者而非共享者的工具。
我过去与David Xanatos共事过,他是一名技术卓越的程序员,但他也是个激进主义者,也就是说他只要有想法就会立即付诸程序。这一方面是好事,可以在相当短的时间内实现很多的功能;但另一方面也容易导致代码混乱和bug泛滥——这跟我的编程理念不太一致。另外我个人绝对不会使用闭源的P2P软件,即使只是部分闭源——这只是个人口味和安全观念使然。

10) 关于eMule(官版),就目前这样新版本难产并且(官方团队)迟迟没有动作的境况,两位愿意接手这个项目来发布新版本吗?

Tuxman:
假如我和/或WiZaRd接手eMule项目的开发,我们对eMule进行的改变毫无疑问将会遭到一些人的反对(kMule走的路线跟以往的mod、例如StulleMule是完全不同的),这样会导致这些人另起炉灶,使得eMule社区四分五裂。——(我的观点是:)假如有人愿意接手eMule项目,那么他自己绝对不能是个modder。只有这样他才能把握住eMule项目的方向而不被(过往的modding经历)影响而偏移。

WiZaRd:
嗯,就像我之前说的:eMule目前已经达到了一个十分成熟的状态,进一步改进的空间很有限。
接手eMule是一件很缥缈的事情……对于Tux、我、我们尝试的方向、以及我们所添加的功能,目前仍然存在很多偏见和敌视——我很质疑(由我们接手官方版本的开发)对eMule是凶是吉。
当然,如果收到邀请,我自然会义不容辞地加入eMule官方开发团队……我仍然认为*Mule是迄今为止最好的P2P软件,让骡子健健康康活下去是非常重要的。

18条评论隐藏

  1. #1 asp502010
    2013年8月2日 周五 08:37 | 回复

    今早才看到,有意思的访谈,感谢Ejack的翻译。

  2. #2 bbdd
    2013年8月2日 周五 09:50 | 回复

    有好多人对C++或者编程技巧基本上没什么了解,仅仅是把代码复制粘贴一下就敢编写mod(这种情况持续至今)……更匪夷所思的是,有些这样的mod居然还非常流行?

    别的不论,这句话我很认同.看过大部分mod代码的人一定会同意.

    很多modder有了什么点子立马就去实现,而在实现的过程中完全不考虑整体以及代码的效率,他们只是急着要看看新点子的效果,然后发现几乎没什么变化就不管了,大堆大堆的臃肿低效充满bug的代码就扔在那了.后来的modder就在这些代码基础上继续这个过程.

    就说很多人在用的刀疤天使,那么迟钝臃肿bug满地的玩意还经常被推崇..只是因为里面的选项比较多么???诸不知那些选项你选和没选在使用上有区别么?好的mod都是精选效果卓著实现高效的功能,并且将这些非常有必要的功能优化后内置,默认.从这个角度来看,X-mod走得方向正确.但是显然该mod的用户很稀少,估计该mod开发者得不到什么正面的反馈已经失去了动力不再继续了,实在是很大的遗憾!

    Kmod一开始还以为是个个人兴趣品,看了这个访谈才对他的开发方向和技术实力有点了解.仅仅是作为对一潭死水顽固僵化的官方进行刺激这个层面来看,我们也应该大力支持才对!

    另外感谢楼主,会独立思考明白emule世界现况的人实在太稀少了.

  3. #3 mon
    2013年8月2日 周五 17:01 | 回复

    字体真大

  4. #4 iizax
    2013年8月3日 周六 01:45 | 回复

    awosome

  5. #5 az13ds2
    2013年8月3日 周六 03:02 | 回复

    scarangel确实bug很多,x mod用起来很顺畅 设置简单 适合一般使用 试用过很多Mod 个人还是觉得x mod最合适国情

  6. 2013年8月3日 周六 23:40 | 回复

    @az13ds2 我也用过,BUG多。现在一直用Xtreme,感觉不错。

  7. #7 tkiller
    2013年8月4日 周日 00:03 | 回复

    emule完全可以改进的更加适合今天的网络,虽然大陆用户很多都是adsl,上传有限,但也可以改进贡献比例算法,强制一定的上传设定,稀有文件分发如何更有效率,如何防止isp对数据流的阻截,是kad更科学也更有效率并减少对骨干网络的影响等等
    在2005~2008年,是emule的黄金时期,呵呵,现在嘛,因为看的基本都是好莱坞的片子,所以要么去国外bt站找种,要么实在找不到就放弃了@

  8. #8 charon0622
    2013年8月5日 周一 22:39 | 回复

    难得现在还能看到这样的文章。话说还有用cn mod的么?

  9. #9 JamesR
    2013年8月6日 周二 17:25 | 回复

    一进来,就按了好多次Ctrl + 0,没反应还以为键盘坏了呢 😀

  10. #10 四足兽
    2013年8月18日 周日 13:49 | 回复

    用kmule自动升级的ipfilter(这里面似乎没有迅雷和QQ离线服务器IP)还是用emulefans制作的ipfilter?
    用UEStudio删掉ipfilter里的注释,emule运行时内存占用明显变少。不知道这会不会造成bug?

  11. #11 四足兽
    2013年8月18日 周日 13:52 | 回复

    作为对强力上传/推送小文件的补充,视频文件最好自动默认最低上传优先级(不管来源多少)。变相加速pdf,doc,chm,exe文件扩散。从全网看,利远大于弊。视频文件大多看完就删,这时强力上传会起相反的作用。

  12. #12 asp502010
    2013年8月18日 周日 16:10 | 回复

    @四足兽
    1、在中国,做到离线服务器IP基本就够用了,这也是最低标准。

    2、注释就是起注释作用喽,不想看就删除,不会出现错误或崩溃的。

    3、电驴网络中影视文件基数与参与交互的骡友数远远大于PDF、doc之类,所以从全网来看,减低影视文件的优先级对加速PDF文件的扩散速度微乎其微。说“视频文件大多看完就删”也比较片面,exe神马的也会有看完就删。最终影视资源依靠强大的基数,保留下载的来源依旧比PDF等文件要多。

  13. #13 tiengulden
    2013年10月24日 周四 17:53 | 回复

    kMule头一回听说,没有用过,没有发言权。不过看了这两位开发者的访谈,俺觉得这种甩开服务器的思路是三个代表、科学发展观和群众路线在eMule-project社区的具体实现,应该大力宣传这种精神!

  14. #14 rsw
    2013年11月20日 周三 08:38 | 回复

    这段时间一直在用,真的不错。很小巧便捷。也很稳定。

  15. #15 jk
    2014年3月9日 周日 12:00 | 回复

    没用过
    用过的说说 看

  16. #16 netr66
    2015年7月2日 周四 21:29 | 回复

    关注并持续使用kMule中,喜欢其设计理念。

  17. #17 无敌稻草人
    2015年7月6日 周一 14:06 | 回复

    @jk 无法屏蔽VC客户端,lowid基本没速度,就这样

  18. #18 netr66
    2020年6月7日 周日 19:11 | 回复

    在目前的网络环境下,回归这个MOD了。。。

发表评论

您的Email将不会显示出来。头像请至Gravatar.com注册上传。*号标注项为必填。

*
*
*
标签用法
字数:0