P2PBT檔案在區(qū)域網絡中的設計研究[通用]

1、P2P-BT檔案在區(qū)域網絡中的設計研究Whats P2P and how it works這篇主要的目標是在BT方面P2P的連結是非區(qū)域性的peer在互相連結交換檔案時, 常常會跨網段傳輸, 而不是與同網段者交換資料, 這造成了大量的網際網路流量浪費.起因於Tracker給予peer名單乃是隨機的.研究目標建立一個減少資料重複傳送的機制 快取檔案的輪替機制控制peer連結在同一個網段建立通透式的機制, 不必修改client端Cache: 快取的維護策略BT快取的額外考量File based or Range based: 刪除時以完整檔案或是以Pieces為單位. (Hit rate vs s

2、pace)Partial cache or Full cache: 僅儲存 Pieces或是完整檔案.在此篇paper中選擇了Range based and Full cache快取之使用策略” Cache Replacement Policies Revisited： The Case of P2P Traffic”比較出之效果最好的四種快取方式控制P2P在同網段: 虛擬地域分割GiraudPhase 1: Synthetic Network Coordinates 用Nodes之間傳送訊息時的latency，做為距的依據，再以下述的判別方法判定較接近的一個AS-like (Autonomo

3、us System like)11的虛擬區(qū)域網。 Phase 2: Nearby Neighbor Discovery 接著，就要尋找鄰近點，進而做結交換資的動作。此處是用flood的方式，將該點自身的虛擬座標訊息及真實IP位址發(fā)送出去，收到該訊息的其它Nodes，也能辨出該點的確是在”附近”，且有意願做結時，會主動向該點做結動作。 缺點: 透過latency判斷有可能將Lan外之節(jié)點畫在一起, 且Private IP無法使用此法BT內建之內網互連功能BitComet客戶端有內建一實驗性質的內網互連功能使用UDP Flood搜尋內網的seed, 且因為每個seed使用的port為亂數, 因此會

4、產生非常大量的封包風暴, 對網路反而造成不好的影響.現有之LAN快取機制Tracker Agent :給予的名單只限LAN內的下載者，這樣可以限制LAN內的下載者線到LAN外。 Torrent Agent :使用者下載 .torrent時， .torrent檔會先經過此處，經過修改後，再傳送給LAN內的下載者。 TA Client :當作是LAN內的seed：當Peer Agent完成下載檔案時，此機器會對LAN內的Tracker Agent作發(fā)佈的動作，這樣LAN內就有一個該torrent的種子。 Peer Agent:置於LAN外，作為BT的cache，下載完成後，再和TA Client分

5、享檔案，以對LAN內Tracker Agent作發(fā)佈的動作。 一些分散式快取的例子Squirrel : P2P Web Cache不使用中央proxy, 全部由client組成的網頁快取系統(tǒng)市面上現有之產品多採取封包過濾, 硬體需求高當peer採取加密策略時會失效本篇使用的解決方案大體上是修改增強的機制.BT快取伺服器本身為一個修改過之BT Client. 置於區(qū)網之內. 當收到後端系統(tǒng)的命令, 即開始下載該Torrent指定之檔案.通透式proxy本proxy攔截區(qū)網內所有之Http通訊, 並專門尋找torrent檔案. 當發(fā)現Torrent檔案的傳輸時, 手會傳送一份備份給後端的處理系統(tǒng).

6、 該系統(tǒng)會拆解其內部訊息, 並通知BT快取伺服器、NAT 、特製Tracker做好準備. 在proxy回傳Torrent檔案前會先移除該檔案紀錄之peers.NAT重導向負責將Torrent解析出來之實際Tracker位址轉向至我們的特製Tracker特製Tracker本Tracker模擬實際Tracker的動作, 唯一不一樣的是他只回傳存在於我們同一網段的peers以及BT快取伺服器.原BT運作流程使用者下載Torrent fileBT Client讀取Torrent之Tracker位址BT Client透過HTTP協(xié)定向Tracker登錄, 並取得peers列表BT Client與peer

7、s列表中的節(jié)點起始連線並要求檔案修改之運作流程使用者下載Torrent file此時透過Transport Proxy取得該檔案, 並且將其Tracker位址加入NAT紀錄中, 通知特製Tracker加入的新檔案, 命令BT快取伺服器開始預下載該Torrent.BT Client讀取Torrent之Tracker位址BT Client透過HTTP協(xié)定向Tracker登錄, 並取得peers列表NAT攔截了向原Tracker的通訊, 並且導向到我們的特製Tracker, 取得了只包含BT快取伺服器以及同區(qū)網peers的清單.BT Client與peers列表中的節(jié)點起始連線並要求檔案由於取得之清

8、單只包含本區(qū)網內之節(jié)點, 因此將不會產生對外流量, 而唯一對外下載者即為我們的BT快取伺服器.實驗目標測試使用本架構與不使用之效能差異測試考慮peers下的快取命中率差異LRU-R-FULL V.S. LRU-R-FULL/Local Seed Aware實驗流程 效能比較對照組(一般LAN架構下使用BT)： (1) PeerA於網站上任意挑選一個用BT協(xié)定發(fā)佈的檔案，然後下載其 .torrent檔(亦即該檔案的metainfo檔)後，隨即開啟BT client端程式，載入下載的 .torrent檔，並開始做檔案的下載動作。 (2) PeerB也隨即至相同的網頁下載相同的metainfo檔，下

9、載後也刻啟動BT Client端程式，載入已下載的metainfo檔，開始下載動作。 (3) 先做任何動作，直到PeerA或PeerB之中任何一個下載完畢之後(4) PeerC也至相同的網頁下載相同的 .torrent檔，並用BT Client端程式及下載的 .torrent檔開始下載的動作。 (5) 直到全部下載完畢為止。 實驗組(本文架構下的LAN中使用BT)： 實驗步驟同實驗一中的所有步驟。 實驗結果-圖表a實驗結果-圖表b實驗結果-圖表c實驗流程 快取策略比較模擬50個peers (使用multi-thread). 在http:/ (檔案大小分佈，是統(tǒng)計分析自網站) 模擬的torren

10、t檔愈多，因為會低下載相同檔案的機，因此應當會低Hit Ratio的值。但，這應影響種策的比較結果。每個Peer隨機選取106個中的任一torrent檔做下載每個Peer的延遲時間：1 20秒 延遲的時間和下載torrent檔案的大小成正比，因此可看成下載該torrent檔的時間。每個Peer下載torrent檔案的總個：1 50個(隨機決定)每個Peer下載完成後隨即開的機：1/2 及 2/3 機愈大，將使LRU-R-FULL/LSA判斷Seed的步驟跳過，變成如同使用LRU-R-FULL策一般，致使種策的Hit Ratio加接近。此處只取1/2及2/3做模擬，只為測試機愈大時，者Hit R

11、atio會愈接近且低，但應影響最後的結。D-node擁有可下載的空間為40,000個單位 模擬最後會再針對種策在同的快取空間大小環(huán)境下做比較。假設：各torrent中任一片段(piece)的大小皆相同實驗結果-圖表a實驗結果-圖表b實驗結果-圖表c快取策略比較 Extra Test雖然是分析自網站，但熱門程和檔案在某範圍內的多寡卻一定成正比(譬如：0500MB範圍中torrent個有470個，70017500MB範圍中torrent個有3個，但有可能下載70017500MB這範圍中3個torrent的總人是大於下載前者的總人)，因此，本文再將檔案分佈相反過(如下表4-8，”決定個”值做反序排)

12、，測試檔案的大小分佈同，是否會影響LRU-R-FULL1623以及LRU-R-FULL/LSA此種策的優(yōu)結果。(亦即檔案大者居多時，是否會影響先前對種取代策的評估) 下面實驗即為將檔案大小的分佈相反後模擬的結果。其中下載完畢後隨即開的機為1/2，且在LRU23判斷時，遇多個相同結果的檔案時，使用最小檔案優(yōu)先策。 由表中可知，當空間為40,000及80,000時，種的表現雖佳，但LRU-R-FULL/LSA此種策還是較優(yōu)；而當空間擴增為400,000時，者的差距即大大開。 Extra實驗結果-圖表Extra實驗結果-圖表快取策略比較 結論由以上實驗可得到以下的結： 在所有模擬的情況下，LRU-R-FULL/LSA的Hit Ratio是優(yōu)於LRU-R-FULL1623。 (2) LRU-R-FULL/LSA但Hit Ratio較高，也比LRU-R-FULL1623節(jié)頻寬。(由”download / all_download”這個值可知) (3) Peer(s)下載完成後隨即開的機愈大，因此Hit Ratio就愈低。