Linux下BT客戶端的設計

摘 要:設計一個Linux下的BitTorent客戶端，具體的實現分為五個大的模塊:B編碼分析模塊，BitTorrent種子分析模塊，BitTorrent客戶端和Tracker服務器通信模塊，BitTorrent客戶端和BitTorrent客戶端間的通信模塊(peer to peer)，運行日志模塊，詳細說明了模塊的架構。

關鍵詞:BitTorrent(BT);內容分發系統

中圖分類號:TP

文獻標識碼:A

文章編號:1672-3198(2010)12-0295-03

1 引言

BitTorrent(簡稱BT)是一個內容分發協議，每個下載者在下載的同時不斷向其他下載者上傳自己已下載的數據。它的特點是下載的人越多下載的速度越快，其原因在于每個下載者將已下載的數據提供給其他下載者下載，它充分利用了用戶的上載帶寬。BT已經發展成為一種主要的互聯網應用。本文嘗試在Linux下設計一個輕量級的BT客戶端軟件，以快速文件傳輸為主要目的。

2 系統模塊功能結構分析

根據BitTorrent協議，文件發布者會根據要發布的文件生成提供一個.torrent文件，即種子文件。.torrent文件本質上是文本文件，包含Tracker信息和文件信息兩部分。Tracker信息主要是BT下載中需要用到的Tracker服務器的地址和針對Tracker服務器的設置，文件信息是根據對目標文件的計算生成的。它的主要原理是需要把提供下載的文件虛擬分成大小相等的塊，塊大小必須為2k的整數次方，并把每個塊的索引信息和Hash驗證碼寫入.torrent文件中，所以，.torrent文件就是被下載文件的“索引”。

下載時，BT客戶端首先解析.torrent文件得到Tracker地址，然后連接Tracker服務器。Tracker服務器回應下載者的請求，提供下載者其他下載者(包括發布者)的IP。下載者再連接其他下載者，根據.torrent文件，兩者分別告知對方自己已經有的塊，然后交換對方所沒有的數據。此時不需要其他服務器參與。

下載者每得到一個塊，需要算出下載塊的Hash驗證碼與.torrent文件中的對比，如果一樣則說明塊正確，不一樣則需要重新下載這個塊。這種規定是為了解決下載內容準確性的問題。

由此可見，在BT客戶端設計中，最主要的部分是:

(1)對種子文件即.torrent文件的內容的解析，以獲知Tracker地址和下載文件信息;

(2)與解析得來的Tracker服務器聯系，獲取其他下載者信息;

(3)與其他下載者互通有無。

其中，“與其他下載者交換數據”的部分又是最為重要的一環，它包含要處理的事務是最多的。除了這三個最主要部分外，還有需要的其他一些功能，比如對程序運行過程中出現的錯誤怎樣處理，程序運行情況的記錄等等。

根據對軟件的總體分析，整個模塊結構如圖1所示。

圖1 系統模塊結構圖

各個模塊的功能如下。

(1)種子解析:主要工作包括對元信息文件的解碼;根據本地數據文件的信息進行bencoding編碼，制作元信息文件。

(2)連接Tracker:根據HTTP協議構造獲取peer地址的請求，與Tracker建立連接，解析Tracker的回應消息，從而獲取各個peer的IP地址和端口號。

(3)與peer交換數據:根據peer的IP地址和端口號連接peer、從peer處下載數據并將已下載的數據上傳給peer。

(4)出錯處理:定義整個系統可能出現的錯誤類型，并對錯誤進行處理。

(5)運行日志:記錄程序運行的日志，并保存到文件中以備查看和分析。

“與peer交換數據”模塊是軟件的核心和主要構成部分，它又可以劃分成如下幾個子模塊。

(1)peer管理:系統為每一個已建立TCP連接的peer構造一個peer結構體。本模塊負責管理由各個peer結點構成的peer鏈表，添加和刪除peer結點。

(2)消息處理:peer與peer之間以發送和接收消息的方式進行通信。本模塊負責根據當前的狀態生成并發送消息，接收并處理消息。

(3)緩沖管理:如果下載完一個piece就立即寫入硬盤，這樣會導致頻繁讀寫硬盤，既影響速度，又不利于保護硬盤。為了解決這個問題，幾乎所有的BT軟件都在程序中增加了一個緩沖管理模塊。將下載到的數據先緩存起來，等到下載到一定量的數據后再集中寫入硬盤。本模塊負責維護一個緩沖區，將下載到的數據保存在緩沖區中，并在適當時刻寫入硬盤的文件中。

(4)位圖管理:BT協議采用位圖指明當前哪些piece已經下載，哪些piece還沒有下載。本模塊負責管理位圖，對位圖的操作主要是創建位圖，設置和獲取位圖某一位的值，保存位圖等。

(5)策略管理:BT協議的設計者為了保證整體性能而制定了許多策略，BT軟件開發者一般都使用這些策略來保證程序的性能。本部分負責策略的管理，主要是計算各個peer的下載和上傳速度，根據下載速度選擇非阻塞peer，采用隨機算法選擇優化非阻塞peer，以及實現片斷選擇策略。

(6)信號處理:在運行過程中，程序可能會接收到一些信號，如SIGINT、SIGTERM，這些信號的默認動作是立即終止程序。這并不是所期望的。在程序終止前需要作一些處理，如釋放動態申請的內存、關閉文件描述符、關閉套接字。

3 系統主要模塊設計

3.1 種子解析模塊的設計

此模塊主要對元信息文件進行Bencoding解碼。當從Web服務器上下載種子文件后，BT客戶端就可以通過分析種子文件然后去訪問Tracker服務器，Tracker服務器將隨機選擇部分參與下載的節點(一般隨機選擇50個節點)作為此請求節點的合作節點，并將這些節點的信息發送給請求節點，新加入節點將同這些合作節點建立連接后便下載或上傳文件片段的編碼塊，并將已解碼的文件片段寫入磁盤文件。當BT客戶端作為種子節點時，它需要根據本地數據文件的信息制作元信息文件，然后發布到Web服務器上，等待其他節點的請求連接，并從本地數據文件中讀取相應的文件片段，然后將編碼之后的編碼塊上傳給相應的合作節點。因此，BT客戶端在其下載或上傳過程中，一直需要對元信息文件進行操作。在BT客戶端獲得.torrent種子文件后做的第一件事就是對此種子文件進行解析，主要任務有:

(1)判斷.torrent文件是否有效;

(2)得到如下的重要信息:tracker服務器列表、文件列表、分塊尺寸、分塊個數、分塊sha1的數組;

(3)其他的一些次要信息如發布者，發布日期，注釋等;

(4)計算infohash。

3.2 位圖管理模塊的設計

位圖指明當前哪些piece已經下載，哪些piece還沒有下載。每個piece占一位，值為0表示該piece還未下載到，為1則表明已經下載到該piece?？蛻舳伺cpeer建立了連接并進行握手之后，即發送位圖給peer告知已下載到哪些piece，同時也接收對方的位圖并將其保存在peer結構體中。每下載到一個piece就更新自己的位圖，并發送have消息給所有已建立連接的peer。每當接收到peer發來的have消息就更新該peer的位圖。

BT客戶端在進行下載或上傳之前，首先把一個文件劃分為若干個固定長度的文件片段(piece)，再把一個文件片段劃分為若干個固定長度的文件塊(Block)，piece位圖中的每一個比特代表了相應的文件片段的下載狀態，初始化時所有比特位為0，每當BT客戶端下載了一個此文件片段的線性無關的編碼塊后，將piece位圖中的相應比特位增1。Piece位圖處理子模塊將目標文件的piece位圖抽象成一個EncodeField類，類的成員函數主要負責為piece位圖開辟一塊內存區域，更新piece位圖中相應位的值，檢查是否已完成目標文件的下載，將piece位圖寫入磁盤文件等等。

3.3 Peer管理模塊的設計

Peer管理模塊負責管理由各個peer結點構成的peer鏈表，主要工作是創建結點，添加結點到peer鏈表，從peer鏈表中刪除結點等。系統為每一個與之建立TCP連接的peer構造一個peer結構體。該結構體的主要成員有:peer的IP地址和端口號、與該peer進行通信的套接字、該peer的ID、當前所處的狀態、發送緩沖區、接收緩沖區、數據請求隊列、數據被請求隊列、從該peer處已下載的數據量和向該peer上傳的數據量、下載速度和上傳速度。

Peer結構是整個程序最重要的數據結構，也是最復雜的數據結構。在這個模塊中首先定義了7種狀態。

Halfshaked(半握手狀態)是指已發送握手消息但未收到對方的握手消息，或者已經接收到對方的握手消息，但己方未發送握手消息。處于Data狀態時雙方可以交換數據，此時peer結構體中的am_choking、am_interested、peer_choking、peer_interested 4個成員變量有效。

當am_interested = 1，peer_choking = 0時，也就是客戶端對peer感興趣，而且peer沒有將客戶端阻塞，此時可以發送數據請求，即發送request消息請求peer發送數據，peer接收到請求后發送piece消息，數據就被封裝在piece消息中。

當peer_interested = 1，am_choking = 0時，也就是peer對客戶端感興趣，而且客戶端沒有將該peer阻塞，此時如果peer發送request消息請求數據，則應該構造并發送piece消息，其中數據被封裝在piece消息中。

“發送unchoke消息”的時機是執行選擇非阻塞peer算法時，選中該peer作為非阻塞peer或者選中該peer作為優化非阻塞peer?！鞍l送choke消息”的時機類似。

“發送have消息，擁有了peer沒有的piece”的含義是己方剛剛下載到一個piece，此時通過發送have消息告知所有peer客戶端已擁有了某個piece，如果peer沒有這個piece且原先peer對本客戶端不感興趣，則發送have消息后，該peer就對該客戶端感興趣了。

3.4 消息處理模塊的設計

peer與peer之間以發送和接收消息的方式進行通信。本模塊負責根據當前的狀態生成并發送消息，接收并處理消息。BitTorrent協議共定義了12種消息，其中對下載和上傳數據最重要的是request消息和piece消息。request消息向peer發送數據請求，指明請求的是哪個piece的哪個slice。Peer接收到request消息后根據當前的狀態，決定是否發送數據給對方。如果允許發送，則構造piece消息，數據被封裝在該消息中。每當下載完一個正確的piece時，就向所有peer發送have消息通告已獲得該piece，其他peer如果沒有該piece就可以向peer發送數據請求，每次請求都是以slice為單位。在消息處理模塊中，定義了如下12種消息:握手消息、keep_alive消息、choke消息、unchoke消息、interested消息、uninterested消息、have消息、bitfield消息、request消息、piece消息、cancel消息、port消息。

本模塊中的消息處理流程見圖2所示。

圖2 消息處理流程圖

3.5 緩沖管理模塊的設計

在緩沖管理模塊的實現中，有個重要的數據結構:Cache鏈表。Cache鏈表的存在是為了提高磁盤性能，降低對磁盤的讀寫次數，缺省大小為16M(大小可調整)。當BT客戶端從本地數據文件中讀數據時，會在Cache鏈表中保存一個復本，如果近期需要上傳同樣的數據時，可以直接從Cache鏈表中讀取數據，不需要再次讀本地數據文件。若緩沖區中不存在所請求的數據，則讀文件并把請求數據所在的piece預先讀入到緩沖區中。同樣，BT客戶端下載了數據并已經正確解碼后，會先將數據寫入Cache鏈表中，當Cache鏈表容量飽和時才寫入本地硬盤數據文件。除了管理緩沖區，本模塊還負責創建待下載的文件，把下載到的piece寫入文件。BT系統既支持單個文件的下載，同時也支持多個文件的下載。上傳和下載文件時，Cache管理流程分別如圖3所示。

圖3 Cache管理流程

每個緩沖區結點的大小為16KB，默認生成1024個結點，總大小為16MB。緩沖區以一個piece(通常為256KB)為基本單位，也就是臨近的16個結點為一組，這16個臨近的結點要么全部被使用要么全部空閑。第1-16個結點存放一個piece，第17-32個結點存放一個piece，依此類推。為了方便處理，所有緩沖區在程序啟動時統一申請，在程序結束時一起被釋放。

3.6 策略管理模塊的設計

計算從各個peer處下載數據的速度是一個棘手的問題。經過分析和對比，現在用的計算下載速度的方法是每10秒計算一次速度。統計最近10秒內從每個peer處下載的數據量，然后除以時間，得到最近這段時間的下載速度，并將下載速度最快的4個peer解除阻塞，允許它們從本客戶端下載，除一個特殊的peer外其他peer將被阻塞。為了發現更快下載速度的peer，任何時刻保證存在一個優化非阻塞peer，將這個peer解除阻塞，而暫時不管從該peer處下載數據的速度，每隔30秒重新進行選擇。在這30秒內，本客戶端提供給該peer較快的下載速度，然后該peer將本客戶端解除阻塞，這樣就可以從該peer處下載數據，并在下次選擇非阻塞peer時，該peer能成為4個非阻塞peer中的一個。

阻塞策略是BT中很重要的一個問題，其優劣直接影響到BT下載的速度。

3.7 連接Tracker模塊的設計

連接Tracker模塊的主要功能是:構造HTTP請求，請求Tracker服務器發送peer的IP地址和端口號;與Tracker建立連接;解析從Tracker返回的數據。Tracker返回的數據是經過B編碼的，解析Tracker的回應和解析種子文件是類似的。根據本地數據文件的信息進行Bencoding編碼，為制作元信息文件子模塊提供編碼功能。從數據類型的角度來看，此子模塊主要是對整數、字符串、列表、字典四種數據類型進行編碼和解碼操作。其工作流程見圖4所示。

圖4 與Tracker的交互

3.8 與peer交換數據模塊的設計

本模塊由多個子模塊構成，主要負責與已建立連接的peer交換數據。除此之外，還調用“連接Tracker”模塊中定義的函數監視各個套接字，以及嘗試與新的peer建立TCP連接。

Peer，抽象表示與BT客戶端建立連接并通信的合作節點，每一個peer，代表著一個合作節點。Peer主要從下載數據的速率、上傳數據的速率、BT客戶端與合作節點連接的狀態、合作節點的piece位圖、通信錯誤次數等角度來描述客戶端與合作節點之間的通信狀態。

至此主要模塊的設計分析完畢，接著就是代碼實現。

參考文獻

[1]吳圣杰.基于Linux限制BitTorrent流量的研究與設計[D].北京:北京化工大學，2007.

[2]李培峰，朱巧明.Linux下支持續傳的多線程下載工具的設計與實現[J].計算機工程與應用，2004，(1).

[3]王楓，羅家融.Linux下多線程Socket通訊的研究與應用[J].計算機工程與應用，2004，(16).

[4]田榮華，盧顯良，侯孟書，王曉斌.P2P分布式存儲系統[J].計算機科學，2007，(6).

[5]郭輝，周敬利，余勝生.基于Linux的HTTP協議實現方案及性能改進的研究[J].計算機工程，2001，(11).

[6]冀志剛，王祥.用JAVA語言實現FTP客戶端[J].唐山師范學院學報，2006，(5).