P2P-BT档案分享在区域网.ppt

P2P BT檔案分享在區域網 中快取服務之設計與實現 國 中央大學研究生 董永安指導教授 曾 明博士投影片製作 Lab505M95570011左一廷 What sP2Pandhowitworks 這篇主要的目標是在BT方面P2P的連結是非區域性的peer在互相連結交換檔案時 常常會跨網段傳輸 而不是與同網段者交換資料 這造成了大量的網際網路流量浪費 起因於Tracker給予peer名單乃是隨機的 研究目標 建立一個減少資料重複傳送的機制快取檔案的輪替機制控制peer連結在同一個網段建立通透式的機制 不必修改client端 Cache 快取的維護策略 BT快取的額外考量 FilebasedorRangebased 刪除時以完整檔案或是以Pieces為單位 Hitratevsspace PartialcacheorFullcache 僅儲存Pieces或是完整檔案 在此篇paper中選擇了RangebasedandFullcache 快取之使用策略 CacheReplacementPoliciesRevisited TheCaseofP2PTraffic 比較出之效果最好的四種快取方式 控制P2P在同網段 虛擬地域分割Giraud Phase1 SyntheticNetworkCoordinates 用Nodes之間傳送訊息時的latency 做為距 的依據 再以下述的判別方法 判定較接近的一個AS like AutonomousSystem like 11 的虛擬區域網 Phase2 NearbyNeighborDiscovery接著 就要尋找鄰近點 進而做 結交換資 的動作 此處是用flood的方式 將該點自身的虛擬座標訊息及真實IP位址發送出去 收到該訊息的其它Nodes 也能辨 出該點的確是在 附近 且有意願做 結時 會主動向該點做 結動作 缺點 透過latency判斷有可能將Lan外之節點畫在一起 且PrivateIP無法使用此法 BT內建之內網互連功能 BitComet客戶端有內建一實驗性質的內網互連功能使用UDPFlood搜尋內網的seed 且因為每個seed使用的port為亂數 因此會產生非常大量的封包風暴 對網路反而造成不好的影響 現有之LAN快取機制 TrackerAgent 給予的名單只限LAN內的下載者 這樣可以限制LAN內的下載者 線到LAN外 TorrentAgent 使用者下載 torrent時 torrent檔會先經過此處 經過修改後 再傳送給LAN內的下載者 TAClient 當作是LAN內的seed 當PeerAgent完成下載檔案時 此機器會對LAN內的TrackerAgent作發佈的動作 這樣LAN內就有一個該torrent的種子 PeerAgent 置於LAN外 作為BT的cache 下載完成後 再和TAClient分享檔案 以 對LAN內TrackerAgent作發佈的動作 一些分散式快取的例子 Squirrel P2PWebCache不使用中央proxy 全部由client組成的網頁快取系統 市面上現有之產品 多採取封包過濾 硬體需求高當peer採取加密策略時會失效 本篇使用的解決方案 大體上是修改增強的機制 BT快取伺服器本身為一個修改過之BTClient 置於區網之內 當收到後端系統的命令 即開始下載該Torrent指定之檔案 通透式proxy本proxy攔截區網內所有之Http通訊 並專門尋找torrent檔案 當發現Torrent檔案的傳輸時 手會傳送一份備份給後端的處理系統 該系統會拆解其內部訊息 並通知BT快取伺服器 NAT 特製Tracker做好準備 在proxy回傳Torrent檔案前會先移除該檔案紀錄之peers NAT重導向負責將Torrent解析出來之實際Tracker位址轉向至我們的特製Tracker特製Tracker本Tracker模擬實際Tracker的動作 唯一不一樣的是他只回傳存在於我們同一網段的peers以及BT快取伺服器 原BT運作流程 使用者下載TorrentfileBTClient讀取Torrent之Tracker位址BTClient透過HTTP協定向Tracker登錄 並取得peers列表BTClient與peers列表中的節點起始連線並要求檔案 修改之運作流程 使用者下載Torrentfile此時透過TransportProxy取得該檔案 並且將其Tracker位址加入NAT紀錄中 通知特製Tracker加入的新檔案 命令BT快取伺服器開始預下載該Torrent BTClient讀取Torrent之Tracker位址BTClient透過HTTP協定向Tracker登錄 並取得peers列表NAT攔截了向原Tracker的通訊 並且導向到我們的特製Tracker 取得了只包含BT快取伺服器以及同區網peers的清單 BTClient與peers列表中的節點起始連線並要求檔案由於取得之清單只包含本區網內之節點 因此將不會產生對外流量 而唯一對外下載者即為我們的BT快取伺服器 實驗目標 測試使用本架構與不使用之效能差異測試考慮peers下的快取命中率差異LRU R FULLV S LRU R FULL LocalSeedAware 實驗流程 效能比較 對照組 一般LAN架構下使用BT 1 PeerA於網站上任意挑選一個 用BT協定發佈的檔案 然後下載其 torrent檔 亦即該檔案的metainfo檔 後 隨即開啟BTclient端程式 載入下載的 torrent檔 並開始做檔案的下載動作 2 PeerB也隨即至相同的網頁下載相同的metainfo檔 下載後也 刻啟動BTClient端程式 載入已下載的metainfo檔 開始下載動作 3 先 做任何動作 直到PeerA或PeerB之中任何一個下載完畢之後 4 PeerC也至相同的網頁下載相同的 torrent檔 並 用BTClient端程式及下載的 torrent檔開始下載的動作 5 直到全部下載完畢為止 實驗組 本文架構下的LAN中使用BT 實驗步驟同實驗一中的所有步驟 實驗結果 圖表a 實驗結果 圖表b 實驗結果 圖表c 實驗流程 快取策略比較 模擬50個peers 使用multi thread 在 實驗結果 圖表a 實驗結果 圖表b 實驗結果 圖表c 快取策略比較ExtraTest 雖然是分析自網站 但熱門程 和檔案在某範圍內的多寡卻 一定成正比 譬如 0 500MB範圍中torrent個 有470個 7001 7500MB範圍中torrent個 有3個 但有可能下載7001 7500MB這範圍中3個torrent的總人 是大於下載前者的總人 因此 本文再將檔案分佈相反過 如下表4 8 決定個 值做反序排 測試檔案的大小分佈 同 是否會影響LRU R FULL 16 23 以及LRU R FULL LSA此 種策 的優 結果 亦即檔案大者居多時 是否會影響先前對 種取代策 的評估 下面實驗即為將檔案大小的分佈相反後模擬的結果 其中下載完畢後隨即 開的機 為1 2 且在LRU 23 判斷時 遇多個相同結果的檔案時 使用最小檔案優先策 由表中可知 當空間為40 000及80 000時 種的表現雖 佳 但LRU R FULL LSA此種策 還是較優 而當空間擴增為400 000時 者的差距即大大 開 Extra實驗結果 圖表 Extra實驗結果 圖表 快取策略比較 結論 由以上實驗可得到以下的結 在所有模擬的情況下 LRU R FULL LSA的HitRatio 是優於LRU R FULL 16 23 2 LRU R FULL LSA 但HitRatio較高 也比LRU R FULL 16 23 節 頻寬 由 download all download 這個值可知 3 Peer s 下載完成後隨即 開的機 愈大 因此HitRatio就愈低 4 最大檔案優先策 的表現 比最小檔案優先策 的表現稍佳 結論