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

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