專利名稱：一種基于互聯網的文件分發(fā)系統(tǒng)及方法
技術領域：
本發(fā)明屬于網絡通信技術領域，涉及一種基于互聯網的文件分發(fā)系統(tǒng)及方法。
背景技術：
隨著網絡的普及，一些基于傳統(tǒng)媒介(光盤、磁帶等)的信息(影視、音樂等)逐
漸以網絡作為傳播的媒介。這些網絡資源往往以較大的文件形式出現，供大家下載。方便、
高效且可靠地獲取這類網絡文件是當今網絡技術一個值得探索的課題。隨著連接網絡的
終端數量急劇增加和網絡結構的多樣化與復雜化，傳統(tǒng)的集中式文件分發(fā)模式面臨著伸縮
性、連接突發(fā)性、可控性和可靠性等問題，因此迫切需要研究新的應用模式。 傳統(tǒng)的集中式文件分發(fā)模式如圖一所示。當有一個較大的文件要通過網絡向位置
分散的用戶分發(fā)時，系統(tǒng)會把要發(fā)布的文件上傳到Web服務器或FTP服務器上，然后通知用
戶從該中心服務器下載文件。服務器承擔了全部的上傳(服務器向下載者傳遞文件)開銷，
它的處理能力和傳輸速率是影響文件分發(fā)速度的瓶頸。隨著用戶數量的增多，每個用戶可
獲得的下載速度將會降低，同時服務器也會因負載過大而宕機。因此很多服務器都會限制
用戶人數和下載速度，給用戶帶來諸多不便。 近年來也發(fā)展有根據業(yè)務覆蓋范圍分發(fā)網絡文件的分發(fā)方法，如申請?zhí)枮?200910084776. 5的專利文獻，這種方法雖然緩解了總服務器的開銷和壓力，但增加了大量 的中間服務器，同時也使文件的分發(fā)路徑變得繁瑣，不利于分發(fā)速度的提高。專利申請?zhí)枮?200810103137. 4的專利文獻公開了一種分時下載的方法來減輕服務器的壓力，但這種方法 在減輕服務器壓力的同時也限制了下載的時間，這與用戶想實時下載的意愿相違背，不能 滿足未來的發(fā)展需要。

發(fā)明內容
本發(fā)明所要解決的技術問題是提供一種基于互聯網的文件分發(fā)系統(tǒng)，可緩解文 件分發(fā)服務器的壓力，提高分發(fā)文件的效率和可靠性。 另外，本發(fā)明還提供一種上述基于互聯網的文件分發(fā)系統(tǒng)的文件分發(fā)方法。
為解決上述技術問題，本發(fā)明采用如下技術方案。 —種基于互聯網的文件分發(fā)系統(tǒng)包括中心服務器，至少一關聯服務器，至少一客 戶端；所述中心服務器與至少一個關聯服務器相連，用以從關聯服務器接收文件或向關聯 服務器發(fā)送文件；所述關聯服務器與至少一個客戶端相連，用以向客戶端下發(fā)文件或接受 客戶端上傳的文件；所述客戶端與關聯服務器相連。 作為本發(fā)明的一種優(yōu)選方案，所述客戶端僅連有一個關聯服務器。 作為本發(fā)明的另一種優(yōu)選方案，所述客戶端連有多個關聯服務器。 作為本發(fā)明的再一種優(yōu)選方案，所述系統(tǒng)還包括服務器控制端，所述服務器控制
端分別與中心服務器和關聯服務器相連，用以管理和調度所有服務器的訪問。 作為本發(fā)明的再一種優(yōu)選方案，所述客戶端采用P2P方式與其他客戶端直接通信。
—種基于互聯網的文件分發(fā)方法包括以下步驟 步驟A，客戶端與關聯服務器相連，并向關聯服務器上傳文件； 步驟B，關聯服務器接收客戶端上傳的文件，并將文件上傳至中心服務器； 步驟C，中心服務器從關聯服務器接收文件，并將文件發(fā)送至所有的關聯服務器； 步驟D，客戶端選擇接收或拒絕關聯服務器的文件。 作為本發(fā)明的一種優(yōu)選方案，所述方法的具體步驟為 步驟一，客戶端讀取文件相關信息，生成文件列表數據包上傳到自己所屬的關聯 服務器； 步驟二，自己所屬的關聯服務器根據所述文件列表數據包增加文件列表數據，并 將文件列表數據上傳到中心服務器； 步驟三，中心服務器獲得文件列表數據后，主動向客戶端請求文件； 步驟四，客戶端收到請求后將文件數據上傳至中心服務器； 步驟五，中心服務器將文件數據和文件列表數據分發(fā)給所有關聯服務器； 步驟六，關聯服務器接收完文件數據和文件列表數據后，將文件列表數據分發(fā)給
其下的所有客戶端； 步驟七，客戶端向自己所屬的關聯服務器發(fā)送同意接收文件請求，自己所屬的關 聯服務器向客戶端發(fā)送文件數據。 作為本發(fā)明的另一種優(yōu)選方案，所述方法還包括服務器控制端，所述服務器控制
端分別與中心服務器和關聯服務器相連，用以管理和調度所有服務器的訪問。 作為本發(fā)明的再一種優(yōu)選方案，所述客戶端采用P2P方式與其他客戶端直接通信。 作為本發(fā)明的再一種優(yōu)選方案，所述方法還包括將客戶端文件與服務器文件進行 對比，判斷是否為同一文件；所述對比的方法包括文件名對比，文件大小對比和文件內容對 比。 本發(fā)明的有益效果在于它分發(fā)路徑簡捷，大大緩解了文件分發(fā)服務器的壓力，提 高了分發(fā)文件的效率和可靠性，且支持斷點續(xù)傳，使文件上傳和下載都可以暫?；蚶^續(xù)。


圖1為傳統(tǒng)集中式文件分發(fā)示意圖； 圖2為本發(fā)明的系統(tǒng)結構示意圖； 圖3為實施例3中服務器控制端的連接示意圖； 圖4為實施例4的系統(tǒng)結構示意圖。
具體實施例方式
下面結合附圖對本發(fā)明的具體實施方式
作進一步詳細說明。 對于大量客戶端和大量數據文件時，文件分發(fā)的效率和可靠性將完全依賴服務器
端的處理能力和網絡的帶寬。 實施例一
—種基于互聯網的文件分發(fā)系統(tǒng)包括中心服務器，至少一關聯服務器，至少一客 戶端；所述中心服務器與至少一個關聯服務器相連，用以從關聯服務器接收文件或向關聯 服務器發(fā)送文件；所述關聯服務器與至少一個客戶端相連，用以向客戶端下發(fā)文件或接受 客戶端上傳的文件；所述客戶端與關聯服務器相連。 所述客戶端僅連有一個關聯服務器。所述客戶端連有多個關聯服務器。所述系統(tǒng)
還包括服務器控制端，所述服務器控制端分別與中心服務器和關聯服務器相連，用以管理
和調度所有服務器的訪問。所述客戶端采用P2P方式與其他客戶端直接通信。 —種基于互聯網的文件分發(fā)方法包括以下步驟 步驟A，客戶端與關聯服務器相連，并向關聯服務器上傳文件； 步驟B，關聯服務器接收客戶端上傳的文件，并將文件上傳至中心服務器； 步驟C，中心服務器從關聯服務器接收文件，并將文件發(fā)送至所有的關聯服務器； 步驟D，客戶端選擇接收或拒絕關聯服務器的文件。
所述方法的具體步驟為 步驟一，客戶端讀取文件相關信息，生成文件列表數據包(指把文件列表數據打 成多個包在網絡下傳輸)上傳到自己所屬的關聯服務器； 步驟二，自己所屬的關聯服務器根據所述文件列表數據包增加文件列表數據，并 將文件列表數據上傳到中心服務器； 步驟三，中心服務器獲得文件列表數據后，主動向客戶端請求文件； 步驟四，客戶端收到請求后將文件數據上傳至中心服務器； 步驟五，中心服務器將文件數據和文件列表數據分發(fā)給所有關聯服務器； 步驟六，關聯服務器接收完文件數據和文件列表數據后，將文件列表數據分發(fā)給
其下的所有客戶端； 步驟七，客戶端向自己所屬的關聯服務器發(fā)送同意接收文件請求，自己所屬的關 聯服務器向客戶端發(fā)送文件數據。 所述方法還包括服務器控制端，所述服務器控制端分別與中心服務器和關聯服務 器相連，用以管理和調度所有服務器的訪問。所述客戶端采用P2P方式與其他客戶端直接 通信。所述方法還包括將客戶端文件與服務器文件進行對比，判斷是否為同一文件；所述對 比的方法包括文件名對比，文件大小對比和文件內容對比。
實施例二 本實施例所述方法采用數據傳輸服務端(DTS)和數據傳輸客戶端(DTC)兩端組 成，DTS由一個中心DTS和多個關聯DTS組成，中心DTS包含所有關聯DTS的地址和端口等 信息。 如圖2所示，DTC上傳文件時，先把文件上傳到所屬的關聯DTS，此關聯DTS再把文 件上傳至中心DTS，中心DTS再根據關聯DTS列表把文件傳至各個關聯DTS，關聯DTS再把 自己的文件發(fā)送到下邊的DTC。 DTC在上傳文件時可以指定某些或所有接收者，被指定的接 收者可以選擇接受或者拒絕其他人發(fā)送的文件。本方法提供對同一文件進行重復下載判斷 的功能，本地文件與服務器文件的對比方法不是僅僅靠文件名稱和大小進行比較，還要抽 取內容進行比較，以快速確定本地和服務器的文件是否一致。如對兩個同名、同大小、同類 型的文件進行比較時，對第一個文件隨機抽取一個位置指定大小的數據包，再對另一個文件抽取相同位置相同尺寸的數據包，對這再個數據包進行比較，可重復這個動作多次，來確 認是否是完全一樣的數據包。具體傳輸步驟如下 —、假設數據傳輸客戶端Al要上傳并分發(fā)文件"上傳.txt": 1、 DTC(A1)讀取文件"上傳.txt"相關信息，打包成文件列表數據包上傳給關聯
DTS(A)。 2、關聯DTS(A)增加文件列表數據(包括文件名稱、大小、發(fā)送者等描述信息)，并 將文件列表數據發(fā)送給中心DTS，中心DTS獲得文件列表數據后，主動向DTC(A1)請求文件 "上傳.txt"， DTC(A)把文件上傳至中心DTS。 3、中心DTS接收完成之后，將文件列表數據和文件數據分發(fā)給所有關聯DTS，關聯
DTS接收完文件列表數據和文件數據后，把文件列表數據分發(fā)給其下的所有DTC。 二、假設數據傳輸客戶端Bl要接收分發(fā)的文件"下載.txt":DTC(B1)向關聯DTS(B)發(fā)送同意接收"下載.txt"文件的請求，關聯DTS(B)向
DTC(B1)發(fā)送文件數據。 實施例三 本實施例所述方法可對上傳和下載進行速度控制，如圖3所示，在DTS_AMIN端 (即服務器管理端)可對每個DTS進行管理，設定下邊的DTC上傳、下載的速度，保證帶寬得 到合理、最大化利用。為保證數據統(tǒng)一，所有DTS的訪問由DTS—A匿IN進行管理和調度。當 DTS請求訪問DTC時，DTS_AMIN統(tǒng)一放入緩存隊列，再由一個線程逐一取得，最后才執(zhí)行訪 問DTC命令，并把結果回調給各個DTS。
實施例四 如圖4所示，我們可采用P2P (peer-to-peer,點對點)方式，讓每個工作站作為接
收客戶端，同時又作為發(fā)送服務端，這樣更能大大緩解服務器端的壓力。 這里本發(fā)明的描述和應用是說明性的，并非想將本發(fā)明的范圍限制在上述實施例
中。這里所披露的實施例的變形和改變是可能的，對于那些本領域的普通技術人員來說實
施例的替換和等效的各種部件是公知的。本領域技術人員應該清楚的是，在不脫離本發(fā)明
的精神或本質特征的情況下，本發(fā)明可以以其他形式、結構、布置、比例，以及用其他元件、
材料和部件來實現。
權利要求
一種基于互聯網的文件分發(fā)系統(tǒng)，其特征在于，包括中心服務器，與至少一個關聯服務器相連，用以從關聯服務器接收文件或向關聯服務器發(fā)送文件；至少一關聯服務器，與至少一個客戶端相連，用以向客戶端下發(fā)文件或接受客戶端上傳的文件；至少一客戶端，與關聯服務器相連。
2. 根據權利要求1所述的基于互聯網的文件分發(fā)系統(tǒng)，其特征在于所述客戶端僅連 有一個關聯服務器。
3. 根據權利要求1所述的基于互聯網的文件分發(fā)系統(tǒng)，其特征在于所述客戶端連有 多個關聯服務器。
4. 根據權利要求1所述的基于互聯網的文件分發(fā)系統(tǒng)，其特征在于所述系統(tǒng)還包括 服務器控制端，所述服務器控制端分別與中心服務器和關聯服務器相連，用以管理和調度 所有服務器的訪問。
5. 根據權利要求1所述的基于互聯網的文件分發(fā)系統(tǒng)，其特征在于所述客戶端采用 P2P方式與其他客戶端直接通信。
6. —種基于互聯網的文件分發(fā)方法，其特征在于，包括以下步驟 步驟A，客戶端與關聯服務器相連，并向關聯服務器上傳文件；步驟B，關聯服務器接收客戶端上傳的文件，并將文件上傳至中心服務器；步驟C，中心服務器從關聯服務器接收文件，并將文件發(fā)送至所有的關聯服務器；步驟D，客戶端選擇接收或拒絕關聯服務器的文件。
7. 根據權利要求6所述的基于互聯網的文件分發(fā)方法，其特征在于所述方法的具體 步驟為步驟一，客戶端讀取文件相關信息，生成文件列表數據包上傳到自己所屬的關聯服務器；步驟二，自己所屬的關聯服務器根據所述文件列表數據包增加文件列表數據，并將文件列表數據上傳到中心服務器；步驟三，中心服務器獲得文件列表數據后，主動向客戶端請求文件；步驟四，客戶端收到請求后將文件數據上傳至中心服務器；步驟五，中心服務器將文件數據和文件列表數據分發(fā)給所有關聯服務器；步驟六，關聯服務器接收完文件數據和文件列表數據后，將文件列表數據分發(fā)給其下的所有客戶端；步驟七，客戶端向自己所屬的關聯服務器發(fā)送同意接收文件請求，自己所屬的關聯服 務器向客戶端發(fā)送文件數據。
8. 根據權利要求6所述的基于互聯網的文件分發(fā)方法，其特征在于所述方法還包括 服務器控制端，所述服務器控制端分別與中心服務器和關聯服務器相連，用以管理和調度 所有服務器的訪問。
9. 根據權利要求6所述的基于互聯網的文件分發(fā)方法，其特征在于所述客戶端采用 P2P方式與其他客戶端直接通信。
10. 根據權利要求6所述的基于互聯網的文件分發(fā)方法，其特征在于所述方法還包括將客戶端文件與服務器文件進行對比，判斷是否為同一文件；所述對比的方法包括文件名 對比，文件大小對比和文件內容對比。
全文摘要
本發(fā)明公開了一種基于互聯網的文件分發(fā)系統(tǒng)及方法，該系統(tǒng)包括中心服務器，至少一關聯服務器，至少一客戶端；所述中心服務器與至少一個關聯服務器相連，用以從關聯服務器接收文件或向關聯服務器發(fā)送文件；所述關聯服務器與至少一個客戶端相連，用以向客戶端下發(fā)文件或接受客戶端上傳的文件；所述客戶端與關聯服務器相連。本發(fā)明它分發(fā)路徑簡捷，大大緩解了文件分發(fā)服務器的壓力，提高了分發(fā)文件的效率和可靠性，且支持斷點續(xù)傳，使文件上傳和下載都可以暫?；蚶^續(xù)。
文檔編號H04L29/06GK101699816SQ20091019891
公開日2010年4月28日 申請日期2009年11月17日 優(yōu)先權日2009年11月17日
發(fā)明者牛興盛 申請人:上海華平信息技術股份有限公司