專利名稱:基于Bittorrent協(xié)議下載文件的系統(tǒng)的制作方法
技術領域:
本發(fā)明涉及在網(wǎng)絡中進行文件傳輸?shù)募夹g。
背景技術:
隨著計算機和網(wǎng)絡技術的發(fā)展,人們越來越多地從網(wǎng)絡中獲取需要的信息文件, 這種便利的獲取信息的方式極大地提高了人們生活、工作的效率。從網(wǎng)絡中獲取信息 文件的方式常采用客戶端/服務器(c/s)模式,例如從網(wǎng)站上下載所需要的信息文件。 現(xiàn)在的信息文件,特別是多媒體文件日益龐大,這使得在c/s模式下獲得信息文件的
效率越來越低,主要原因在于客戶端發(fā)出下載請求都集中于服務器,使得服務器的處 理能力和網(wǎng)絡帶寬隨著客戶端數(shù)量的增加很快被消耗殆盡。這導致客戶端下載速度變 得緩慢, 一個比較大的文件需要下載幾個甚至幾十個小時。
以目前的硬件技術還不能在低成本的前提下大幅度提高服務器的處理能力和網(wǎng)絡
帶寬,這就需要人們尋求其他方法來提高文件傳輸速度?;贐ittorrent (簡稱為BT) 協(xié)議或電驢協(xié)議等以對等網(wǎng)為基礎的P2P (Peer to Peer)模式是解決上述問題的一種方 式。在P2P(PeertoPeer)模式中,用戶之間是對等關系,每個用戶既為他人提供資源, 也從他人那里下載需要的資源,每個用戶端既是服務器也是客戶端。P2P能更好的充 分利用每個客戶端的資源,能夠解決FTP或HTTP等C/S模式下由于資源集中且承擔 了客戶端過多的服務而引起的服務器帶寬和處理請求能力方面的瓶頸問題,從而下載 速度得以大大提高。
目前,網(wǎng)絡中大量文件存儲在FTP或HTTP服務器上,造成這種狀況的主要原因 在于FTP協(xié)議和HTTP協(xié)議具有更長的歷史,但現(xiàn)階段Bittorrent協(xié)議模式并不能直接 支持FTP或HTTP協(xié)議下的文件的下載,這就使得在Bittorrent協(xié)議下網(wǎng)絡中很大一部 分資源不能夠被利用。因此需要采取措施將FTP或HTTP服務器等服務器資源引入到 Bittorrent協(xié)議模式中。
發(fā)明內(nèi)容
為了實現(xiàn)將FTP或HTTP服務器等服務器資源引入到Bittorrent協(xié)議模式中的目 的,本發(fā)明提供了一種基于Bittorrent協(xié)議下載文件的系統(tǒng)。 本發(fā)明的技術方案如下
基于Bittorrent協(xié)議下載文件的系統(tǒng),包括按照Bittorrent協(xié)議設置的網(wǎng)絡,還包括 連接于所述網(wǎng)絡中的網(wǎng)絡節(jié)點,網(wǎng)絡節(jié)點包括普通節(jié)點、分布設置于網(wǎng)絡中的DHT節(jié)點,普通節(jié)點上設置有下載請求模塊和普通上傳模塊,下載請求模塊用于向所述網(wǎng)絡 節(jié)點發(fā)出下載文件分塊單位的請求,普通上傳模塊用于接收其他普通節(jié)點發(fā)來的下載 請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位,網(wǎng)絡節(jié)點還包括服務器節(jié)點, 服務器節(jié)點上設置有服務器上傳模塊,服務器上傳模塊執(zhí)行以下步驟接收普通節(jié)點 發(fā)來的下載請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位;DHT節(jié)點上設置信 息保存模塊記錄普通節(jié)點具有的可供下載的文件,所述網(wǎng)絡中至少有部分DHT節(jié)點的 信息保存模塊記錄服務器節(jié)點具有的可供下載的文件的信息,信息保存模塊響應普通 節(jié)點的査詢請求向發(fā)出查詢請求的普通節(jié)點傳遞記錄的信息。 所述服務器節(jié)點為FTP服務器或HTTP服務器。
普通節(jié)點上還設置有分塊驗證模塊,分塊驗證模塊對下載到的文件分塊單位進行 驗證,執(zhí)行如下功能如果文件分塊單位來自服務器節(jié)點,則對此文件分塊單位進行 哈希運算,得到的值為文件分塊單位驗證碼;如果文件分塊單位來自普通節(jié)點,則同 時請求得到該文件分塊單位的文件分塊單位驗證碼,若對文件分塊單位進行哈希運算 得到的結果與該文件分塊單位的文件分塊單位驗證碼一致則保留該文件分塊單位和文 件分塊單位驗證碼。
普通節(jié)點在向其他普通節(jié)點發(fā)出的Bittorent握手包中設置一對Bi加rent消息以傳 輸所述驗證碼
請求驗證碼<len = 5><id = 140><piece index>; 回復驗證碼<len = 25><id = 141〉<piece index〉〈hash value〉。
分塊驗證模塊還執(zhí)行如下功能如果對來自普通節(jié)點的文件分塊單位進行哈希運 算的結果與該文件分塊單位的文件分塊單位驗證碼不一致,則記錄發(fā)送該文件分塊單 位的普通節(jié)點發(fā)生一次錯誤,如果某個普通節(jié)點累計發(fā)生錯誤數(shù)達到預定值,則不再 向該普通節(jié)點發(fā)出下載文件分塊單位的請求。
下載請求模塊從服務器節(jié)點獲取要下載文件的大小,特征碼為文件在網(wǎng)絡中唯一
標識,根據(jù)該特征碼向DHT節(jié)點查詢獲取所記錄的信息,根據(jù)獲取到的所述記錄的信 息向具有或部分具有該下載文件的網(wǎng)絡節(jié)點發(fā)出下載請求,所述特征碼為以下兩者之 一如果在服務器節(jié)點的URL地址中提供了文件哈希值,則使用此文件哈希值作為特 征碼;否則,文件在服務器節(jié)點上的URL地址經(jīng)哈希運算得到的哈希值作為特征碼。
DHT節(jié)點可以在物理上與普通節(jié)點合并設置在同一設備上,即信息保存模塊設置 于普通節(jié)點上,這樣可以不必為DHT節(jié)點單獨設置硬件設備,DHT節(jié)點與普通節(jié)點 共享硬件資源,節(jié)約了成本。
信息保存模塊以一定周期更新所記錄的信息。
信息保存模塊還對應所述特征碼保存文件哈希值;信息保存模塊應普通節(jié)點的請 求提供記錄的信息。
信息保存模塊還對應文件哈希值記錄具有該文件的服務器節(jié)點地址,普通節(jié)點可
以根據(jù)特征碼査詢到文件哈希值,進而查詢到具有該文件的服務器節(jié)點地址和普通節(jié)
點列表;對應特征碼沒有文件哈希值時,普通節(jié)點下載完文件后計算出文件哈希值并傳給信息保存模塊,信息保存模塊將該特征碼與該文件哈希值對應記錄。 本發(fā)明的技術效果
本發(fā)明的基于Bittorrent協(xié)議下載文件的系統(tǒng)將具有豐富文件內(nèi)容的FTP、 HTTP 等服務器作為網(wǎng)絡中特殊的節(jié)點(主要供普通節(jié)點下載內(nèi)容),從而將FTP或HTTP服 務器等服務器資源引入到Bittorrent協(xié)議模式中, 一方面使得在Bittorrent協(xié)議模式下可 以充分利用現(xiàn)有網(wǎng)絡中的資源,另一方面,加快了普通節(jié)點從FTP、 HTTP等服務器上 下載文件的速度,并減輕了服務器的壓力。對現(xiàn)有的FTP、 HTTP等服務器不需要進行 改造即可以實現(xiàn)本發(fā)明的目的,因此成本低廉。
圖1是本發(fā)明基于Bittorrent協(xié)議下載文件的系統(tǒng)的網(wǎng)絡結構圖; 圖2是普通節(jié)點下載請求模塊的流程圖; 圖3是普通節(jié)點上分塊驗證模塊流程圖4是獲得一個錯誤文件分塊單位受普通節(jié)點上分塊驗證模塊的處理流程。 圖中標記列示如下
1、服務器節(jié)點;2、普通節(jié)點;3、 DHT節(jié)點。
具體實施例方式
下面結合附圖對本發(fā)明的技術方案進行詳細說明。
如圖1所示,基于BT協(xié)議下載文件的系統(tǒng)的網(wǎng)絡節(jié)點(服務器節(jié)點l、普通節(jié)點 2和DHT節(jié)點3)通過網(wǎng)絡連接,連接而成的網(wǎng)絡符合BT協(xié)議規(guī)范。服務器節(jié)點1 上設置有服務器上傳模塊,服務器上傳模塊的主要作用在于響應網(wǎng)絡中普通節(jié)點的下 載請求并向該普通節(jié)點傳遞(上傳)請求的文件(具體的是文件的分塊單位,即將一 個文件分割成大小均等的文件塊,以利于在網(wǎng)絡傳輸速度有限的條件下可以有效傳遞 這些文件塊,再將文件塊合并成文件,獲得文件的整體)。服務器節(jié)點1可以是FTP服 務器或HTTP服務器等可以響應下載文件請求的服務器。由于現(xiàn)有的網(wǎng)絡中FTP服務 器和HTTP服務器保有量大,其上存有大量的文件,是內(nèi)容豐富的下載源,本發(fā)明將 BT協(xié)議和客戶端/服務器模式的優(yōu)點結合,可以使普通節(jié)點2獲得更多的文件。
DHT節(jié)點3采用分布式哈希表(Distributed Hash Table, DHT)技術分布式的存儲
具有特定文件的網(wǎng)絡節(jié)點信息,即文件的信息(如文件的特征碼)、正在下載此文件的
網(wǎng)絡節(jié)點列表等都分布式的存儲在DHT節(jié)點3上,當普通節(jié)點2需要査找具有某文件
的網(wǎng)絡節(jié)點列表,則通過向DHT節(jié)點構成的DHT網(wǎng)絡發(fā)起査詢(具體查詢的規(guī)則可
以依據(jù)現(xiàn)有的分布式哈希表技術規(guī)范),DHT網(wǎng)絡返回上述列表等記錄的信息后,根據(jù)
獲得的上述列表,普通節(jié)點2與列表中所列的網(wǎng)絡節(jié)點建立連接并進行下載文件。DHT
節(jié)點3上設置的信息保存模塊記錄正在下載特定文件的普通節(jié)點、具有該特定文件的
服務器節(jié)點和文件的哈希值,將這些信息形成所述列表。信息保存模塊周期性地更新
記錄的信息,也可以在記錄的信息發(fā)生變化時即時更新。普通節(jié)點2向DHT節(jié)點發(fā)3出請求后,DHT節(jié)點3將相應的列表內(nèi)容反饋給該普通節(jié)點2。采用DHT技術可以避 免列表信息集中于有限的幾個節(jié)點,當網(wǎng)絡受到攻擊時當這幾個節(jié)點失效后就會導致 整個網(wǎng)絡不能工作。DHT技術將列表分散于網(wǎng)絡中,承受攻擊的能力強。另外,由于 不必將列表集中設置于服務器,因此避免增加服務器的相關成本。
普通節(jié)點2是下載和使用文件的主體,能夠向其他網(wǎng)絡節(jié)點發(fā)出請求下載文件, 也能夠響應其他網(wǎng)絡節(jié)點的請求提供文件。在普通節(jié)點2上設置有下載請求模塊和普 通上傳模塊。下載請求模塊向其他網(wǎng)絡節(jié)點發(fā)出下載文件的請求并獲得文件,普通上 傳模塊響應其他普通節(jié)點的下載請求上傳(提供)相應文件。在本發(fā)明的系統(tǒng)中識別 特定文件的標識為特征碼,特征碼有以下兩種產(chǎn)生方法如果在URL地址中提供了文 件哈希值(如ED2K地址,ED2K鏈接是一個特別的鏈接格式,包含文件名、文件大 小、文件哈希值等),則使用此文件哈希值作為特征碼;否則,將文件在服務器節(jié)點上 的URL地址經(jīng)哈希運算得到的哈希值作為特征碼。DHT節(jié)點3可以在物理上與普通節(jié) 點2合并設置,即信息保存模塊設置于普通節(jié)點2上,這樣可以不必為DHT節(jié)點3單 獨設置硬件設備,DHT節(jié)點3與普通節(jié)點2共享硬件資源,節(jié)約了成本。
圖2是普通節(jié)點上設置的下載請求模塊的工作流程。普通節(jié)點首先向服務器節(jié)點 發(fā)出請求,獲得需要下載文件的大小,計算或提取該文件的特征碼。對于FTP服務器 使用Size Filepath可以得到文件大?。欢鳫TTP協(xié)議中有content-length字段,可以直 接得到文件大小。特征碼根據(jù)該文件在服務器節(jié)點上的地址獲得如果URL地址中提 供了文件哈希值,則直接取出其中的文件哈希值作為特征碼;否則則對該URL地址進 行Hash運算,得到的哈希(Hash)值作為該文件的特征碼。
其次,普通節(jié)點得到上述的特征碼后,依據(jù)DHT網(wǎng)絡的查詢規(guī)則向DHT節(jié)點(即 信息保存模塊)發(fā)出查詢請求,獲得可以提供此文件或此文件的分塊單位的網(wǎng)絡節(jié)點 列表。如果DHT網(wǎng)絡中存在正在下載此文件的用戶,則DHT網(wǎng)絡返回用戶列表,如 果DHT網(wǎng)絡返回普通節(jié)點列表,則根據(jù)已有的特征碼信息生成握手包,向普通節(jié)點列 表中的普通節(jié)點發(fā)出Bittorrent連接握手包,使用特征碼作為Bittorrent握手包中的哈希 值,握手時必須對特征碼進行比對,完全匹配才允許握手成功。如握手成功,對方即 返回它擁有的已下載和未下載的文件分塊單位的信息,根據(jù)此信息可以向?qū)Ψ桨l(fā)出數(shù) 據(jù)請求。不斷嘗試連接其他普通節(jié)點,則可以得到網(wǎng)絡中所有能連接到的普通節(jié)點的 具有的文件分塊單位信息,對所有的這些信息進行"或"運算,可以得到所有普通節(jié) 點具有的文件分塊單位的合集,據(jù)此可以判斷,所需下載的文件是否已經(jīng)完整地存在 于網(wǎng)絡的普通節(jié)點中。如不完整,則向服務器節(jié)點發(fā)出請求。
如果網(wǎng)絡中不存在任何正在下載此文件普通節(jié)點,則DHT網(wǎng)絡不能返回普通節(jié)點 列表。此意味著本普通節(jié)點為下載此文件的第一個用戶。將特征碼和本普通節(jié)點的IP 地址信息等保存在DHT網(wǎng)絡中(即信息保存程序模塊),再從服務器節(jié)點下載該文件 數(shù)據(jù)。
在實際應用中可能會發(fā)生這樣的情況如果特征碼是根據(jù)文件的鏈接地址確定的, 在網(wǎng)絡中如果文件相同,只是鏈接地址不同,僅根據(jù)特征碼發(fā)出下載請求的話,只能一個服務器節(jié)點作為源頭提供的文件),即使其他 服務器節(jié)點具有該文件,也不能發(fā)出下載請求,這無形中浪費了資源。為了解決這一 問題,在DHT節(jié)點上的信息保存模塊保存如下兩種格式的數(shù)據(jù)
1) 、以由鏈接地址計算得到的特征碼作為關鍵字,保存文件哈希值、普通節(jié)點列 表,即保存該特征碼對應的文件的哈希值和己經(jīng)下載該特征碼代表的特定地址的文件 的普通節(jié)點列表。文件的哈希值是指對整個文件進行哈希運算后得到的結果。
2) 、以文件哈希值作為關鍵字,保存具有該哈希值代表的文件的普通節(jié)點列表、 服務器節(jié)點列表。
普通節(jié)點在得到經(jīng)鏈接地址計算得到的特征碼后,向DHT節(jié)點(即信息保存模塊, 適用于獨立設置DHT節(jié)點和DHT節(jié)點與普通節(jié)點物理上合并設置兩種情況,以下同) 發(fā)出查詢,查詢結果可能返回上述列表和文件哈希值,將返回的網(wǎng)絡節(jié)點列表加入到 自己可以連接的網(wǎng)絡節(jié)點列表中。如果返回了文件哈希值,再以文件哈希值作為特征 碼向DHT節(jié)點發(fā)出查詢,返回得到普通節(jié)點和服務器節(jié)點加入到自己可以連接的網(wǎng)絡 節(jié)點列表中。
普通節(jié)點下載完該文件后計算出文件哈希值,并按上述格式上傳給信息保存模塊 保留,這樣當下次再有普通節(jié)點下載此文件時,就可以根據(jù)鏈接地址查詢到文件哈希 值,并根據(jù)文件哈希值查詢到具有此相同文件的所有普通節(jié)點和服務器節(jié)點,使得整 個文件下載系統(tǒng)的效率更高。這樣信息保存模塊就可以不斷增加信息,類似于通過學 習不斷增加知識。
第三,根據(jù)返回的網(wǎng)絡節(jié)點列表,與這些網(wǎng)絡節(jié)點建立連接,發(fā)出下載請求。如 果反饋的結果表明沒有普通節(jié)點正在下載該文件,則向服務器節(jié)點發(fā)出下載請求,獲 取文件,同時在DHT的信息保存模塊中記錄該文件的文件哈希值及自身普通節(jié)點的IP 地址信息。
普通節(jié)點上還設置有分塊驗證模塊,用于對獲得的文件分塊單位進行驗證,避免 獲得錯誤的文件分塊單位。圖3為分塊驗證模塊的流程圖。
每個文件分塊單位都有對應的驗證碼,普通節(jié)點獲得驗證碼的來源有如下三種方
式
1、 如果下載的文件分塊單位來自服務器節(jié)點,則得到全部文件分塊單位后對其進 行哈希運算,得到的哈希值作為該文件分塊單位的驗證碼;
2、 如果存在相應的種子文件,則從種子文件中獲得該文件分塊單位的驗證碼。
3、 如果不存在相應的種子文件,且下載的文件分塊單位來自在DHT上查詢到的 普通節(jié)點,則向普通節(jié)點請求驗證碼。在向其他普通節(jié)點發(fā)出的Bittorent握手包中設 置一對Bittorent消息以傳輸所述驗證碼
請求驗證碼<len = 5><id = 140><piece index〉; 回復驗證碼<len = 25><id = 141><piece index><hash value>。 在上述格式中,第一個字段len為4個字節(jié)的整型,指明本消息的長度,它等于以 字節(jié)為單位,除len之外的其它字段的長度和。對于請求哈希驗證碼,它的值為1+4=5,對于回復哈希驗證碼,它的值為1+4+20=25。第二個字段為1個字節(jié),指明本消息的 類型,值分別為140和141。第三個字段均為本次消息的所使用的分塊序號。對于回復 哈希驗證碼消息,第四個字段為分塊序號對應的驗證碼。 分塊驗證模塊執(zhí)行如下步驟-
首先判斷獲得的文件分塊單位是否來自于服務器節(jié)點,如果是來自于服務器節(jié)點, 則對該文件分塊單位進行哈希運算得到驗證碼,對于從服務器節(jié)點獲得的文件分塊單 位認為是正確的,直接保存文件分塊單位和驗證碼,無須對該文件分塊單位進行驗證。
其次,如果文件分塊單位來自于其他普通節(jié)點,則從該普通節(jié)點或種子文件獲得 其驗證碼,對該文件分塊單位進行哈希運算,得到的哈希值與驗證碼進行對比,如果 一致,則該文件分塊單位是正確的;如果不一致則該文件分塊單位是錯誤的。
如果文件分塊單位是正確的,保存文件分塊單位及驗證碼。
如果文件分塊單位是錯誤的,重新發(fā)出對該文件分塊單位的下載請求。重新發(fā)出 下載請求按如下方式進行
對于每個文件分塊單位,均記錄該文件分塊單位由哪個普通節(jié)點提供的。在普通 節(jié)點上設置有錯誤計數(shù)器,記錄得到錯誤文件分塊單位的次數(shù)及對應的普通節(jié)點。
如果記錄的某個普通節(jié)點發(fā)送錯誤文件分塊單位的次數(shù)累計達到預定的值,即可 認為該普通節(jié)點為非正常節(jié)點,通知下載模塊不再向該普通節(jié)點發(fā)送下載請求,即列 入黑名單,這樣能有效防止他人通過不斷地發(fā)錯誤數(shù)據(jù)來對系統(tǒng)進行攻擊。
在本實施例中需要考慮文件分塊單位分級的情況,這種情況在BT協(xié)議中有規(guī)定, 如每個文件分塊單位大小為256K,每個塊由16個分片組成,每個分片的大小為16K。 下載單位為分片,即可以以16K大小的分片為單位進行下載;驗證單位為文件分塊單 位, 一旦開始對一個新的文件分塊單位的請求,則必須將整個文件分塊單位的數(shù)據(jù)全 部下載完成,以方便向連接自己的其他網(wǎng)絡節(jié)點報告"擁有"了此文件分塊單位。文 件分塊單位大小也可以根據(jù)BT協(xié)議規(guī)范中的種子文件規(guī)定。針對這種情況,分塊驗證 模塊執(zhí)行的步驟進一步細化如下(見圖4所示流程圖)
在下載時記錄下每個文件分塊單位的每個分片分別來自哪個普通節(jié)點,當驗證文 件分塊單位為錯誤時,此時并不立即丟棄此錯誤數(shù)據(jù)分塊。如果服務器節(jié)點具有該正
在下載的文件,則向服務器節(jié)點請求并下載該文件分塊單位,保存文件分塊單位和驗 證碼。將從服務器節(jié)點得到的文件分塊單位與剛被驗證發(fā)生錯誤的文件分塊單位對比, 得知哪一個或哪幾個分片發(fā)生錯誤,在錯誤計數(shù)器中為提供該分片的普通節(jié)點累計一 次或幾次錯誤, 一個錯誤分片對應累計一次錯誤。
如果服務器節(jié)點不具有該正在下載的文件,則選擇一個下載速度較快并擁有該文 件分塊單位分片的普通節(jié)點(以下簡稱為選擇節(jié)點)下載。為了節(jié)省網(wǎng)絡資源,避免 重復下載正確的分片,在向選擇節(jié)點發(fā)出下載請求前需要進行如下步驟
査詢在提供了錯誤文件分塊單位的普通節(jié)點中,是否有錯誤計數(shù)記錄,如果有,
向選擇節(jié)點請求下載該普通節(jié)點提供的那一個分片。重新下載的分片對原錯誤文件分
塊單位中隊應的分片進行替換構成完整的文件分塊單位,然后對其進行驗證,如果驗證為正確,則保留文件分塊單位,并比較錯誤文件分塊單位與正確文件分塊單位確定 有哪些分片是錯誤的,為提供1個錯誤分片的普通節(jié)點累計1次錯誤計數(shù)。如果替換 后的文件分塊單位被驗證為錯誤,則向選擇節(jié)點請求下載其他有錯誤記錄普通節(jié)點提 供的分片,重復上述過程,直到所有有錯誤記錄的普通節(jié)點提供的分片均被替換。如 果所有有錯誤記錄普通節(jié)點提供的分片已經(jīng)全被替換,文件分塊單位仍然是錯誤的, 則向選擇節(jié)點請求下載文件分塊單位的全部剩余分片,對從選擇節(jié)點得到的該文件分 塊單位進行驗證,如果文件分塊單位正確,則保留文件分塊單位,對提供錯誤分片的 普通節(jié)點累計錯誤數(shù);如果文件分塊單位錯誤,則累計選擇節(jié)點的錯誤數(shù),重新確定 選擇節(jié)點并向其發(fā)出下載請求,重復進行上述步驟,直到得到正確的文件分塊單位。
如果選擇節(jié)點的出錯率較高,可以直接選擇服務器節(jié)點進行下載并保存數(shù)據(jù)和驗 證信息,這樣可以節(jié)省時間和帶寬。
需要指出的是,上述哈希運算的算法在普通節(jié)點之間應當是同一的,這樣才能起 到驗證的作用。
以下對本發(fā)明的下載文件的系統(tǒng)的工作過程進行描述
普通節(jié)點向服務器節(jié)點發(fā)起連接請求,并獲知所要下載的文件的大小,對于FTP 服務器使用Size Filepath可以得到文件大??;而HTTP協(xié)議中有content-length字段, 可以直接得到文件大小。對FTP或HTTP服務器上的文件以塊大小為256K進行分塊, 并計算分片數(shù)量,生成分塊信息表,所有分塊初始狀態(tài)都置為0,表示還未獲得該分塊。 分塊信息表可以表明文件的下載進度。
獲得要下載文件的特征碼。
根據(jù)特征碼向DHT節(jié)點構成的DHT網(wǎng)絡發(fā)起查詢。向DHT網(wǎng)絡發(fā)送get_peers 消息,查詢正在下載該特征碼的文件的普通節(jié)點列表,并發(fā)送announcejeer將自己的 IP地址、端口存儲在信息保存程序模塊(在本實施例中信息保存程序模塊設置在普通 節(jié)點上)中。如果DHT網(wǎng)絡中存在正在下載此文件的用戶,則DHT網(wǎng)絡返回用戶列 表,如果網(wǎng)絡中不存在任何正在下載此文件普通節(jié)點,則DHT網(wǎng)絡不能返回普通節(jié)點 列表。此意味著本普通節(jié)點為下載此文件的第一個用戶。將特征碼和本普通節(jié)點的IP 地址信息等保存在DHT網(wǎng)絡中(即信息保存程序模塊),再從服務器節(jié)點下載該文件 數(shù)據(jù),每獲取一個文件分塊,都將分塊信息表中對應的比特位置為1,以表明此塊下載 完成。如果網(wǎng)絡中存在其他正在下載此文件的普通節(jié)點,則DHT網(wǎng)絡會返回一個普通 節(jié)點列表,該列表記載正在下載此文件的普通節(jié)點。如果DHT網(wǎng)絡返回普通節(jié)點列表, 則根據(jù)已有的特征碼信息生成握手包,向普通節(jié)點列表中的普通節(jié)點發(fā)出Bittorrent連 接握手包,使用特征碼作為Bittorrent握手包中的哈希值,握手時必須對特征碼進行比 對,完全匹配才允許握手成功。如握手成功,對方即返回它擁有的已下載和未下載的 分塊信息表,根據(jù)此分塊信息表可以向?qū)Ψ桨l(fā)出數(shù)據(jù)請求。不斷嘗試連接其它普通節(jié) 點,則可以得到網(wǎng)絡中所有能連接到的普通節(jié)點的分塊信息表,對所有的分塊信息表 進行"或"運算,可以得到所有普通節(jié)點的分塊信息的合集,據(jù)此可以判斷,所需下 載的文件是否已經(jīng)完整地存在于網(wǎng)絡的普通節(jié)點中。如不完整,則向服務器節(jié)點發(fā)出請求。
如果分塊是從服務器節(jié)點下載的,則在一個分塊下載完成時(從服務器節(jié)點只能 下載分塊的全部分片,不能以分片為單位進行下載),對它進行哈希運算,得到此分塊 的哈希值作為該分塊的驗證碼保存,以備其他普通節(jié)點對此驗證碼的請求。
如果分塊來自其他普通節(jié)點,則在普通節(jié)點上增加一對Bittorrent消息,以傳輸分 塊的驗證碼。
在得到分塊和對應的驗證碼后進行驗證,并根據(jù)驗證結果保存正確的分塊和驗證 碼,放棄錯誤的分塊。每成功下載一個分塊,將自己的分塊信息表的對應位置為1,并 給所有連接上本普通節(jié)點的網(wǎng)絡節(jié)點發(fā)送HAVE消息,表明自己擁有此分片,以便其 他普通節(jié)點請求。
權利要求
1、基于Bittorrent協(xié)議下載文件的系統(tǒng),包括按照Bittorrent協(xié)議設置的網(wǎng)絡,還包括連接于所述網(wǎng)絡中的網(wǎng)絡節(jié)點,網(wǎng)絡節(jié)點包括普通節(jié)點、分布設置于所述網(wǎng)絡中的DHT節(jié)點,普通節(jié)點上設置有下載請求模塊和普通上傳模塊,下載請求模塊用于向所述網(wǎng)絡節(jié)點發(fā)出下載文件分塊單位的請求,普通上傳模塊用于接收其他普通節(jié)點發(fā)來的下載請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位,其特征在于網(wǎng)絡節(jié)點還包括服務器節(jié)點,服務器節(jié)點上設置有服務器上傳模塊,服務器上傳模塊執(zhí)行以下步驟接收普通節(jié)點發(fā)來的下載請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位;DHT節(jié)點上設置信息保存模塊記錄普通節(jié)點具有的可供下載的文件,所述網(wǎng)絡中至少有部分DHT節(jié)點的信息保存模塊記錄服務器節(jié)點具有的可供下載的文件的信息,信息保存模塊響應普通節(jié)點的查詢請求向發(fā)出查詢請求的普通節(jié)點傳遞記錄的信息。
2、 根據(jù)權利要求1所述下載文件的系統(tǒng),其特征在于所述服務器節(jié)點為FTP服務 器或HTTP服務器。
3、 根據(jù)權利要求1所述下載文件的系統(tǒng),其特征在于所述DHT節(jié)點和普通節(jié)點 設置在同一物理設備上。
4、 根據(jù)權利要求1至3之一所述下載文件的系統(tǒng),其特征在于信息保存模塊以一 定周期更新所記錄的信息。
5、 根據(jù)權利要求1至3之一 所述下載文件的系統(tǒng),其特征在于普通節(jié)點上還設 置有分塊驗證模塊,分塊驗證模塊對下載到的文件分塊單位進行驗證,執(zhí)行如下功能 如果文件分塊單位來自服務器節(jié)點,則對此文件分塊單位進行哈希運算,得到的值為 文件分塊單位驗證碼;如果文件分塊單位來自普通節(jié)點,則同時請求得到該文件分塊 單位的文件分塊單位驗證碼,若對文件分塊單位進行哈希運算得到的結果與該文件分 塊單位的文件分塊單位驗證碼一致則保留該文件分塊單位和文件分塊單位驗證碼。
6、 根據(jù)權利要求5所述下載文件的系統(tǒng),其特征在于普通節(jié)點在向其他普通節(jié)點 發(fā)出的Bi加rent握手包中設置一對Bittorent消息以傳輸所述驗證碼請求驗證碼<len = 5〉<id = 140><piece index>; 回復驗證碼<len = 25><id = 141><piece index><hash value>。
7、 根據(jù)權利要求5所述下載文件的系統(tǒng),其特征在于分塊驗證序模塊還執(zhí)行如下功能如果對來自普通節(jié)點的文件分塊單位進行哈希運算的結果與該文件分塊單位的文件分塊單位驗證碼不一致,則記錄發(fā)送該文件分塊單位的普通節(jié)點發(fā)生一次錯誤, 如果某個普通節(jié)點累計發(fā)生錯誤數(shù)達到預定值,則不再向該普通節(jié)點發(fā)出下載文件分 塊單位的請求。
8、 根據(jù)權利要求1至3之一 所述下載文件的系統(tǒng),其特征在于下載請求模塊從 服務器節(jié)點獲取要下載文件的大小和特征碼,特征碼為文件在網(wǎng)絡中唯一標識,根據(jù) 該特征碼向DHT節(jié)點查詢獲取所記錄的信息,根據(jù)獲取到的所述記錄的信息向具有或 部分具有該下載文件的網(wǎng)絡節(jié)點發(fā)出下載請求,所述特征碼為以下兩者之一如果在服務器節(jié)點的URL地址中提供了文件哈希值,則使用此文件哈希值作為特征碼;否則, 文件在服務器節(jié)點上的URL地址經(jīng)哈希運算得到的哈希值作為特征碼。
9、 根據(jù)權利要求8所述下載文件的系統(tǒng),其特征在于信息保存模塊還對應所述特 征碼保存文件哈希值;信息保存模塊應普通節(jié)點的請求提供記錄的信息。
10、 根據(jù)權利要求9所述下載文件的系統(tǒng),其特征在于信息保存模塊還對應文件 哈希值記錄具有該文件的服務器節(jié)點地址,普通節(jié)點可以根據(jù)特征碼查詢到文件哈希 值,進而査詢到具有該文件的服務器節(jié)點地址和普通節(jié)點列表;對應特征碼沒有文件 哈希值時,普通節(jié)點下載完文件后計算出文件哈希值并傳給信息保存模塊,信息保存 模塊將該特征碼與該文件哈希值對應記錄。
全文摘要
為了實現(xiàn)將FTP或HTTP服務器等服務器資源引入到Bittorrent協(xié)議模式中的目的,本發(fā)明提供了一種基于Bittorrent協(xié)議下載文件的系統(tǒng),包括按照Bittorrent協(xié)議設置的網(wǎng)絡,還包括連接于所述網(wǎng)絡中的網(wǎng)絡節(jié)點,網(wǎng)絡節(jié)點包括普通節(jié)點、分布設置于網(wǎng)絡中的DHT節(jié)點、服務器節(jié)點,服務器節(jié)點執(zhí)行以下步驟接收普通節(jié)點發(fā)來的下載請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位;普通節(jié)點上設置有普通上傳模塊,普通上傳模塊用于接收其他普通節(jié)點發(fā)來的下載請求并向該普通節(jié)點傳遞所請求下載的文件分塊單位;DHT節(jié)點上設置信息保存模塊記錄網(wǎng)絡節(jié)點具有的可供下載的文件的信息。
文檔編號H04L29/08GK101626397SQ20091000024
公開日2010年1月13日 申請日期2009年1月14日 優(yōu)先權日2008年7月11日
發(fā)明者耀 黃 申請人:寶利微電子系統(tǒng)控股公司