《{档案管理}P2PBT档案分享在区域网》由会员分享，可在线阅读，更多相关《{档案管理}P2PBT档案分享在区域网（34页珍藏版）》请在金锄头文库上搜索。
1、P2P-BT檔案分享在區域網中快取服務之設計與實現,國中央大學 研究生：董永安 指導教授：曾明博士 投影片製作:Lab505 M95570011 左一廷,Whats P2P and how it works,這篇主要的目標是在BT方面 P2P的連結是非區域性的 peer在互相連結交換檔案時, 常常會跨網段傳輸, 而不是與同網段者交換資料, 這造成了大量的網際網路流量浪費. 起因於Tracker給予peer名單乃是隨機的.,研究目標,建立一個減少資料重複傳送的機制 快取檔案的輪替機制 控制peer連結在同一個網段 建立通透式的機制, 不必修改client端,Cache: 快取的維護策略,BT快取
2、的額外考量,File based or Range based: 刪除時以完整檔案或是以Pieces為單位. (Hit rate vs space) Partial cache or Full cache: 僅儲存 Pieces或是完整檔案. 在此篇paper中選擇了Range based and Full cache,快取之使用策略,” Cache Replacement Policies Revisited： The Case of P2P Traffic”比較出之效果最好的四種快取方式,控制P2P在同網段: 虛擬地域分割Giraud,Phase 1: Synthetic Network
3、Coordinates 用Nodes之間傳送訊息時的latency，做為距的依據，再以下述的判別方法判定較接近的一個AS-like (Autonomous System like)11的虛擬區域網。 Phase 2: Nearby Neighbor Discovery 接著，就要尋找鄰近點，進而做結交換資的動作。此處是用flood的方式，將該點自身的虛擬座標訊息及真實IP位址發送出去，收到該訊息的其它Nodes，也能辨出該點的確是在”附近”，且有意願做結時，會主動向該點做結動作。 缺點: 透過latency判斷有可能將Lan外之節點畫在一起, 且Private IP無法使用此法,BT內建之內網
4、互連功能,BitComet客戶端有內建一實驗性質的內網互連功能 使用UDP Flood搜尋內網的seed, 且因為每個seed使用的port為亂數, 因此會產生非常大量的封包風暴, 對網路反而造成不好的影響.,現有之LAN快取機制,Tracker Agent :給予的名單只限LAN內的下載者，這樣可以限制LAN內的下載者線到LAN外。 Torrent Agent :使用者下載 .torrent時， .torrent檔會先經過此處，經過修改後，再傳送給LAN內的下載者。 TA Client :當作是LAN內的seed：當Peer Agent完成下載檔案時，此機器會對LAN內的Tracker Ag
5、ent作發佈的動作，這樣LAN內就有一個該torrent的種子。 Peer Agent:置於LAN外，作為BT的cache，下載完成後，再和TA Client分享檔案，以對LAN內Tracker Agent作發佈的動作。,一些分散式快取的例子,Squirrel : P2P Web Cache 不使用中央proxy, 全部由client組成的網頁快取系統,市面上現有之產品,多採取封包過濾, 硬體需求高 當peer採取加密策略時會失效,本篇使用的解決方案,大體上是修改增強的機制. BT快取伺服器 本身為一個修改過之BT Client. 置於區網之內. 當收到後端系統的命令, 即開始下載該Torre
6、nt指定之檔案. 通透式proxy 本proxy攔截區網內所有之Http通訊, 並專門尋找torrent檔案. 當發現Torrent檔案的傳輸時, 手會傳送一份備份給後端的處理系統. 該系統會拆解其內部訊息, 並通知BT快取伺服器、NAT 、特製Tracker做好準備. 在proxy回傳Torrent檔案前會先移除該檔案紀錄之peers. NAT重導向 負責將Torrent解析出來之實際Tracker位址轉向至我們的特製Tracker 特製Tracker 本Tracker模擬實際Tracker的動作, 唯一不一樣的是他只回傳存在於我們同一網段的peers以及BT快取伺服器.,原BT運作流程,使
7、用者下載Torrent file BT Client讀取Torrent之Tracker位址 BT Client透過HTTP協定向Tracker登錄, 並取得peers列表 BT Client與peers列表中的節點起始連線並要求檔案,修改之運作流程,使用者下載Torrent file 此時透過Transport Proxy取得該檔案, 並且將其Tracker位址加入NAT紀錄中, 通知特製Tracker加入的新檔案, 命令BT快取伺服器開始預下載該Torrent. BT Client讀取Torrent之Tracker位址 BT Client透過HTTP協定向Tracker登錄, 並取得peer
8、s列表 NAT攔截了向原Tracker的通訊, 並且導向到我們的特製Tracker, 取得了只包含BT快取伺服器以及同區網peers的清單. BT Client與peers列表中的節點起始連線並要求檔案 由於取得之清單只包含本區網內之節點, 因此將不會產生對外流量, 而唯一對外下載者即為我們的BT快取伺服器.,實驗目標,測試使用本架構與不使用之效能差異 測試考慮peers下的快取命中率差異 LRU-R-FULL V.S. LRU-R-FULL/Local Seed Aware,實驗流程 效能比較,對照組(一般LAN架構下使用BT)： (1) PeerA於網站上任意挑選一個用BT協定發佈的檔案，
9、然後下載其 .torrent檔(亦即該檔案的metainfo檔)後，隨即開啟BT client端程式，載入下載的 .torrent檔，並開始做檔案的下載動作。 (2) PeerB也隨即至相同的網頁下載相同的metainfo檔，下載後也刻啟動BT Client端程式，載入已下載的metainfo檔，開始下載動作。 (3) 先做任何動作，直到PeerA或PeerB之中任何一個下載完畢之後 (4) PeerC也至相同的網頁下載相同的 .torrent檔，並用BT Client端程式及下載的 .torrent檔開始下載的動作。 (5) 直到全部下載完畢為止。 實驗組(本文架構下的LAN中使用BT)：
10、實驗步驟同實驗一中的所有步驟。,實驗結果-圖表a,實驗結果-圖表b,實驗結果-圖表c,實驗流程 快取策略比較,實驗結果-圖表a,實驗結果-圖表b,實驗結果-圖表c,快取策略比較 Extra Test,雖然是分析自網站，但熱門程和檔案在某範圍內的多寡卻一定成正比(譬如：0500MB範圍中torrent個有470個，70017500MB範圍中torrent個有3個，但有可能下載70017500MB這範圍中3個torrent的總人是大於下載前者的總人)，因此，本文再將檔案分佈相反過(如下表4-8，”決定個”值做反序排)，測試檔案的大小分佈同，是否會影響LRU-R-FULL1623以及LRU-R-FU
11、LL/LSA此種策的優結果。(亦即檔案大者居多時，是否會影響先前對種取代策的評估) 下面實驗即為將檔案大小的分佈相反後模擬的結果。其中下載完畢後隨即開的機為1/2，且在LRU23判斷時，遇多個相同結果的檔案時，使用最小檔案優先策。 由表中可知，當空間為40,000及80,000時，種的表現雖佳，但LRU-R-FULL/LSA此種策還是較優；而當空間擴增為400,000時，者的差距即大大開。,Extra實驗結果-圖表,Extra實驗結果-圖表,快取策略比較 結論,由以上實驗可得到以下的結： 在所有模擬的情況下，LRU-R-FULL/LSA的Hit Ratio是優於LRU-R-FULL1623。
12、(2) LRU-R-FULL/LSA但Hit Ratio較高，也比LRU-R-FULL1623節頻寬。(由”download / all_download”這個值可知) (3) Peer(s)下載完成後隨即開的機愈大，因此Hit Ratio就愈低。 (4) 最大檔案優先策的表現，比最小檔案優先策的表現稍佳。,結論,挑毛病的時間,架構 使用的結構是區域性的proxy, 要有專人維護 通透性方面不夠徹底，無法過濾所有的Torrent, 也因此無法代理所有之Tracker. 只要有人下載Torrent檔, BT快取伺服器就必須做預載動作, 但是實際上並不一定會立即有人執行該檔的下載動作. 實驗結果 效能比較方面的結果看起來有點誇張, 而且結構有點怪異?,Thanks for reading!,
