P2P-BT档案分享在区域网

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

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快取機制•應用於BT同儕通訊的通透閘道快取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同儕通訊的通透閘道快取的機制.•BT快取伺服器–本身為一個修改過之BTClient.置於區網之內.當收到後端系統的命令,即開始下載該Torrent指定之檔案.•通透式proxy–本proxy攔截區網內所有之Http通訊,並專門尋找torrent檔案.當發現Torrent檔案的傳輸時,手會傳送一份備份給後端的處理系統.該系統會拆解其內部訊息,並通知BT快取伺服器、NAT、特製Tracker做好準備.在proxy回傳Torrent檔案前會先移除該檔案紀錄之peers.•NAT重導向–負責將Torrent解析出來之實際Tracker位址轉向至我們的特製Tracker•特製Tracker–本Tracker模擬實際Tracker的動作,唯一不一樣的是他只回傳存在於我們同一網段的peers以及BT快取伺服器.原BT運作流程1.使用者下載Torrentfile2.BTClient讀取Torrent之Tracker位址3.BTClient透過HTTP協定向Tracker登錄,並取得peers列表4.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).在網頁中可觀察到,一個torrent檔案的分享者數目很多都是三、四十個,因此本文中模擬五十個下載者應該是合理且可接受的值。•106個模擬的torrent檔(檔案大小分佈,是統計分析自網站)模擬的torrent檔愈多,因為會降低下載相同檔案的機率,因此應當會降低HitRatio的值。但,這應不影響兩種策略的比較結果。•每個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策略一般,致使兩種策略的HitRatio更加接近。此處只取1/2及2/3來做模擬,只為測試機率愈大時,兩者HitRatio會愈接近且降低,但應不影響最後的結論。•D-node擁有可下載的空間為40,000個單位模擬最後會再針對兩種策略在不同的快取空間大小環境下做比較。•假設:各torrent中任一片段(piece)的大小皆相同實驗結果-圖表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實驗結果-圖表快取策略比較–結論由以上實驗可得到以下的結論:(1)在所有模擬的情況下,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)最大檔案優先策略的表現,比最小檔案優先策略的表現稍佳。結論挑毛病的時間...•架構–使用的結構是區域性的proxy,要有專人維護–通透性方面不夠徹底,無法過濾所有的Torrent,也因此無法代理所有之Tracker.–只要有人下載Torrent檔,BT快取伺服器就必須做預載動作,但是實際上並不一定會立即有人執行該檔的下載動作.•實驗結果–效能比較方面的結果看起來有點誇張,而且結構有點怪異?Thanksforreading!

1 / 34
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功