P2PBT档案分享在区域网

29三月2024P2PBT档案分享在区域网What`sP2Pandhowitworks這篇主要的目標是在BT方面P2P的連結是非區域性的peer在互相連結交換檔案時,常常會跨網段傳輸,而不是與同網段者交換資料,這造成了大量的網際網路流量浪費.起因於Tracker給予peer名單乃是隨機的.P2PBT档案分享在区域网研究目標建立一個減少資料重複傳送的機制快取檔案的輪替機制控制peer連結在同一個網段建立通透式的機制,不必修改client端P2PBT档案分享在区域网Cache:快取的維護策略P2PBT档案分享在区域网BT快取的額外考量FilebasedorRangebased:刪除時以完整檔案或是以Pieces為單位.(Hitratevsspace)PartialcacheorFullcache:僅儲存Pieces或是完整檔案.在此篇paper中選擇了RangebasedandFullcacheP2PBT档案分享在区域网快取之使用策略”CacheReplacementPoliciesRevisited：TheCaseofP2PTraffic”比較出之效果最好的四種快取方式P2PBT档案分享在区域网控制P2P在同網段:虛擬地域分割GiraudPhase1:SyntheticNetworkCoordinates利用Nodes之間傳送訊息時的latency，做為距離的依據，再以下述的判別方法來判定較接近的一個AS-like(AutonomousSystem–like)[11]的虛擬區域網路。Phase2:NearbyNeighborDiscovery接著，就要尋找鄰近點，進而做連結交換資料的動作。此處是用flood的方式，將該點自身的虛擬座標訊息及真實IP位址發送出去，收到該訊息的其它Nodes，若也能辨識出該點的確是在”附近”，且有意願做連結時，便會主動向該點做連結動作。缺點:透過latency判斷有可能將Lan外之節點畫在一起,且PrivateIP無法使用此法P2PBT档案分享在区域网BT內建之內網互連功能BitComet客戶端有內建一實驗性質的內網互連功能使用UDPFlood搜尋內網的seed,且因為每個seed使用的port為亂數,因此會產生非常大量的封包風暴,對網路反而造成不好的影響.P2PBT档案分享在区域网現有之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作發佈的動作。

P2PBT档案分享在区域网P2PBT档案分享在区域网一些分散式快取的例子Squirrel:P2PWebCache不使用中央proxy,全部由client組成的網頁快取系統P2PBT档案分享在区域网市面上現有之產品多採取封包過濾,硬體需求高當peer採取加密策略時會失效P2PBT档案分享在区域网本篇使用的解決方案大體上是修改增強<應用於BT同儕通訊的通透閘道快取>的機制.BT快取伺服器本身為一個修改過之BTClient.置於區網之內.當收到後端系統的命令,即開始下載該Torrent指定之檔案.通透式proxy本proxy攔截區網內所有之Http通訊,並專門尋找torrent檔案.當發現Torrent檔案的傳輸時,手會傳送一份備份給後端的處理系統.該系統會拆解其內部訊息,並通知BT快取伺服器、NAT、特製Tracker做好準備.在proxy回傳Torrent檔案前會先移除該檔案紀錄之peers.NAT重導向負責將Torrent解析出來之實際Tracker位址轉向至我們的特製Tracker特製Tracker本Tracker模擬實際Tracker的動作,唯一不一樣的是他只回傳存在於我們同一網段的peers以及BT快取伺服器.P2PBT档案分享在区域网原BT運作流程使用者下載TorrentfileBTClient讀取Torrent之Tracker位址BTClient透過HTTP協定向Tracker登錄,並取得peers列表BTClient與peers列表中的節點起始連線並要求檔案P2PBT档案分享在区域网修改之運作流程使用者下載Torrentfile

此時透過TransportProxy取得該檔案,並且將其Tracker位址加入NAT紀錄中,通知特製Tracker加入的新檔案,命令BT快取伺服器開始預下載該Torrent.BTClient讀取Torrent之Tracker位址BTClient透過HTTP協定向Tracker登錄,並取得peers列表 NAT攔截了向原Tracker的通訊,並且導向到我們的特製Tracker,取得了只包含BT快取伺服器以及同區網peers的清單. BTClient與peers列表中的節點起始連線並要求檔案

由於取得之清單只包含本區網內之節點,因此將不會產生對外流量,而唯一對外下載者即為我們的BT快取伺服器.P2PBT档案分享在区域网P2PBT档案分享在区域网實驗目標測試使用本架構與不使用之效能差異測試考慮peers下的快取命中率差異LRU-R-FULLV.S.LRU-R-FULL/LocalSeedAwareP2PBT档案分享在区域网實驗流程–效能比較對照組(一般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)：實驗步驟同實驗一中的所有步驟。P2PBT档案分享在区域网實驗結果-圖表aP2PBT档案分享在区域网實驗結果-圖表bP2PBT档案分享在区域网實驗結果-圖表cP2PBT档案分享在区域网實驗流程–快取策略比較模擬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)的大小皆相同P2PBT档案分享在区域网P2PBT档案分享在区域网實驗結果-圖表aP2PBT档案分享在区域网實驗結果-圖表bP2PBT档案分享在区域网實驗結果-圖表cP2PBT档案分享在区域网快取策略比較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時，兩者的差距即大大拉開。P2PBT档案分享在区域网P2PBT档案分享在区域网Extra實驗結果-圖表P2PBT档案分享在区域网Extra實驗結果-圖表P2PBT档案分享在区域网快取策略比較–結論由以上實驗可得到以下的結論：在所有模擬的情況下，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)最