On ‘Wrong header’ Error during downloading of aMule v2.3.2 and later
在剛剛發布的CN新版，有關aMule v2.3.2及其以後版本在下載中容易因發生’Wrong header’底層錯誤中斷的問題，已經得到有效緩解。本文是為記述解決這一問題的歷程，並談談本人對一些程序開發規則方面的思考。 一、問題回顧 大概早期aMule v2.3.2發布之後一段時間，我就注意到下載時壞塊的情況增加，當時以為是比較爛的改裝版導致的。但後來通過分析verbose log，發現可能是aMule官方客戶端導致的。 一個log的例子如下： 2/1/2021 4:07:55 PM: Client TCP socket: Error: Wrong header; [email protected] (xxx.xxx.xx.xxx) ‘http://www.aMule.org’ (aMule v2.3.2,Downloading/None/None) 這是比較底層的錯誤，是應用程序在處理TCP數據流時，找不到合法的數據頭從而無法繼續的錯誤。這個問題延續到aMule v2.4.0的每日構建版，以及今年剛發布的aMule v2.3.3。 二、初期eMule CN採取的緩解辦法 如果只是下載中斷還好說，但由於數據傳輸錯誤在中斷之前就已經發生，導致下載數據錯誤，出現壞塊。為對付這種壞塊的出現，eMule CN加入了一旦此類嚴重底層錯誤發生，那麼放棄這一問題客戶端此前下載的一些數據的功能，從而有效緩解了這個問題引發的壞塊。 三、終極緩解方案——重寫下載帶寬分配算法 今年3月開始，我用std::list重寫eMule CN的下載帶寬分配算法，得益於std::list的靈活，能夠比較自如地改動、測試各種方法。經過一段時間的調試，速度控制特性穩定下來後，偶然發現在測試極端的一些模式時，「正常」的下載客戶端（即並非aMule v2.3.2及以後版本的客戶端）也可能產生類似的’Wrong header’錯誤。 這個發現給出一些啟示，就是這類錯誤雖然在aMule v2.3.2中引入boost::asio庫處理socket之後出現，應歸屬於該客戶端的問題，但是在本地通過算法調整來緩解，很可能是可以做到的。 接下來的工作就是，如何找出可以令此問題得以極大緩解的算法模式。這是一項非常delicate的任務，經過多次嘗試，終於發現一種算法模式，其中的一個參數能導致問題惡化，也就意味著，反方向對該參數調整，可以找到一個較佳的參數；同時還有其它方面的配合算法調整，最終得到了一個現有的算法，經測試可以避免絕大多數下載時可能的‘Wrong header’錯誤。 四、引發的一些思考 根據一般的開發者遵循的規則，對方客戶端引發的問題，不可能花時間精力去在本地的客戶端開發上去緩解，尤其是aMule客戶端占比並非很高。 那麼這項工作是否值得呢？eMule Community的維護者fox88就認為，不值得！ 但我們另外一個角度上看，不是正是由於aMule v2.3.2及以後版本的這個問題，可以是否觸發它的錯誤作為一項指標，來衡量下載分配算法的錯誤容忍度以及魯棒性嗎？ 至少，以前一看到aMule v2.3.2及以後版本客戶端開始下載就害怕，到現在可以放心地看著來自這些客戶端的下載數據流入，能帶來這樣的心境的改變，對我來說，這個開發所耗費的精力還是值得的。 你們說呢？