一種p2p內容下載緩存系統設計和下載軟件開發(文件)

　

【正文】 Content Delivery Network，即內容分發網絡。當用戶的請求到達指定節點時，CDN的服務器（節點上的高速緩存)負責將用戶請求的內容提供給用戶。各部分功能見表21。但是Web Caching在P2P內容緩存系統中是否可行呢？178。178。 Web Caching所處的位置是在網絡的邊緣，可以靠近客戶端，也可以接近服務器端，根據其所處的位置也有所不同。可行性報告結論：根據以上比較可知，Web Caching技術在不能達到P2P內容緩存服務器設計的要求，其方案不可行。 CDN內容分發網絡主要傳遞內容為大容量的媒體文件，這與目前主流P2P文件下載應用傳遞內容基本一致。 CDN系統在實現效果上比較理想，性能、可伸縮性和可靠性都很好，節省了網絡帶寬。178。 CDN內容分發網絡需要在全球各地設置服務器，成本比較高，而P2P內容下載范圍一般沒有這么廣，不必要全球分布服務器。 本章小結在本章中，我們分別展示了Web Caching技術和CDN內容分法網絡技術的技術原理以及這兩種技術的比較，同時結合目前P2P流量情況進行分析，研究這兩種緩存技術是否適合P2P流量的需要，得到以下結論：(1) Web Caching技術和CDN技術在實現方式、運營模式、資金投入等方面不適合P2P流量的需要，不能滿足有效控制P2P流量的作用。對于ISP來說，P2P的快速大規模的使用使ISP的利益受到了很大的影響：帶寬資源被P2P應用耗用殆盡，無法滿足一些客戶帶寬的要求；嚴重沖擊了ISP的傳統業務收入。其設計目標及要求如下：(1) 通過一定的技術手段，減少ISP出口的P2P連接數量（流量）或是適當降低用戶信息的下載速度，實現P2P流量在ISP出口處的壓力，從而節省網絡帶寬。(5) 此系統設計對于網絡接入用戶來說是透明的。 系統設計層次結構首先，所有的P2P應用都是屬于OSI模型的第七層——應用層的，其次，所有的P2P 應用都是一種通信過程，無論是通過TCP傳輸方式，還是UDP方式；最后，由于ISP需要將所有經過ISP路由器的P2P數據檢測出來，改變其路由，轉發到設置好的P2P內容緩存服務器中，所以，網絡層路由轉發策略也是系統中很重要的部分。同時，設計一個主動下載P2P內容策略，預測用戶可能需要下載的P2P內容。另外，由于P2P內容緩存數據庫的空間是有限的，所以本部分存在一個信息淘汰算法，淘汰一段時間內沒有用戶請求下載的P2P內容或者是該P2P內容發生更新的P2P內容。初始化剩余空間有文件下載更新有無該文件更新數據庫（增）無有有等待淘汰有查詢記錄長時間無下載是否無下載更新數據庫（刪）無淘汰更新數據庫（刪）圖33 文件內容更新示意圖對數據包分類用戶數據流是不是P2P數據是不是P2P下載路由器將該數據包轉發至P2P緩存服務器正常通過ISP出口有無該種子文件有更新嗎用戶到P2P緩存服務器中下載下載種子和內容是否無有有無下載完了嗎是否是否開始結束（與用戶斷開連接）圖34 系統工作原理圖 系統關鍵技術在前面幾個中，我們詳細分析了系統設計目標與要求和功能模塊設計，可以看出，該系統的關鍵是系統能夠在多用戶同時請求P2P內容時快速響應用戶請求，提供P2P內容下載業務。客戶端與服務器端使用不同的傳輸協議socket編程是不同的，圖35為使用TCP協議socket編程流程圖。一個BT client 在下載開始以及下載進行的過程中，要不停的與 tracker 服務器進行通信，以報告自己的信息，并獲取其它下載client的信息。由于本系統再邏輯上比較復雜，為了使系統更加簡潔，功能更加明確，因此根據其功能將系統分為六個部分：178。 種子下載客戶端模塊：該模塊的任務是負責種子文件和內容文件的下載，主要有兩種情況：用戶請求下載，P2P緩存服務器上沒有；P2P服務器設置一個策略，主動搜索“熱門”種子，預測用戶可能對哪些種子感興趣，請求下載的種子文件和內容文件，下載文件放在P2P緩存服務器中，等待用戶下載，并將其信息加入到種子信息數據庫中。 模擬Tracker服務器模塊：當ISP內peer向外部Tracker發送GET請求時，此模塊模擬外部Tracker向peer返回HTT GET的響應信息。 種子信息數據庫模塊：負責對種子信息數據庫的維護（增加、刪除、修改、更新）。本方案主要由種子請求處理模塊、內容請求處理模塊、種子自動搜索模塊三個模塊組成，每個模塊之間相對獨立，互不干擾。l 內容請求處理模塊：本模塊相當于一個內容服務器，響應用戶內容請求，將請求內容按照某種方式傳送給客戶端。 方案比較方案一：系統設計功能全面，能夠支持目前主流所有P2P應用軟件，擴展性好，能夠解決目前ISP出口網絡擁塞得狀況。開發環境采用Linux系統，Linux系統是“開放性架構”，支持幾乎所有的計算機平臺上，包括PC、PC服務器、UNIX服務器、中型機、大型計算機上，給用戶的應用軟件在不同的平臺之間的移植創造了極為便利的條件。調試工具選擇GDB工具，它可以方便的設置斷點、單步跟蹤，能夠滿足全部的調試程序的需要。178。①Client與內容緩存服務器請求建立連接的過程；②服務器與Client之間進行應用層握手的過程；③P2P內容主進程派生出一子進程負責處理與Client通信；④子進程查詢緩存服務器，找到Client請求內容的過程，如果沒有請求內容則需要先下載；⑤子進程向Client發送種子文件和擁有該種子的peer列表；C1Cn內容請求監聽進程1內容緩存服務器緩存數據庫S1Sn①②③④⑤Client 1Client n內容請求監聽進程10S’1S’n圖42 P2P內容服務進程工作示意圖說明：在P2P緩存服務器上同時運行10個P2P內容服務進程，10個進程功能完全相同，只是監聽端口不同而已，端口為68816889這10個端口。port)子進程父進程連接種子服務器下載該種子，并連接原始內容服務器下載內容文件能取得內容嗎？有這個種子嗎？采用P2P下載方式下載內容文件內容完整嗎？結束子進程，釋放資源有無是向請求該種子的Client返回“無請求的種子”否是圖43 P2P種子下載程序流程圖建立Socket（sockfd）開始(main)Listen客戶端請求內容的連接accept 客戶端的P2P內容請求使用fork()函數創建一子進程等待客戶端發送主動握手信息向Client發送被動握手信息收到Client主動握手信息向Client發送bitfield信息子進程父進程建立新socket 與客戶端通信解析握手信息，得到Info_hash收到Client的interest信息向Client發送unchock信息解析Client發來的request信息根據request信息返回piece信息傳遞內容完整嗎？結束子進程，釋放資源圖44 P2P內容服務程序流程圖 數據結構與關鍵算法分析 socketint socket ( /*返回一個整形的socket描述符 */ int family, /*指明所使用的協議簇 */ int type, /*socket的類型,UDP或是TCP */ int protocol /*指明使用協議名 */)。 /* 地址族 */　　 unsigned short int sin_port。178。 P2P種子下載進程listenport： 3333 監聽客戶端連接的端口；get_dest_port： 8080 HTTP服務器監聽的服務器端口；content_svr_port：5555 內容服務器監聽的服務端口；178。4) info_hash：元信息文件中的鍵info的20字節SHA1哈希值。a) keepalive：len=0000 keepalive消息長度固定，消息長度后面沒有任何數據。bitfield消息是變長的，X指bitfield的長度。如果長度不正確，或剩余比特位有任何位置1，客戶端都應該丟棄連接；h) request:len=0013id=6indexbeginlength request消息長度固定，用于請求一個塊。index：4字節整數，指明片的索引號。監聽端口是該peer的DHT節點的監聽端口，該peer應被插入到當地路由表上（如果DHT Tracker支持的話）；說明：在連接開始時，Peer之間的狀態為是“阻塞”和“無興趣”狀態，即：216。 peer_interested = 0 （此peer對該客戶端感興趣） peer結構體P2P緩存服務器向client返回的peer（結構體）列表（列表中包含N個peer信息），列表中包含4個字節的IP地址，2個字節的Port端口號。 HTTP GET請求格式每個HTTP請求都包含兩個部分：1) HTTP請求行，為GET；2) HTTP請求中的可選消息頭，這些消息頭會由于使用的HTTP客戶端瀏覽器或客戶端瀏覽器配置選項的不同而不同。 數據定義178。系統配置表見41，網絡拓撲結構[14]見圖45。另外，它主要用于TCP連接，而在UDP連接中則無此必要。經查閱資料發現，Linux系統下提供了兩個用于關閉進程的函數[9]exit()和_exit()，當程序執行到exit和_exit時，進程會無條件地停止剩下所有的操作，清楚包括PCB在內的各種數據結構，并終止本進程的運行。 文件I/O操作過程本系統中使用的文件I/O操作均是不帶緩存在I/O操作，主要涉及到5個函數[9]，open、read、write、lseek、close。經仔細檢查，發現在打開文件時，open函數代入了一個參數O_TRUNC，這個參數的代表：當打開文件存在時，并且以只讀或只寫方式成功打開時，首先全部刪除文件原有數據，再對文件進行操作，因此才會發現原文件大小變為0。為了解決問題，將文件打開方式中的追加方式去掉，在將接受到數據寫入到文件之前，利用lseek函數將移動文件指針，將指針移到存放該數據的首地址。 文件寫操作時，追加與覆蓋的區別當使用P2P方式下載文件時，由于文件采取分片傳輸的方式，因此要多次將受到的數據寫入到文件中，文件傳送方式是順序的，在打開文件時，就將文件打開發式設置為追加方式，在用戶正常下載文件時運行很正常。其中每個函數都有規定好的參數，代入不同的參數，得到不同的結果。最大的區別就在于exit()函數在調用exit系統之前要檢查文件打開情況，把文件緩沖區中的內容寫回文件，而_exit()則不執行此操作。經查找，發現IP地址設置為INADDR_ANY(即為本地IP地址)，端口選擇8080端口，而8080端口被WWW服務占用，所以綁定出錯，改成3333后綁定成功。 系統測試時遇到的問題 socket通信中bind問題在使用socket通信中，bind()是一個很重要的函數，一般在服務器端程序中使用。 P2P內容服務進程LISTENNUM 1000 P2P內容服務進程監聽連接的最大數；MAXREAD 4096 從文件中讀取到緩沖區read_buf中數據的最大字節數，也是每片 的最大數；MAXMSG 5109 客戶端與服務器之間進行交換信息的最大字節數，也即是支持最大 每片為4M字節的文件下載；SERVERPORT 68816889 P2P內容服務進程監聽端口； 系統軟件測試 系統測試環境由于本系統是面向ISP開發和使用的，但是由于條件限制，不能再真實的ISP出口處進行測試，因此選擇在局域網內測試。這里可以看到客戶端能夠接收的類型有gif、bitmap、jpeg等等。 /* IP地址 */ unsigned short int sin_port。 am_interested = 0　 （am_interested：該客戶端對此peer感興趣）216。block：塊數據，是指定索引的片的子集；j) cancel:len=0013id=8indexbeginlength cancel消息固長，負載和request消息的一樣。begin：4字節整數，指明片內的字節偏移量。最后剩余的比特位置0。該消息通常每兩分鐘發送一次；b) chock：len=0001id=0 chock消息長度固定，且沒有負載；c) unchock：len=0001id=1 unchock消息長度固定，且沒有負載；d) interested：len=0001id=2 interested消息長度固定，且沒有負載；e) not interested:len=0001id=3 not interested消息長度固定，且沒有負載；f) have:len=0005id=4piece index have消息長度固定，負載是一個片的索引，該索引從零開始，是成功下載并且通過哈希驗證的；g) bitfield：len=0001+Xid=5bitfield bitfield消息可能只在握手系列完成后立刻發送，在這之前沒有其他任何消息發送。 消息流message的格式[13]長度前綴消息 ID負載。2) pstr:協議的字符串標志（通常為BitTorrent protocol）。router_addr： 路由器將P2P數據報轉發給P2P緩存服務器的sockaddr；getclient_addr： 請求種子的客戶端的sockaddr；seedserver_addr： 種子服務器的sockaddr；cont