本篇博客是《JWebFileTrans(JDownload):一款可以從網路上下載文件的小程式》系列博客的第三篇，本篇博客的內容主要是在前兩篇的基礎上增加多線程的功能。簡言之，本篇博客截止目前所達到的功能是：基於HTTP協議的多線程斷點遠程下載小程式 ...
一 前言
本篇博客是《JWebFileTrans(JDownload):一款可以從網路上下載文件的小程式》系列博客的第三篇，本篇博客的內容主要是在前兩篇的基礎上增加多線程的功能。簡言之，本篇博客截止目前所達到的功能是：基於HTTP協議的多線程斷點遠程下載小程式。在閱讀本篇博客之前，讀者應該先閱讀筆者的前兩篇博客：
自從本系列第二篇博客以來，這個小程式從JWebFileTrans更名為JDownload,以後會增加諸如ftp下載功能等，以學習為目的，也給對網路感興趣的讀者們一個參考。第一篇博客中給出的若幹實驗鏈接現在已經不可用，關於用於實驗的http下載鏈接請參考第二篇博客的說明，截止筆者寫這篇博客，快車官網的http下載鏈接依然有效可以用來做實驗。華中科大的hbase的鏡像站點也可以用來做實驗，但是華中科大的個別hbase鏈接實際上會重定向到真實的下載鏈接，但是本程式目前尚不支持從重定向的鏈接下載文件。此篇博客所述的功能已經更新到github代碼：JDownload鏈接請點我 。如果您覺得JDownlaod源代碼對您有用的話，不妨賞賜作者的github一個小星星star.
PS: 本篇博客是博客園用戶“cs小學生”的原創作品，轉載請註明原作者和原文鏈接，謝謝。
接下來，按照慣例，下一節仍然是功能展示部分。
二 多線程斷點續傳功能演示
本次的實驗平臺依然是vmware player的虛擬ubuntu系統，測試鏈接是http://mirrors.hust.edu.cn/apache/hbase/1.2.5/hbase-1.2.5-src.tar.gz 。
第一張圖是下載過程中的截圖，第二張是下載完畢後的截圖，第三張是hbase下載完畢後解壓後的進入主目錄的截圖。PS：筆者發現要想打開源代碼，需要點擊打開N層目錄，真是別具一格啊，對於docker，基本上也就嵌套一兩層目錄就能找到源代碼。好像Java代碼都是這種風格，目錄下嵌套子目錄，子目錄下再嵌套子目錄，真是子子孫孫無窮盡也啊。
三 基本思路
在前兩篇的基礎上加入多線程的支持其實是相當直觀的，從上一節的第一幅圖就能看出來，有一個.jbp文件，還有四個.jbp0, .jbp1, .jbp2, .jbp3文件，這5個都是記錄斷點信息的文件。另外還有4個.part文件：.part0, .part1, .part2, .part3，這4個.part文件就是目標下載文件被分為了4段來下載，這四段可以由4個線程同時下載。首先說下.jbp文件，這個描述的是一般性信息，主要是目標文件被分為了幾個分段來下載，分片信息，文件大小等等。而.jbp0,1,2,3則記錄的是每一個.part0,1,2,3文件已經下載的情況，比如這個.part文件對應目標文件的起始分片，結束分片，已經下載了多少分片等。關於.jbp文件的具體記錄內容，可以參考源代碼JWebFileTrans.h中的數據結構break_point和break_point_of_part，此處不再贅述。
有了以上信息後，下載過程可以隨時停止，再次啟動下載程式的時候，只需要讀入這些斷點文件，進行簡要的分析，就可以繼續下載。當然4個.part文件不一定非得4個線程來下載，兩個線程也行，每一個線程下載其中的兩個分段，這體現出一定的靈活性，也就是說每一次下載啟動的線程數是可以靈活調整的。下載完畢後，需要有一個合併函數來把這些.part文件合併成一個文件，並且刪除所有斷點文件，以及不需要的.part文件。
有一個問題需要註意，在此種方案下，分part多線程下載的內容寫入到對應的part的時候，offset要設置好。比如之前單線程下載的時候，下載目標文件的第[m,n]個區間，則寫入本地文件也要寫入[m,n]區間，而多線程分段下載後，下載目標文件的區間[m,n]寫入到對應的.partn裡面就不一定是[m,n]了，要做一定的修正。由於思維慣性，筆者就犯了這個錯誤，導致調試了很長時間。
還有一個需要註意的點是，在更新斷點文件的時候最好fflush一下，否則下載異常退出後，斷點文件沒有正確保存到磁碟，下次再運行的時候可能會出錯。
多線程部分使用的是pthread線程庫，關於如何使用pthread,讀者可以參見網上的大量教程，此處也不再贅述。另外最好每一個線程創建一個自己的socket fd,最好不要所有線程共用一個socket fd,那樣的話如果其中一個線程把socket fd關閉了，而另一個線程還在使用這個socket fd跟服務端請求數據，則就會出錯。筆者在更新代碼的時候也犯了這個錯誤，也花費了一些調試時間找出原因。
四 一點小的改進
筆者後來用不同的線程數量來測試的時候，發現一個很不美觀的問題，隨著線程數目的增加，本地下載目錄里會產生大量的.jbp 和.part文件，一大堆東西亂轟轟的，很不美觀。於是就想著儘量減少斷點文件和.part文件的數量，那就把所有斷點文件合併到一個文件里吧，所有的.part文件也合併到一個文件里吧。在多線程環境下，這麼做安不安全呢？實際上是安全的，大家想一下，每一個線程下載的那段.part文件在目標文件中的區間與其他線程都是不同的，並不會產生衝突，可以並行的寫入。比如線程1想要寫入區間[m,n],那就用fseek把文件指針移動到偏移量m處，線程2想要寫入區間[x,y]，就移動文件指針到偏移量x處，然後寫入。而由程式的邏輯可知，區間[m,n]和區間[x,y]是沒有交集的。這樣不僅解決了美觀的問題，而且也省去了合併.part文件的步驟，提高了效率。改進後的下載功能演示如下，此次用的是快車下載鏈接來測試的：
五 多線程環境下的斷點功能演示
上一節經過改進後的演示截圖，這裡演示一下多線程環境下的斷點功能。截圖如下：
由截圖可以看出，在下載過程中筆者兩次中斷了下載，在第一個中斷後重新下載時，程式提示part 0,1,3,4已經下載完畢，這個是在中斷前的那一步驟中下載完畢的，在讀入斷點文件解析後發現並列印出來的。在第二次中斷後再次執行的時候，提示part1,2,3,4,0已經下載完畢，說明在第二次中斷前part 2被下載完畢。最後直到shell提示downlaod success, download complete，則全部下載完畢。下載完畢的快車運行截圖，這裡就不在演示了，筆者可以自行測試之。
六 一些調試問題
之前在寫博客的時候，調試代碼方面也遇到了挺多問題，但是都沒有被記錄下來，打算未來把遇到的問題都記錄一下，來提醒自己。本次遇到的問題如下：
- 指針的分離導致malloc失敗。有時候一個指針在其中一個函數裡面定義，經過重重傳遞到達另一個函數，再加上代碼數量比較多，有時候會忘記這個指針其實不是malloc分配而來的，這個時候free它，肯定是會出錯的。
- fopen文件太多導致的錯誤。這個具體是在哪個步驟導致的，我現在已經記不太清楚了，看來還是好記性不如爛筆頭啊
- 前文提到的每一個.part文件保存時偏移量的修正問題，當然改進後，這個問題就不存在了
- 文件分片餘數問題。文件不一定被分片整除，因此會有餘數，筆者之前下載文件老是失敗，經過調試，發現每一次下載的文件都少了一部分，進一步分析這個少的部分就是這個餘數的大小，於是迅速定位解決了問題。
還有一個很難重現的問題，只出現過一次：有一天晚上筆者又拿JDownlaod下載快車來測試，卻發現程式老是提示http_recv_file, bad file descriptor,由於筆者的程式在列印錯誤信息的時候會帶上出錯的函數名字，因此一下就定位到http_recv_file這個函數，經查明是http_recv_file這個函數里調用send函數失敗導致的，網上查了下，說原因可能是：It could be that you are closing the client socket before the thread，gets a chance to run, or it could be that your thread is improperly setup. 但是我的代碼里每一個線程有自己的socket fd，不會被其他線程影響到啊。於是只能暫時在調用send的時候加上一個while迴圈，如果出錯，就多試幾次，測試截圖如下：
從上圖可以看出，在下載過程中提示了好幾次Http_recv_file,close in first send:Bad file descriptor。但是由於筆者更新了代碼，加上了while迴圈，從截圖看出，在失敗了幾次後終於成功了。但是之後筆者再次測試想要查明具體原因時，這個錯誤再也沒有出現過。之前問題是出現在下載快車軟體的時候，線程多到一定程度就會出現這個問題，與此同時，從華中科大下載hbase，同樣的線程數目，卻不會出現問題。這個只好留到以後，錯誤再次重現的時候再查明具體原因了。另外還有一個現象就是，如果出現了上述錯誤，然後筆者中斷下載，再次通過斷點續傳的話，很快就能下載完畢。而如果一直等待不採用斷點的方式重新下載，雖然可以成功，但卻花費更長的時間。
七 一個有意思的現象
在分別從快車官網、華中科大鏡像下載的時候，通過top命令，看到前者cpu占用率基本維持在0.9%左右，而後者基本維持在5%左右。這應該是後者網路通暢，使得JDownload大部分時間有事情做，而前者由於網路不是太通暢，導致大部分時間沒有數據需要處理，從而不需要占用太多的cpu資源。有時候JDownload會從top命令裡面消失，這應該是由於網路太不通暢了，導致send,或者recv調用被阻塞，從而程式被linux內核從調度隊列裡面暫時移除了。另外測試的時候最好用可執行文件的下載鏈接來測試，這樣可以通過運行它來確定下載的是正確的文件，而有些壓縮文件，即使最後少下載了一部分，但是也能解壓看到其他文件，這個時候就不利於判斷程式寫的是否正確。
具體的代碼實現，請讀者移步筆者的github鏈接吧，鏈接在前言中。
八 結束語
至此本文就結束了，總結來說，就是在單線程斷點續傳的功能基礎上，加上了多線程的功能。目前只支持從http站點下載，未來可能還會加入ftp的支持，如果您對此有興趣的話，請繼續關註筆者博客的動態。
聯繫方式：https://github.com/junhuster/
