FRONT互聯(lián)網(wǎng)文件存儲(chǔ)與共享系統(tǒng).doc

FRONT互聯(lián)網(wǎng)文件存儲(chǔ)與共享系統(tǒng)劉斌 劉忠義網(wǎng)絡(luò)實(shí)驗(yàn)室夏冰數(shù)據(jù)庫實(shí)驗(yàn)室朱彬軟工實(shí)驗(yàn)室摘要 本文受Freenet項(xiàng)目的啟發(fā)，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)具備存儲(chǔ)和共享功能的互聯(lián)網(wǎng)分布式文件系統(tǒng)Files Reiable ON inTernet (FRONT)。FRONT在操作系統(tǒng)的文件系統(tǒng)之上提供了一層新的虛擬文件系統(tǒng)，上傳到FRONT系統(tǒng)的文件被適當(dāng)?shù)厍蟹植⒎峙涞骄W(wǎng)絡(luò)中某些節(jié)點(diǎn)上。通過文件分塊表或文件塊復(fù)制和緩存，用戶得以利用FRONT實(shí)現(xiàn)可用高效的文件訪問。FRONT系統(tǒng)使用磁盤配額和固定共享空間比例的技術(shù)來配合這個(gè)虛擬文件系統(tǒng)，來解決P2P應(yīng)用中的Free rider問題。Front使用Random Walk算法進(jìn)行文件定位，并且在網(wǎng)路規(guī)模變化時(shí)保持系統(tǒng)中文件的高可用性和高性能。實(shí)驗(yàn)表明本文實(shí)現(xiàn)FRONT系統(tǒng)運(yùn)行正確，性能有待進(jìn)一步實(shí)驗(yàn)。關(guān)鍵詞 分布式系統(tǒng)、P2P、網(wǎng)絡(luò)存儲(chǔ)、文件共享I. 介紹A. 工作動(dòng)機(jī)今天互聯(lián)網(wǎng)上已經(jīng)有許多成熟的P2P文件共享系統(tǒng)，例如BT、迅雷、Maze等，它們的存在極大地豐富了普通網(wǎng)民可以訪問的互聯(lián)網(wǎng)資源。這些系統(tǒng)著重于將互聯(lián)網(wǎng)上的文件以P2P的方式共享給更多用戶。幾乎在這些P2P共享協(xié)議在開始被研究和應(yīng)用的同時(shí)（2001年），學(xué)術(shù)界也曾熱烈地討論過在互聯(lián)網(wǎng)絡(luò)上提供開放的存儲(chǔ)服務(wù)的分布式文件系統(tǒng)，一些著名的系統(tǒng)包括CFS、Gnutella、FreeNet等。今天仍有一些個(gè)人和組織在這些協(xié)議的基礎(chǔ)上開發(fā)擴(kuò)展和應(yīng)用。但是由于版權(quán)、用戶激勵(lì)、網(wǎng)絡(luò)封禁等等原因，這些系統(tǒng)一直停留在研究階段或者很小規(guī)模的應(yīng)用。隨著網(wǎng)絡(luò)的普及和計(jì)算服務(wù)的無所不在，普通用戶開始在一個(gè)以上的計(jì)算機(jī)上進(jìn)行文件存??；并且越來越多的群體或組織的成員參與到互聯(lián)網(wǎng)上的協(xié)作和共享。這樣的需求可以使用分布式的文件存儲(chǔ)和共享技術(shù)來滿足。本文是幾位研究生在學(xué)習(xí)分布式系統(tǒng)課程之后的一次嘗試，希望開發(fā)一個(gè)具有一定可擴(kuò)展性的分布式文件系統(tǒng)FRONT（Files Reliable ON inTernet），用戶可以使用這個(gè)系統(tǒng)實(shí)現(xiàn)高效的文件存儲(chǔ)與訪問。B. 本文內(nèi)容FRONT文件系統(tǒng)最主要受到FreeNet6項(xiàng)目的啟發(fā)。FRONT系統(tǒng)無須依托任何基礎(chǔ)設(shè)施，當(dāng)文件存儲(chǔ)或者共享的需求產(chǎn)生時(shí)，它即可從一臺(tái)主機(jī)的規(guī)模開始擴(kuò)展，在網(wǎng)絡(luò)規(guī)模和共享空間逐漸擴(kuò)大的同時(shí)，它可以持續(xù)提供高可用、高性能的文件存儲(chǔ)與共享服務(wù)。FRONT采用用戶磁盤配額的方式，讓每一臺(tái)主機(jī)向整個(gè)系統(tǒng)提供存儲(chǔ)空間，并通過控制共享空間與用戶需求空間的比例來避免free rider問題。FRONT系統(tǒng)對(duì)用戶上傳的文件進(jìn)行適當(dāng)?shù)厍蟹?，使之映射為操作系統(tǒng)的文件系統(tǒng)之上的虛擬文件系統(tǒng)Front VFS中的文件。文件分塊的設(shè)計(jì)讓用戶可以上傳更大的文件，并且流行的文件塊將被分配到更多的機(jī)器上，帶來更高的訪問性能。新的一層虛擬文件系統(tǒng)還造成了用戶對(duì)磁盤空間使用的不透明性，又一次保證了客戶端在使用系統(tǒng)的同時(shí)提供必要的服務(wù)。在文件分塊后，系統(tǒng)中需要存儲(chǔ)的數(shù)據(jù)包括文件的分塊表和文件塊兩種類型。文件分塊表使用“發(fā)布者用戶空間”上的路徑來定位，文件塊使用對(duì)數(shù)據(jù)內(nèi)容的哈希來定位。為了提供高可用性和高性能，F(xiàn)RONT在文件塊的級(jí)別在系統(tǒng)中實(shí)現(xiàn)了復(fù)制和緩存。FRONT對(duì)于局域網(wǎng)構(gòu)成的網(wǎng)絡(luò)還做了特別的優(yōu)化處理，讓處在同一個(gè)以太網(wǎng)絡(luò)內(nèi)的本地用戶高效地利用網(wǎng)絡(luò)，并降低對(duì)整體網(wǎng)絡(luò)的負(fù)擔(dān)。另外，F(xiàn)RONT系統(tǒng)中節(jié)點(diǎn)的通訊組織方式提供了高效的文件查找功能。這些都將在下面的章節(jié)中系統(tǒng)介紹。下文的主要內(nèi)容：第II部分描述了Front文件系統(tǒng)對(duì)于應(yīng)用場景的假設(shè)，并分析在假設(shè)情況下的文件系需要解決的問題。第III部分是對(duì)Front文件系統(tǒng)的結(jié)構(gòu)設(shè)計(jì)。第IV部分是本文的主要部分，介紹了開發(fā)Front文件系統(tǒng)的細(xì)節(jié)。第V部分講述了Front文件系統(tǒng)的運(yùn)行情況，分析對(duì)比了與其他文件系統(tǒng)的區(qū)別和特點(diǎn)。最后第VI部分是對(duì)本文工作的總結(jié)和展望。II. 假設(shè)和問題我們基于互聯(lián)網(wǎng)上的存儲(chǔ)和共享需求設(shè)計(jì)并實(shí)現(xiàn)了Front網(wǎng)絡(luò)文件系統(tǒng)，為互聯(lián)網(wǎng)用戶提供了高效可靠的文件服務(wù)。它適用于在下文定義的一些假設(shè)情況，我們認(rèn)為這些假設(shè)有較強(qiáng)的普遍性和適應(yīng)性，滿足了很多應(yīng)用需求。這些假設(shè)包括以下幾點(diǎn)：1） 互聯(lián)網(wǎng)中存在多個(gè)節(jié)點(diǎn)，無論它們是否鄰近。它們?cè)敢夤餐M織一個(gè)文件存儲(chǔ)和共享平臺(tái)。這個(gè)平臺(tái)可以選擇由預(yù)先定義的用戶組成，與Internet上可能存在的其他front網(wǎng)絡(luò)沒有交互。2） 每個(gè)參與的節(jié)點(diǎn)提供存儲(chǔ)空間和一定的網(wǎng)絡(luò)帶寬。每個(gè)節(jié)點(diǎn)的空間組合起來構(gòu)成全局大容量的存儲(chǔ)共享空間。節(jié)點(diǎn)在自己的文件需要的容量之外還能夠提供一定比例的“服務(wù)空間”，用于存儲(chǔ)全局的其他文件，為別人提供服務(wù)。3） 文件系統(tǒng)的文件發(fā)布和下載對(duì)于用戶來說好像本地的一樣。節(jié)點(diǎn)上的用戶不用關(guān)心文件傳輸?shù)氖虑?，包括文件?nèi)容從哪里獲得、發(fā)往哪里。分布式系統(tǒng)數(shù)據(jù)復(fù)制和協(xié)議通訊對(duì)用戶都是不可見的。4） 一些節(jié)點(diǎn)組成的分布式網(wǎng)絡(luò)中。發(fā)布和下載的需求并不一定是對(duì)稱的。例如在一個(gè)極端情況下，一個(gè)網(wǎng)絡(luò)中總是由一個(gè)節(jié)點(diǎn)在發(fā)布（上傳）文件，其他節(jié)點(diǎn)都是不同需要的下載者。5） 文件系統(tǒng)提供的語義是只讀的。文件發(fā)布后即可由他人獲得，但不可修改。6） 向Front網(wǎng)絡(luò)上發(fā)布的文件可能很大，甚至大于本地節(jié)點(diǎn)提供的共享空間容量。但只要front網(wǎng)絡(luò)平臺(tái)上還有空間，它就應(yīng)該上傳成功。本文需要設(shè)計(jì)一個(gè)網(wǎng)絡(luò)文件系統(tǒng)，滿足以上假設(shè)的應(yīng)用場景，并且保證這個(gè)分布式文件系統(tǒng)的高可用和高性能。需要解決的問題有下面3個(gè)方面：a) 本地文件系統(tǒng)首先，為了在本地保證用戶提供的“共享空間”比例，F(xiàn)ront在本地磁盤上的存取應(yīng)該對(duì)用戶有一定的不透明性。也即用戶看不到是什么數(shù)據(jù)（在操作系統(tǒng)里看就是文件）占用了本地磁盤。一種可行的方案是，用戶在操作系統(tǒng)里看到的存儲(chǔ)文件不是發(fā)布到Front系統(tǒng)的文件的直接形式。發(fā)布的文件可以經(jīng)過某種轉(zhuǎn)化后存在磁盤上，用戶不知道那個(gè)什么文件是自己需要的還是提供給他人的，因此不太愿意去冒險(xiǎn)刪掉其中的一部分。從這個(gè)角度上可以部分解決P2P系統(tǒng)的Free Rider問題。一種簡單的磁盤存儲(chǔ)不透明性可以用文件分塊來實(shí)現(xiàn)。通過把文件切分成一定大小的文件塊，可以自然的把系統(tǒng)上的眾多文件數(shù)據(jù)“混淆”在一起。把文件分成塊，還可以簡化一個(gè)節(jié)點(diǎn)上傳大于本地空間大小的文件的設(shè)計(jì)。另外，在分布式文件系統(tǒng)中，我們希望資源（包括復(fù)本）可以均勻的分布在更多的節(jié)點(diǎn)上，這樣可以帶來更高的可用性和性能。顯然，當(dāng)文件分成較小的塊時(shí)，系統(tǒng)中的大文件也更加容易實(shí)現(xiàn)在網(wǎng)絡(luò)中的這種分布。文件分塊的一個(gè)額外開銷是需要在這個(gè)網(wǎng)絡(luò)中維護(hù)文件分塊信息，并且對(duì)文件的請(qǐng)求被分為多個(gè)不走。另一個(gè)需要在本地處理的問題是，當(dāng)資源請(qǐng)求超過了本地磁盤配額，如何權(quán)衡用戶的需要得到滿足和節(jié)點(diǎn)同時(shí)為網(wǎng)絡(luò)提供存儲(chǔ)服務(wù)的矛盾，F(xiàn)ront系統(tǒng)本地需要一個(gè)安全有效的數(shù)據(jù)替換算法。b) 網(wǎng)絡(luò)互聯(lián)和文件查詢網(wǎng)絡(luò)上需要協(xié)作的Front節(jié)點(diǎn)需要一種辦法來知道彼此的存在。節(jié)點(diǎn)加入和離開對(duì)網(wǎng)絡(luò)的影響不能太大。因此當(dāng)網(wǎng)絡(luò)規(guī)模較大時(shí)，節(jié)點(diǎn)之間不可能兩兩可知的。相互可知的節(jié)點(diǎn)互為鄰居，并且可以彼此交換信息，以增強(qiáng)網(wǎng)絡(luò)連通性或者傳遞查詢請(qǐng)求等。一個(gè)理想的網(wǎng)絡(luò)連接情況是：臨近（IP或者地理位置）的節(jié)點(diǎn)盡可能互為鄰居，形成連通性較強(qiáng)的局部網(wǎng)絡(luò)；距離較遠(yuǎn)的節(jié)點(diǎn)之間保持一定的連通，這樣才能讓遠(yuǎn)處的查詢得到本地的信息，讓整個(gè)網(wǎng)絡(luò)的信息通暢。為了避免網(wǎng)絡(luò)中的節(jié)點(diǎn)孤島，需要一種方法顯式地加入已經(jīng)存在的網(wǎng)絡(luò)。文件的查詢涉及命名和查詢路由。文件在系統(tǒng)的命名最好可閱讀的，并且具有一定的區(qū)分性。后者讓不同用戶發(fā)布文件較難產(chǎn)生命名沖突。對(duì)于系統(tǒng)內(nèi)部，對(duì)文件（可能被切分成文件塊）的識(shí)別應(yīng)該是唯一的，可以跟可閱讀的文件名一一對(duì)應(yīng)。另外，不同的用戶可能發(fā)布完全一樣的文件，應(yīng)該被識(shí)別并且利用起來。當(dāng)網(wǎng)絡(luò)中的節(jié)點(diǎn)向路由器一樣連接起來后，每個(gè)節(jié)點(diǎn)根據(jù)本地鄰居信息，以一定的方式將請(qǐng)求和應(yīng)答在分布式系統(tǒng)中傳播，最終使請(qǐng)求發(fā)起者獲得文件的信息。c) 數(shù)據(jù)復(fù)制和傳輸系統(tǒng)中的文件數(shù)據(jù)需要被合理地分配在分布式節(jié)點(diǎn)上。這一點(diǎn)保證系統(tǒng)中的文件以盡可能大的概率存在于網(wǎng)絡(luò)中并且可達(dá)。同時(shí)對(duì)于文件的傳輸請(qǐng)求也可以向傳統(tǒng)P2P網(wǎng)絡(luò)中那樣從多個(gè)目標(biāo)節(jié)點(diǎn)同時(shí)開始。當(dāng)文件被分塊后，文件的結(jié)構(gòu)信息也應(yīng)該被廣泛地分布于整個(gè)網(wǎng)絡(luò)中，以使得被更多的節(jié)點(diǎn)可知。數(shù)據(jù)復(fù)制的觸發(fā)可以放在發(fā)布時(shí)，當(dāng)節(jié)點(diǎn)有可能探測(cè)到文件的復(fù)本可能在網(wǎng)絡(luò)中下降時(shí)，或者很受歡迎被很多人請(qǐng)求時(shí)，也應(yīng)該出發(fā)復(fù)制（在后一種情況中被稱為緩存）。III. 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)為了解決第II部分提出來的幾點(diǎn)問題，設(shè)計(jì)Front網(wǎng)絡(luò)文件系統(tǒng)需要考慮的幾個(gè)模塊的交互。Front系統(tǒng)及節(jié)點(diǎn)的本地結(jié)構(gòu)如圖表一所示。圖表 Front系統(tǒng)節(jié)點(diǎn)的本地結(jié)構(gòu)系統(tǒng)中所共有的Front結(jié)構(gòu)信息在common structures里定義。Front Virtual File System是本地與操作系統(tǒng)的文件系統(tǒng)交互的唯一模塊，它通過將文件分塊，并維持本地文件結(jié)構(gòu)表和本地分塊表，來向上層提供一層虛擬的文件系統(tǒng)。Networking component模塊負(fù)責(zé)與其他節(jié)點(diǎn)的通訊和數(shù)據(jù)傳輸。在FrontVFS和Networking componet之上的一層是Front文件系統(tǒng)的對(duì)外接口FSClientNode。FSClientNode就好像一層中間件，可以向上層提供可以實(shí)現(xiàn)網(wǎng)絡(luò)存儲(chǔ)和共享的文件系統(tǒng)。在我們的實(shí)現(xiàn)中，我們?cè)O(shè)計(jì)了用戶界面來調(diào)用FSClientNode，即實(shí)現(xiàn)了一個(gè)完整的客戶端。關(guān)于每個(gè)模塊的實(shí)現(xiàn)將在第IV部分介紹。IV. 實(shí)現(xiàn)FRONT互聯(lián)網(wǎng)文件存儲(chǔ)與共享系統(tǒng)的實(shí)現(xiàn)，分成以下5個(gè)部分來介紹。A. 命名Front文件系統(tǒng)的命名問題屬于第V部分介紹的Front common structures部分。上文已經(jīng)提到，每個(gè)文件應(yīng)該擁有一個(gè)可閱讀（human readable）的文件路徑。這個(gè)路徑在用戶發(fā)布是制定。有namespace域和systempath域組成。文件系統(tǒng)內(nèi)部使用的定位符(identifier)統(tǒng)一使用128位數(shù)據(jù)來表示。針對(duì)文件的定位符，根據(jù)可閱讀的文件路徑經(jīng)過MD5計(jì)算得到。因此，請(qǐng)求文件的用戶只要知道這個(gè)可閱讀的文件路徑即可發(fā)出請(qǐng)求。針對(duì)文件塊的定位符，根據(jù)文件塊數(shù)據(jù)內(nèi)容經(jīng)過MD5計(jì)算得到。這樣當(dāng)一個(gè)固定的文件被分塊時(shí)，如果能夠保證分塊結(jié)構(gòu)總是一致，那每一塊計(jì)算得到的定位符也是相等的。這個(gè)特性有利于Front系統(tǒng)對(duì)發(fā)布相同文件的識(shí)別和利用。下文將會(huì)提到，F(xiàn)ront VFS對(duì)于相同的文件，分塊的結(jié)果是一致的。B. 本地文件系統(tǒng)FRONT VFSFRONT VFS是建立在操作系統(tǒng)文件系統(tǒng)之上的一層文件系統(tǒng)，用戶與在整個(gè)系統(tǒng)中與FRONT VFS進(jìn)行交互。對(duì)系統(tǒng)中存在的文件我們選擇了對(duì)其進(jìn)行分塊。分塊的好處首先在于一個(gè)節(jié)點(diǎn)存放不下的文件可以分開存儲(chǔ)在多個(gè)節(jié)點(diǎn)上。第二，如果用戶修改某個(gè)文件的一部分，重新發(fā)布時(shí)很可能有的塊并沒有變化，此時(shí)只需發(fā)布更改過的塊即可。第三個(gè)好處在于可以均衡負(fù)載，用戶可以同時(shí)從幾個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上下載不同的塊來達(dá)到加速傳輸?shù)哪康??？紤]下面一種情況：網(wǎng)絡(luò)中有三個(gè)節(jié)點(diǎn)存儲(chǔ)三個(gè)300M的文件，每個(gè)節(jié)點(diǎn)指定的共享空間為300M。那么，如果我們將三個(gè)文件都分成三個(gè)塊，分布在三個(gè)節(jié)點(diǎn)。這樣用戶下載每一個(gè)文件時(shí)都可以從三個(gè)節(jié)點(diǎn)同時(shí)下載三個(gè)塊，比文件不分塊時(shí)必須從單個(gè)節(jié)點(diǎn)下載的情況效率要高。但是，分塊同時(shí)帶來了資源存在的不確定性。如果存放一個(gè)文件的某個(gè)塊的節(jié)點(diǎn)關(guān)機(jī)，系統(tǒng)中又沒有該塊的備份，那么這個(gè)文件就無法被完整獲得。分塊越多分布越廣越容易出現(xiàn)這樣的問題。除了采取一定的復(fù)制策略外，我們的分塊算法也保證一個(gè)文件不要分成太多的塊。根據(jù)文件大小所在的不同區(qū)間，我們對(duì)文件采取不同的分塊策略。分塊算法如下：int chunkSize;int times = 1;int maxChunkNum = chunkNumStart;while(true)if( minChunkSize * times maxChunkSize )chunkSize = maxChunkSize;break;if( fileLength 0，則任選一個(gè)鄰居把FILEQUERY發(fā)送出去。FILEQUERY的發(fā)起節(jié)點(diǎn)在啟動(dòng)RandomWalk之后，啟動(dòng)一個(gè)計(jì)時(shí)器，在這個(gè)時(shí)段內(nèi)系統(tǒng)收集所有的應(yīng)答(FILEREPLY)。每個(gè)應(yīng)答中包含了文件的Chunk列表和本地保存的Chunk的列表。在計(jì)時(shí)器到期時(shí)，如果所有的chunk的信息都已經(jīng)可用，則把結(jié)果顯示到UI；否則再依次搜索每個(gè)未知未知的chunk。搜索chunk的方式也是K-RandomWalk。收到FILEQUERY丟棄FILEQUERY任選鄰居轉(zhuǎn)發(fā)FILEQUERY本地保存有請(qǐng)求的文件信息？FILEQUERY.TTL0？YNYN發(fā)送應(yīng)答FILEQUERY.TTL-圖表 3 FILEQUERY的路由Procedure QueryFile(fileKey)BEGIN FOR i in 0,minK,neighborCount DO BEGINNeighbor = getRandomNeighbor();Send FILEQUERY to neighborENDStart_timer(T_Query, collectQueryResult) /waits T_Query secods and then collect the resultENDProcedure recvFileQueryReply(reply)BEGINMerge reply.availiableChunks to receivedAvailiableChunks;Record chunk locations in receivedAvailiableChunks;ENDProcedure collectQueryResult()BEGINIF has full result THENDisplay result to UIELSE BEGIN Query remaining chunks like file query startTimer(T_chunk_Query, collectQueryResult) ENDEND 根據(jù)引文10的結(jié)論，在K=1664的情況下，K-RandomWalk能夠得到很好的查詢效率。 然而，簡單的K-RandomWalk可能導(dǎo)致一定的低效率，原因包括： K次選擇隨即鄰居有可能重復(fù)選擇； 有可能造成環(huán)狀搜索，即節(jié)點(diǎn)A選擇了鄰居B，B又選擇了A（或者A選擇了B，B選擇了C，C又選擇了A，等等）； 不同的Walker可能遍歷相同的節(jié)點(diǎn)。其中，第一個(gè)問題很容易解決。然而，后面兩個(gè)問題則不那么簡單。事實(shí)上，一個(gè)有意思的研究問題是，如何使得K-Random Walk的效率最高（遍歷的節(jié)點(diǎn)最多）？如何避免重復(fù)經(jīng)過某些節(jié)點(diǎn)？一個(gè)簡單的解決環(huán)狀搜索（第二個(gè)問題）的方法是在Query消息中添加途經(jīng)的節(jié)點(diǎn)列表，然后每個(gè)轉(zhuǎn)發(fā)節(jié)點(diǎn)盡量選擇不在途經(jīng)節(jié)點(diǎn)列表中的鄰居進(jìn)行轉(zhuǎn)發(fā)。然而，更進(jìn)一步，如何使得不同的Walk之間的重疊盡可能的??？我們提出的解決方案是：(1) 為每個(gè)FILEQUERY添加一個(gè)序列號(hào)屬性，每個(gè)FILEQUERY由唯一確定；(2) 添加主動(dòng)HELLO消息，每當(dāng)有FILEQUERY經(jīng)過本節(jié)點(diǎn)時(shí)就廣播主動(dòng)HELLO，主動(dòng)HELLO中包含近期所途經(jīng)的M個(gè)Query消息的，主動(dòng)HELLO的信息也添加到鄰居表中；(3) 節(jié)點(diǎn)在進(jìn)行轉(zhuǎn)發(fā)決策時(shí)，就可以選擇鄰居列表中不曾收到過待轉(zhuǎn)發(fā)請(qǐng)求的節(jié)點(diǎn)進(jìn)行轉(zhuǎn)發(fā)。E. 文件塊的復(fù)制和傳輸當(dāng)用戶發(fā)布文件時(shí)，就需要發(fā)起文件復(fù)制。文件復(fù)制包括了復(fù)制觸發(fā)點(diǎn)、塊傳輸和文件的復(fù)制策略三方面。在設(shè)計(jì)這一部分時(shí)需要考慮到實(shí)現(xiàn)的靈活性和可擴(kuò)展性。首先是復(fù)制觸發(fā)點(diǎn)的設(shè)置。當(dāng)用戶發(fā)布文件時(shí)，顯然需要觸發(fā)文件復(fù)制。然后客戶端需要主動(dòng)地定時(shí)探測(cè)當(dāng)前網(wǎng)絡(luò)該文件的復(fù)制情況，當(dāng)復(fù)本數(shù)長期小于額定值時(shí)，也是需要觸發(fā)文件復(fù)制的。當(dāng)出現(xiàn)替換文件塊時(shí)，就需要主動(dòng)地發(fā)起復(fù)制，最簡單的情況就是將該塊復(fù)制到某個(gè)其它的節(jié)點(diǎn)，但這樣的復(fù)制沒有全局的考慮。如果考慮了整個(gè)文件當(dāng)前的復(fù)制情況的話，就可以收到更好的效果，例如可以請(qǐng)求發(fā)布文件的節(jié)點(diǎn)重新發(fā)起復(fù)制。其次，在考慮塊傳輸時(shí)，有兩種實(shí)現(xiàn)的方法：一種是使用多線程同步Socket的方法，一種是使用異步Socket的方法。使用異步Socket的方法雖然在效率上和多線程相近，但在代碼的簡潔性上顯然不如多線程的方法。因此為了提高塊傳輸?shù)男剩约白非蟠a的簡潔，我們使用了多線程。每個(gè)塊的傳輸都有一個(gè)線程對(duì)應(yīng)，這樣很好的減少了代碼量和代碼的復(fù)雜性。文件復(fù)制時(shí)存在很多的線程同時(shí)在傳輸，這時(shí)就需要有一個(gè)統(tǒng)一的線程來管理這些塊傳輸?shù)木€程。每個(gè)文件復(fù)制的過程由一個(gè)線程控制，而每個(gè)文件塊的傳輸也都由一個(gè)線程負(fù)責(zé)，這樣的實(shí)現(xiàn)可以保證在用戶發(fā)布文件時(shí)，不用長時(shí)間等待文件復(fù)制的完成，就可以進(jìn)行下一步的操作。在實(shí)現(xiàn)之初，文件復(fù)制需要文件的本地分塊完成之后才開始，這樣就要求用戶的本地空間足夠大，顯然這個(gè)要求過于苛刻。為了解決這個(gè)問題，我們需要在用戶本地空間不夠放下整個(gè)文件時(shí)，只要用戶本地空間能都放下最大的文件塊，用戶仍然可以發(fā)布文件。在分塊過程中，如果發(fā)現(xiàn)本地空間不足時(shí)，就需要等待當(dāng)前文件塊復(fù)制完成，再使用相應(yīng)的替換算法替換不必要的文件塊。這樣的實(shí)現(xiàn)既提高了文件復(fù)制的效率，又無需用戶長時(shí)間的等待，還能滿足用戶發(fā)布大文件的需求。再次，可以將文件的復(fù)制策略從文件復(fù)制中剝離出來，通過定義一個(gè)復(fù)制策略的基類，如果需要新的復(fù)制策略時(shí)，只需要繼承這個(gè)基類，實(shí)現(xiàn)其中的方法。這樣就可以在只改變少量代碼的情況下就能實(shí)現(xiàn)擴(kuò)展，定義新的文件復(fù)制策略。在實(shí)現(xiàn)具體的復(fù)制策略時(shí)，需要確定復(fù)制中候選節(jié)點(diǎn)的范圍、復(fù)制節(jié)點(diǎn)的選擇、文件塊在這些節(jié)點(diǎn)的分配策略以及復(fù)制份數(shù)。這些方面并非各自獨(dú)立的，某一方面的決策可能會(huì)影響另一方面的策略。候選節(jié)點(diǎn)的范圍可以是在鄰居節(jié)點(diǎn)或者整個(gè)網(wǎng)絡(luò)。如果是鄰居節(jié)點(diǎn)則較易實(shí)現(xiàn)，如果是在整個(gè)網(wǎng)絡(luò)則需要通過鄰居節(jié)點(diǎn)來試探整個(gè)網(wǎng)絡(luò)，以得到潛在的候選節(jié)點(diǎn)，這些節(jié)點(diǎn)需要能夠均勻的分布在網(wǎng)絡(luò)中。在選擇候選節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)之間的距離（即兩個(gè)節(jié)點(diǎn)間的最短跳數(shù)）是一個(gè)重要的參考，不同距離的節(jié)點(diǎn)就是有代表性的候選節(jié)點(diǎn)。在一個(gè)合理的網(wǎng)絡(luò)中，各種不同距離的節(jié)點(diǎn)可以認(rèn)為是均勻分布的，同時(shí)也考慮了網(wǎng)絡(luò)的連通性，遠(yuǎn)端節(jié)點(diǎn)也覆蓋到了。另外節(jié)點(diǎn)的IP地址也是很好的參考，通過IP地址和子網(wǎng)掩碼可以了解節(jié)點(diǎn)之間的關(guān)系，相同網(wǎng)段的節(jié)點(diǎn)可以認(rèn)為具有較近的地理位置，不同網(wǎng)段的節(jié)點(diǎn)也是有代表性的候選節(jié)點(diǎn)。復(fù)制節(jié)點(diǎn)選擇的復(fù)雜性同候選節(jié)點(diǎn)的范圍有關(guān)，當(dāng)候選節(jié)點(diǎn)的范圍較小時(shí)，復(fù)雜性相對(duì)會(huì)低一點(diǎn)。選擇復(fù)制節(jié)點(diǎn)需要考慮節(jié)點(diǎn)的網(wǎng)絡(luò)帶寬、存儲(chǔ)余額等，網(wǎng)絡(luò)帶寬較大或者存儲(chǔ)余額較大的節(jié)點(diǎn)較易被選中，同時(shí)還需要考慮節(jié)點(diǎn)數(shù)，一種策略是一個(gè)文件復(fù)本應(yīng)盡量在少量的節(jié)點(diǎn)上，以確保文件的可用性。除此之外，選擇有代表性的節(jié)點(diǎn)也是很重要的，能夠考慮整個(gè)網(wǎng)絡(luò)的全局信息，選擇最佳的復(fù)制節(jié)點(diǎn)也是需要考慮的因素。文件塊的分配策略需要考慮到均衡性，盡量保證文件塊均勻的放置在這些節(jié)點(diǎn)中，同時(shí)還需保證相同的文件塊復(fù)本不應(yīng)放在同一個(gè)節(jié)點(diǎn)上。這樣的策略不僅是為了公平而均勻的使用用戶共享的空間，同時(shí)也是基于多線程的考慮，均勻的分配有利于充分利用網(wǎng)絡(luò)帶寬，在盡可能短的時(shí)間內(nèi)完成復(fù)制。考慮到候選節(jié)點(diǎn)的選擇策略，距離較接近的節(jié)點(diǎn)和相同網(wǎng)段的節(jié)點(diǎn)傾向于擁有一個(gè)復(fù)本，當(dāng)然兩個(gè)復(fù)本所占用節(jié)點(diǎn)的交集應(yīng)當(dāng)盡量小，這些節(jié)點(diǎn)往往連通性較好，地理位置較近，這樣即使網(wǎng)絡(luò)出現(xiàn)了問題，在網(wǎng)絡(luò)的某個(gè)局部仍然可以保證文件的可用性。至于復(fù)制份數(shù)，可以根據(jù)當(dāng)前網(wǎng)絡(luò)的大小和網(wǎng)絡(luò)存儲(chǔ)空間的大小來確定，網(wǎng)絡(luò)的大小可以通過探測(cè)節(jié)點(diǎn)之間的距離和網(wǎng)絡(luò)中的節(jié)點(diǎn)數(shù)來獲得，網(wǎng)絡(luò)的大小同節(jié)點(diǎn)之間的距離和網(wǎng)絡(luò)中的節(jié)點(diǎn)數(shù)成正比，當(dāng)然其中節(jié)點(diǎn)數(shù)的比重應(yīng)該更大。節(jié)點(diǎn)數(shù)多、節(jié)點(diǎn)間距離大，那么復(fù)制份數(shù)就可以多一點(diǎn)。網(wǎng)絡(luò)存儲(chǔ)空間的大小可以通過試探各個(gè)節(jié)點(diǎn)的存儲(chǔ)余額來估算。在獲得相當(dāng)數(shù)量的存儲(chǔ)余額后，通過簡單的求平均來得到當(dāng)前網(wǎng)絡(luò)中節(jié)點(diǎn)的平均存儲(chǔ)余額，余額越多，那么復(fù)制份數(shù)就可以越多。V. 性能與相關(guān)工作由于Front文件系統(tǒng)和其它類似系統(tǒng)在應(yīng)用場景的區(qū)別，難以構(gòu)造同樣的環(huán)境對(duì)比。并且由于時(shí)間和網(wǎng)絡(luò)環(huán)境的限制，我們只在3個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)規(guī)模上進(jìn)行了測(cè)試。實(shí)驗(yàn)中文件發(fā)布、復(fù)制和下載功能均得到正確的結(jié)果。在本文之前的大多數(shù)P2P文件系統(tǒng)，例如迅雷、Bt等，都提供的是文件共享的服務(wù)。本文試圖使用文件分塊的技術(shù)提供具有一定擴(kuò)展性的網(wǎng)絡(luò)文件存儲(chǔ)和共享系統(tǒng)。不同于使用DHT結(jié)構(gòu)的一些系統(tǒng)，例如Chord等，F(xiàn)ront系統(tǒng)的設(shè)計(jì)目標(biāo)是盡可能地提供高可靠、高性能的文件服務(wù)，同時(shí)降低對(duì)網(wǎng)絡(luò)負(fù)載的影響。Front文件系統(tǒng)使用文件分塊實(shí)現(xiàn)了一層操作系統(tǒng)文件系統(tǒng)之上的文件層。磁盤上文件的不透明性一定程度上促使用戶向網(wǎng)絡(luò)提供一定比例的空間服務(wù)。Front系統(tǒng)使用Random Walk算法進(jìn)行文件定位，一定程度上降低了網(wǎng)絡(luò)開銷，但查詢的時(shí)間可能會(huì)較長。VI. 總結(jié)和展望從Front文件存儲(chǔ)和共享系統(tǒng)的運(yùn)行試驗(yàn)中我們得知，F(xiàn)ront系統(tǒng)的功能可行，但是由于時(shí)間和測(cè)試的限制，系統(tǒng)在較大網(wǎng)絡(luò)規(guī)模上的性能還未知。之后的一項(xiàng)重要工作是進(jìn)行更多的測(cè)試，發(fā)現(xiàn)系統(tǒng)性能在較大規(guī)模網(wǎng)絡(luò)上的影響因素，并設(shè)計(jì)策略進(jìn)一步提高可用性和性能。其他一些已知的需要改進(jìn)的地方有：1） Front文件系統(tǒng)是只讀的。無法顯式刪除一個(gè)已經(jīng)發(fā)布的文件，以釋放全局空間。2） 文件塊的復(fù)制，需要在更多的情況下觸發(fā)。以避免文件內(nèi)容慢慢地在網(wǎng)絡(luò)中消失。3） 現(xiàn)在的文件定位算法Random Walk，還需要性能