關於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軟體,讓騾子健健康康活下去是非常重要的。

17條評論隱藏

  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基本沒速度,就這樣

發表評論

您的Email將不會顯示出來。頭像請至Gravatar.com註冊上傳。*號標註項為必填。

*
*
*
標籤用法
字數:0