【正文】 模塊以及網(wǎng)絡通信模塊（如圖 41所示）。其中資源請求模塊、文件分塊模塊和內(nèi)容傳輸模塊屬于底層功能支持的模塊，而文件分塊選擇模塊和負載均衡模塊為內(nèi)容分發(fā)機制的核心功能模塊。圖 41系統(tǒng)功能模塊圖 P2PCDS實現(xiàn)技術 資源請求實現(xiàn)技術資源請求功能是一個內(nèi)容分發(fā)網(wǎng)絡的最基本的功能之一，它的主要功能是資源請求者向網(wǎng)絡發(fā)出某個資源的請求信號，然后網(wǎng)絡向其返回資源的相關詳細信息，系統(tǒng)通過負載均衡算法選擇合適的資源提供者，并向其發(fā)出資源請求以獲得資源下載資格。在這個過程中，它涉及到了資源查找與發(fā)布以及網(wǎng)絡的拓撲結(jié)構(gòu)方面的內(nèi)容。不同的網(wǎng)絡拓撲結(jié)構(gòu)，不同的資源查找與發(fā)布原理都會導致資源請求方式的不同。在本系統(tǒng)中，網(wǎng)絡拓撲結(jié)構(gòu)采用的是開源軟件Emule所采用的的Kademlia網(wǎng)絡，它是一個分布式的結(jié)構(gòu)化覆蓋網(wǎng)絡。資源請求的主要步驟為：（1） 依據(jù)文件名或者文件關鍵字，通過Kademlia網(wǎng)絡進行資源查找，獲得擁有該資源的用戶的相關信息。（2） 通過負載均衡算法獲得合適的資源提供者子集S。（3） 對于S中的每個節(jié)點發(fā)出資源請求信號，首先發(fā)出OP_HASHSETREQUEST，資源提供者接受到該信號后，向其返回OP_HASHSETANSWER信號包，包中攜帶有該文件的HashSet（該文件各個分塊的Hash值的集合）；請求者保存HashSet以后，向提供者發(fā)送OP_STARTUPLOADREQ信號，提供者接受到以后，把請求者加入隊列，向其返回OP_ACCEPTUPLOADREQ信號；請求者在接受到該信號以后，啟動下載，向提供這發(fā)出文件部分請求信號OP_REQUESTPART，而提供這接受到該信號以后，啟動分塊選擇算法，并進入文件分發(fā)功能。資源請求者與擁有者之間的交互如圖 42所示。圖 42資源請求交互圖 文件分塊實現(xiàn)技術為了加快內(nèi)容分發(fā)的速度，使用文件分塊是一個簡單有效的方法。這樣在進行文件傳輸?shù)臅r候，可以把傳輸?shù)淖钚挝豢s小到分塊上，如此擁有不同分塊的主機之間也可以進行相互的分發(fā)。，本文已經(jīng)對本系統(tǒng)的分塊原理進行簡單的說明，下面將對如何實現(xiàn)文件分塊進行詳細的說明。本系統(tǒng)的文件分塊采用了兩種不同粒度的文件分塊方式：第一粒度是9500KB大小的部分（part）；第二粒度是180KB大小的塊（block）。也就是說，本系統(tǒng)的文件分塊分為兩層：第一層為9500KB大小的部分（part），第二層為每部分劃分為180KB的塊（block），其中最后的一塊大小為140KB。這樣傳輸?shù)淖钚挝皇菈K，為防止文件傳輸中出現(xiàn)錯誤，系統(tǒng)采用Hash算法SHA1來對文件分塊進行傳輸后的文件檢驗。在用戶進行某個文件共享發(fā)布前，系統(tǒng)都會對該文件進行分塊，并且對各個分塊進行Hash計算得到一個Hash值集合。在進行文件傳輸前，資源提供者首先要把文件的Hash值集合傳輸給請求者。雖然系統(tǒng)采用了兩層的文件分塊方式，但是在實際上，系統(tǒng)并沒有把文件劃分為部分或者塊的形式讀入內(nèi)存或者類似的小文件，而只是采用保存偏移量的方式實現(xiàn)具體的分塊。由于分塊的大小是固定的，因此要想獲得某個部分的某個塊，只需要知道該部分索引（設為i）以及該塊在該部分中的索引（設為j），然后根據(jù)公式得到該塊在實際文件中的起始偏移量以及結(jié)束偏移量。 41 42但如果，則；如果，則。其中startPos為起始偏移量，endPos為結(jié)束偏移量；i為該塊所在的部分在整個文件部分集合中的索引，而j為該塊在所在部分中的塊集合的索引；PARTSIZE為每個部分的大小，即9500KB；EMBLOCKSIZE為每個塊的大小，即180KB；FILESIZE為文件結(jié)尾偏移量。而對于已經(jīng)接受到的文件分塊，系統(tǒng)體現(xiàn)它們已經(jīng)存在（即該塊下載完成）的方法也是適用偏移量。在系統(tǒng)中，有一個數(shù)據(jù)結(jié)構(gòu)是專門用于保存文件已經(jīng)下載（或者擁有的）的分塊的偏移量的。這個數(shù)據(jù)結(jié)構(gòu)為Gap_Struct，它的定義如下：struct Gap_Struct{ uint64 start。//表示該部分的起始偏移量 uint64 end。//該部分的結(jié)束偏移量}。這個數(shù)據(jù)結(jié)構(gòu)所保存的部分并不是上面文件分塊所定義的part。事實上，它可能是一個block、一個part或者幾個part構(gòu)成的集合，甚至是整個文件。它的作用是告訴系統(tǒng)從start到end的部分已經(jīng)下載完成了。當系統(tǒng)接受一個新塊時，首先從由Gap_Struct數(shù)據(jù)結(jié)構(gòu)作為成員的一個gaplist中查找該塊是否已經(jīng)下載完成，不是的話就保存該塊，并把該塊的偏移量以Gap_Struct結(jié)構(gòu)保存到gaplist中；否則不保存該塊。在一個新的Gap_Struct加入到gaplist的過程中，有一點是需要注意的，即如果某兩個部分可以合并成一個更大的部分，則應該刪除原來的那個Gap_Struct數(shù)據(jù)，并把合并得到的部分作為一個新的元素加入到gaplist中去。而在判斷是否可以合并時，主要是判斷兩個Gap_Struct的相互之間的start和end是否是連續(xù)分布的（即其中一個的start等于另一個的end加一）。在本系統(tǒng)中文件的各個分塊的Hash值集合采用的數(shù)據(jù)結(jié)構(gòu)是樹。樹的結(jié)構(gòu)圖如圖 31所示。首先對文件的每個部分進行Hash值計算，這些部分構(gòu)成一個樹，樹根為整個文件的Hash值；然后針對每一個部分，對一個部分中的每個塊進行Hash值計算，該部分中的各個塊的Hash值又構(gòu)成一個樹，樹根為該部分的Hash值。文件分塊模塊的類圖如圖 43所示。圖 43文件分塊模塊類圖 文件分塊選擇實現(xiàn)技術，本系統(tǒng)采用的分發(fā)方式是一個混合式的分發(fā)方式。對于整個文件來說，采用的是拉方式，而對于文件分塊來說，采用的方式為推方式。在資源提供者接受到請求者所發(fā)出的OP_REQUESTPART信號后，提供者系統(tǒng)進入文件分塊選擇模塊。，文件分塊選擇模塊分為兩個子功能模塊：部分（part）選擇模塊與塊（block）選擇模塊。部分選擇模塊首先執(zhí)行，從文件的眾多部分中選擇出一個合適的部分作為分發(fā)文件部分；然后在該分發(fā)文件部分的各個塊中，通過塊選擇模塊選擇合適的塊進行分發(fā)。（1） 部分選擇模塊實現(xiàn)技術根據(jù)文件分塊選擇算法中所描述的公式31，與部分選擇功能相關的主要因素有：該部分在其他節(jié)點的分布情況、完成度、是否已經(jīng)發(fā)送過以及正在上傳的情況。這幾個因素應該在優(yōu)先級計算前就已經(jīng)得出結(jié)果，也就是說這幾個因素不是即時計算的，而是通過某些事件觸發(fā)計算的。而各個因素的觸發(fā)情況各有不同：其中代表分布情況的是在系統(tǒng)已經(jīng)確認接受作為一個新的請求者的上傳時更新的；代表是否已經(jīng)發(fā)送過的則是系統(tǒng)在接收到某個請求者j的部分請求信號后，進行部分選擇得到某個合適的部分i作為上傳部分時更新的；部分i的正在上傳的接受者的更新情況與一樣，部分選擇所獲得部分的上傳者加一；而則是在系統(tǒng)接收到某個部分i的某個塊，并確認要把該塊寫入文件時更新的。在上述的四個因素中，不僅與文件的部分有關，還與資源請求者有關；而其余的三個因素只與文件的部分有關，與具體的資源請求者并沒有密切的關系。根據(jù)這種情況，應該與其他三個因素分塊定義數(shù)據(jù)結(jié)構(gòu)。因此依據(jù)本身的含義和系統(tǒng)的構(gòu)造，的數(shù)據(jù)結(jié)構(gòu)是一個int型的數(shù)組，該數(shù)組的長度為文件的部分數(shù)，并且該數(shù)組是作為代表上傳客戶端的CUpDownClient的一個成員變量。而對于其他的三個因素，可以定義為一個結(jié)構(gòu)，該結(jié)構(gòu)的定義如下：Struct fileInfo{ Int num。//表示該部分的分布情況 Int upload。//表示該部分的正在上傳狀況 Float finish。}//表示該部分的完成度在代表一個文件的CPartFile中定義一個數(shù)組，該數(shù)組的元素為上面定義的結(jié)構(gòu)fileInfo。當系統(tǒng)需要進行部分選擇的時候，從這兩個數(shù)據(jù)結(jié)構(gòu)中提取相應的信息，然后計算獲得優(yōu)先級，然后對各個部分進行優(yōu)先級排序，把優(yōu)先級最大的哪個部分作為所選擇的部分進行分發(fā)。部分選擇模塊的流程圖如圖 44所示。圖 44部分選擇模塊流程圖（2） 塊選擇模塊實現(xiàn)技術進行塊選擇的時機主要有兩個：第一，當系統(tǒng)的部分選擇結(jié)束得到所要分發(fā)的部分以后，就要對該部分的各個塊進行塊選擇，然后分發(fā)；第二，當系統(tǒng)接收到請求者的塊請求信號OP_REQUESTBLOCK時，就要對上一次所選擇部分進行塊選擇。，本系統(tǒng)的塊選擇模塊采用比較簡單的連續(xù)塊選擇。因此，塊選擇模塊并不需要定義特別的數(shù)據(jù)結(jié)構(gòu)，只需要在CUpDownClient中定義兩個int型的成員變量：一個為lastPart，表示上次部分選擇算法所選擇的部分索引；另一個是lastBlock，表示上一次上傳的塊的索引。流程圖如圖 45所示。而在下載端的處理則相對比較的復雜，為了處理某些情況在CUpDownClient中定義了幾個成員變量：hasUploaded表示系統(tǒng)已經(jīng)接收到該用戶正在上傳部分的塊的數(shù)量，int型數(shù)據(jù)；hasBlock表示所上傳的hasUploaded塊中系統(tǒng)已經(jīng)存在的塊的數(shù)量，int型數(shù)據(jù)；lastSendPartRequest為上一次發(fā)出部分請求時正在獲得上傳的部分的索引，用于避免同一個部分下載中對同一個上傳者發(fā)出多余的部分請求信號；lastSendZone為上一次發(fā)出塊請求信息時正在獲得上傳的塊所在的區(qū)號（一個部分中每5個塊為一個區(qū)），用于避免一個區(qū)中發(fā)出多于的塊請求信號。下載端的處理（即接收端分塊處理模塊）流程如圖 46所示。圖 45塊選擇模塊上傳端流程圖圖 46塊選擇模塊下載端流程圖 負載均衡實現(xiàn)技術，本系統(tǒng)采用基于優(yōu)先級的負載均衡算法。負載均衡的優(yōu)先級計算公式為：。這個公式包含了四個參數(shù)，其中表示資源提供者j的CPU狀況；表示資源提供者j的內(nèi)存狀況；表示提供者j與本節(jié)點之間的距離；為兩節(jié)點之間的網(wǎng)絡狀況。這四個參數(shù)有分別由公式33到36計算出來。從這四個公式可以看出來，、和的計算必須通過請求者與提供者兩者之間進行網(wǎng)絡通信才能得到。如果在請求者端直接采用優(yōu)先級計算公式（即請求者向提供者發(fā)出狀態(tài)查詢信號，獲得提供者的CPU、內(nèi)存和網(wǎng)絡等相關信息，然后在請求者端計算優(yōu)先級，并進行排序），那么在這個優(yōu)先級計算中，總計算時間＝提供者CPU與內(nèi)存狀態(tài)的查詢時間＋網(wǎng)絡通信時間＋優(yōu)先級計算時間＋排序時間。在這四個時間中，查詢時間與優(yōu)先級計算時間在各個節(jié)點中相差不會太大，然而網(wǎng)絡通信時間與當前的網(wǎng)絡狀況有關，具有不確定性；排序時間也與通信時間有關系，只有通信結(jié)束或者超時才能進行排序。因此直接按照公式在請求者端進行優(yōu)先級計算，有可能出現(xiàn)低效的情況。而且對于系統(tǒng)來說，過多的網(wǎng)絡通信會導致網(wǎng)絡狀況的惡化。為消除網(wǎng)絡通信所帶來的不良后果，但在具體的實現(xiàn)細節(jié)上采用兩次優(yōu)先級計算，或者說在請求者端使用優(yōu)先級排序，而在提供者端使用阻塞機制。在請求者端的優(yōu)先級排序已經(jīng)不是對公式32中進行排序，而僅僅是對排序。的定義是請求者與提供者之間的邏輯距離，事實上就是兩者IP的異或值。兩個IP地址越相近，則兩者處以同一個網(wǎng)絡的可能就越大，也就是距離越近。在請求者端對排序完成以后，向前n個提供者發(fā)出資源請求信號（n的取值由系統(tǒng)靜態(tài)設置，一般為10）。而提供者接收到請求以后就啟動阻塞機制：系統(tǒng)首先獲取CPU與內(nèi)存狀態(tài)，計算得到和，然后根據(jù)系統(tǒng)對、和分別設定的阻塞閥值，如果三者任何一個超過其對應的閥值，則該請求者就會被阻塞。然后提供者向請求者返回一個阻塞通知。請求者接收到阻塞通知以后，向鏈表中的下一個提供者發(fā)出資源請求信號，并把被阻塞的提供者移動到鏈表的尾端。而接收請求的提供者直接從鏈表中移出。在提供者接收到資源請求信號以后，無論該請求者是否被阻塞，提供者總是向請求者返回其與所請求文件對應的正在上傳的用戶信息集合。請求者接收到該集合以后，把集合中提供者按照的大小插入到鏈表中。在請求者端服務器選擇功能中，主要有兩個數(shù)據(jù)結(jié)構(gòu)是需要注意的：（1） CUploadServerList類。該類的主要功能是把資源發(fā)現(xiàn)中獲得的服務器信息以及資源請求中返回的下載者信息作為潛在的上傳者信息保存起來，然后根據(jù)上面所介紹的原理進行服務器選擇。具體的結(jié)構(gòu)如下所示：class CUploadServerList {private: CListServerInfo* nearServerList。//距離小于256的服務器列表 CListServerInfo* midServerList。//距離大于256而小于65536的服務器列表 CListServerInfo* farServerList。//距離大于65536的服務器列表 CPartFile * partfile。//所請求的文件的CPartFile對象 struct ClientInfoStreamNode * workingHead。//正在處理的服務器信息包鏈 struct ClientInfoStreamNode * waitingHead。//等待被處理鏈表的頭 struct ClientInfoStreamNode * waitingTail。//等待被處理的鏈表的尾 bool working。//是否正在處理中的標記 CUInt128 hashID。//文件ID int nearListCount。//已經(jīng)發(fā)出資源請求的近服務器的個數(shù) int midListCount。//已經(jīng)發(fā)出資源請求的中服務器的個數(shù) uint32 allReceivedServerCount。//已經(jīng)處理完信息的服務器總數(shù)}。（2） ClientInfoStreamNode結(jié)構(gòu)。該結(jié)構(gòu)主要是保存資源發(fā)現(xiàn)中以及資源請求中返回的未處理的服務器信息網(wǎng)絡包。具體的定義為：struct ClientInfoStreamNode{ const BYTE * packet。//網(wǎng)絡包 uint32 packetSize。//包的大小 struct ClientInfoStreamNode * next。//下一個包的指針}。請求者端的負載均衡的詳細的流程如圖 47所示。圖 47負載均衡請求者端流程圖 本章小結(jié)本章主要介紹了P2P環(huán)境下的內(nèi)容分發(fā)機