專利名稱：數(shù)據(jù)傳輸?shù)姆椒跋到y(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，特別是數(shù)據(jù)傳輸?shù)姆椒跋到y(tǒng)。
背景技術(shù)：
數(shù)字摘要(digital digest)又稱為安全Hash編碼法(SHA Secure Hash Algorithm)。該編碼法采用單向Hash函數(shù)將需加密的明文"摘要"成一串 128bit的密文，這一串密文亦稱為數(shù)字指紋(FingerPrint)。且不同的明文 摘要成密文，其結(jié)果總是不同的，這樣這串摘要便可成為驗(yàn)證明文是否是"真 身"的"指紋"了。
采用數(shù)字摘要技術(shù)將任意長度的文件變成固定長度的短消息，它類似于 一個自變量是文件數(shù)據(jù)的函數(shù)，也就是Hash函數(shù)。 一個Hash函數(shù)的好壞是 由發(fā)生碰撞的概率決定的。如果攻擊者能夠輕易地構(gòu)造出兩個文件具有相同 的Hash值，那么這樣的Hash函數(shù)是很危險的。 一般來說，安全Hash標(biāo)準(zhǔn) 的輸出長度為160位，這樣才能保證它足夠的安全。
在目前現(xiàn)有的客戶端向服務(wù)器端上傳文件的方法中，服務(wù)器端除了進(jìn)行 簡單的內(nèi)容過濾外，是不會對上傳文件進(jìn)行標(biāo)識和識別的。例如A客戶端 創(chuàng)建了一個名為a.mp3的文件，并上傳給服務(wù)器，服務(wù)器對其存儲備份；之 后B客戶端創(chuàng)建了一個名為b,mp3的文件，雖然名稱不同，但內(nèi)容與a.mp3 完全一致，服務(wù)器對該文件的合法性進(jìn)行驗(yàn)證后，同樣進(jìn)行存儲備份。這樣 的方法所帶來的問題是
名稱不同但內(nèi)容相同的文件占據(jù)了大量的存儲空間，造成極大數(shù)據(jù)冗余 和空間浪費(fèi)；
客戶端在上傳服務(wù)器端已有文件的過程中，占用了較大帶寬，這又是對網(wǎng)絡(luò)資源的浪費(fèi)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供數(shù)據(jù)傳輸?shù)姆椒跋到y(tǒng)，用于減小數(shù) 據(jù)冗余和網(wǎng)絡(luò)資源的浪費(fèi)。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種數(shù)據(jù)傳輸?shù)姆椒ǎ蛻舳嗽诒４嫖?br> 件數(shù)據(jù)時，包括以下步驟
客戶端將所述文件數(shù)據(jù)的數(shù)字摘要上傳給服務(wù)器，服務(wù)器根據(jù)數(shù)據(jù)摘 要，獲取是否存在與所述文件數(shù)據(jù)具有相同數(shù)據(jù)內(nèi)容的文件數(shù)據(jù)的信息，如 果存在，則不需客戶端上傳所述數(shù)據(jù)文件，直接指示客戶端上傳結(jié)束。
本發(fā)明還提供了 一種數(shù)據(jù)傳輸?shù)南到y(tǒng)，包括客戶端和服務(wù)器端兩部分， 其中，客戶端包括
數(shù)字摘要創(chuàng)建模塊，用于創(chuàng)建文件數(shù)據(jù)的數(shù)字摘要；
數(shù)字摘要上傳模塊，用于將所述數(shù)字摘要上傳到服務(wù)器端； 文件數(shù)據(jù)傳輸模塊，用于向服務(wù)器端上傳文件數(shù)據(jù)； 服務(wù)器端包括
數(shù)字摘要檢索分析模塊，用于接收所述客戶端上傳的數(shù)字摘要，并獲取 是否存在具有相向數(shù)字摘要的文件數(shù)據(jù)的信息；
上傳判決模塊，用于根據(jù)所述信息，確定客戶端是否上傳所述數(shù)據(jù)文件；
存儲器，用于保存數(shù)據(jù)文件的內(nèi)容及其數(shù)字摘要。
本發(fā)明通過比對文件數(shù)據(jù)的數(shù)字摘要，避免重復(fù)保存內(nèi)容相同的文件數(shù) 據(jù)，減少了服務(wù)器端存儲空間的占用，提高網(wǎng)絡(luò)帶寬利用率?？蛻舳嗽谙螺d 文件時，可通過P2P傳輸，直接從其它擁有數(shù)據(jù)且在線的客戶端上下載，從 而減少了對服務(wù)器的訪問負(fù)栽。本發(fā)明進(jìn)一步通過對消息和數(shù)據(jù)加密，提高 傳輸?shù)陌踩浴?br>

圖1為本發(fā)明的實(shí)施例中客戶端上傳文件數(shù)據(jù)的方法流程圖2為本發(fā)明的實(shí)施例中客戶端上傳文件數(shù)據(jù)后的映射關(guān)系結(jié)構(gòu)圖3為本發(fā)明的實(shí)施例中客戶端下載文件數(shù)據(jù)的方法流程圖4為本發(fā)明的實(shí)施例中其它客戶端上傳文件數(shù)據(jù)后的映射關(guān)系結(jié)構(gòu)
圖5為本發(fā)明的實(shí)施例中服務(wù)器端維護(hù)的某一客戶端保存的文件數(shù)據(jù) 信息的結(jié)構(gòu)圖6為本發(fā)明的實(shí)施例中數(shù)據(jù)傳輸系統(tǒng)的結(jié)構(gòu)圖。
具體實(shí)施例方式
本發(fā)明的實(shí)施例通過比對數(shù)據(jù)文件的數(shù)字摘要，避免重復(fù)保存內(nèi)容相同 的文件，減少了服務(wù)器端存儲空間的占用，提高網(wǎng)絡(luò)帶寬利用率。在下栽文 件時，通過P2P傳輸，減少了對服務(wù)器的訪問負(fù)栽。
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面結(jié)合附圖對本發(fā)明 作進(jìn)一步的詳細(xì)描述。其中，上傳方法如圖l所示
步驟IOI、發(fā)送端創(chuàng)建數(shù)據(jù)文件，并為該數(shù)據(jù)文件生成數(shù)字摘要?？蛻?端A創(chuàng)建了一個名為a.mp3的數(shù)據(jù)文件，保存于"目錄1/a.mp3"下，create a,mp3。并依據(jù)一定的算法為該文件生成數(shù)字摘要hash (a,mp3)。
生成數(shù)字摘要的哈希函數(shù)的安全性直接關(guān)系到數(shù)字摘要的安全性，如果 哈希函數(shù)被攻破，數(shù)字摘要的有效性就會受到質(zhì)疑.
目前，已經(jīng)發(fā)明的Hash函數(shù)有多種，如Snefru、 N-Hash、 LOKI、 AR、 GOST、 MD、 SHA等。它們在數(shù)學(xué)上實(shí)現(xiàn)的方法各有不同，安全性也各有 不同。目前比較常用的Hash函數(shù)是MD5和SHA-1。 MD5哈希函數(shù)以512 位來處理輸入數(shù)據(jù)，每一分組又劃分為16個32位的子分組。算法的輸出由 4個32位分組組成，將它們級聯(lián)起來，形成一個128位的固定長度的哈希 值，即輸入數(shù)據(jù)的摘要.SHA-1哈希函數(shù)在MD4的基礎(chǔ)上增加了數(shù)學(xué)運(yùn)算的復(fù)雜程度，即SHA-MD4+擴(kuò)展轉(zhuǎn)換+附加輪+更好的雪崩效應(yīng)(哈希值中， 為0的比特和為1的比特，其總數(shù)應(yīng)該大致相等；輸入數(shù)據(jù)中一個比特的變 化，將導(dǎo)致哈希值中一半以上的比特變化，這就叫做雪崩效應(yīng))。SHA能 夠產(chǎn)生160位的哈希值。對SHA還沒有已知的密碼攻擊，并且由于它產(chǎn)生 的哈希值位數(shù)長于MD5，所以它能更有效地抵抗窮舉攻擊。
但是，任何一種算法都有其漏洞和局限性。任何一個哈希函數(shù)都會存在 碰撞，即在一些特定椅況下，兩個不同的文件或信息會指向同一個數(shù)字摘要。 在一般情況下，類似碰撞只能盡可能地減少，而不能完全避免。
采用密碼技術(shù)對信息加密，是最常用的安全交易手段，在電子商務(wù)中獲 得廣泛應(yīng)用的加密技術(shù)是公共密鑰和私用密鑰(public key and private key ) 在加密應(yīng)用時，某個用戶總是將一個密鑰公開，讓需發(fā)信的人員將信息用公 共密鑰加密后發(fā)給該用戶，而一旦信息加密后，只有該用戶一個人知道的私 用密鑰才能解密。具有數(shù)字憑證身份的人員的公共密鑰可在網(wǎng)上查到，亦可 在請對方發(fā)信息時主動將公共密鑰傳給對方，這樣保證在Internet上傳輸信 息的保密和安全。
為了避免數(shù)字摘要在傳輸過程中被截獲和破譯，在本發(fā)明的較佳實(shí)施例 中，將數(shù)字摘要和密鑰加密兩種方法結(jié)合起來使用?？梢赃M(jìn)一步在摘要發(fā)送 端使用對稱密鑰來加密數(shù)字摘要，然后將此對稱密鑰用接收者的公鑰加密， 稱為加密數(shù)據(jù)的"數(shù)字信封"，將其和加密數(shù)字摘要一起發(fā)送給接收者，接 收者先用自己的私鑰解密數(shù)字信封，得到對稱密鑰，然后使用對稱密鑰解密 數(shù)字摘要。
服務(wù)器端的文件系統(tǒng)創(chuàng)建所述數(shù)據(jù)文件時，發(fā)送端應(yīng)將相應(yīng)數(shù)據(jù)文件上 傳i具體執(zhí)行以下步驟
步驟l02、發(fā)送端向服務(wù)器端發(fā)送創(chuàng)建文件請求及上傳數(shù)據(jù)請求?？蛻?端A將包含"目錄l/a、mp3"的創(chuàng)建文件請求發(fā)送給服務(wù)器severl,并發(fā)送 包含hash(a.mp3)的上傳a，mp3的上傳數(shù)據(jù)請求。在較佳實(shí)施例中，發(fā)送 的是加密的hash (a.mp3)和數(shù)字信封。在具體應(yīng)用中，這兩個消息可以合并，在一個消息中發(fā)送。
步驟103、服務(wù)器接收到所述創(chuàng)建文件請求后，在用戶文件信息系統(tǒng)中 創(chuàng)建指定文件；在接收到上傳數(shù)據(jù)請求時，檢索該數(shù)字摘要hash(a.mp3), 根據(jù)數(shù)字摘要定位服務(wù)器上是否存在與欲傳輸?shù)奈募?nèi)容相同的文件數(shù)據(jù)， 如果有，指示客戶端上傳結(jié)束，建立文件名和文件內(nèi)容所在位置的映射關(guān)系。 結(jié)束本流程(在本發(fā)明的較佳實(shí)施例中，如果具有相同數(shù)字摘要的文件名稱 為b.mp3，服務(wù)器端可以記錄"目錄1/ a.nip3"，建立"目錄1/ a.mp3"和 該文件數(shù)字摘要之間的映射關(guān)系)；否則，執(zhí)行步驟104。
步驟104、服務(wù)器通知發(fā)送端上傳數(shù)據(jù)文件。severl向客戶端A發(fā)送請 求數(shù)據(jù)消息，指示A發(fā)送a.mp3數(shù)據(jù)內(nèi)容。
步驟105、發(fā)送端上傳數(shù)據(jù)文件?？蛻舳薃將a.mp3的數(shù)據(jù)內(nèi)容發(fā)送給 服務(wù)器。severl接收到文件后進(jìn)行保存，并建立a.mp3在服務(wù)器端的存儲地 址、目錄1/ a.mp3和hash ( a.mp3 )之間的映射關(guān)系，具體是所述存儲地址 和目錄1/ a.mp3的映射，及所述存儲地址和hash ( a.mp3 )的映射。severl 并不一定要將a.mp3保存在本地，也可保存在備份服務(wù)器Storage Server中， 此時應(yīng)建立其存儲地址locate ID、目錄1/ a.mp3和hash ( a.mp3 )之間的映 射關(guān)系。該映射關(guān)系如圖2所示，具體是locateID和目錄1/a,mp3的映射， locate ID和hash的映射。
在應(yīng)用中，客戶端A在刪除文件時，應(yīng)通知服務(wù)器刪除目錄l/a.mp3， 以及目錄1/ a,mp3和locate ID的關(guān)聯(lián)。如果發(fā)現(xiàn)locate ID沒有和任何文件 目錄信息關(guān)聯(lián)，則刪除locate ID所代表的文件。
以上流程是發(fā)送端用戶向服務(wù)器端上傳數(shù)據(jù)文件的流程，在上傳過程 中，會存在兩種情況即該文件是第一次上傳，服務(wù)器中并無相同文件存在； 另一種情況是服務(wù)器中已保存有該文件，即使文件名稱不一致，服務(wù)器端也 可通過數(shù)字摘要判斷出來，從而拒絕發(fā)送端重復(fù)上傳已有的文件。
通過該流程，能夠有效避免不同發(fā)送端重復(fù)上傳相同文件，從而節(jié)省服 務(wù)器端的存儲空間；另外，發(fā)送端想要上傳已有文件時，僅僅發(fā)送了該文件的數(shù)字摘要，數(shù)字摘要由于其體量很小(如128位的哈希值)，只占用極小 帶寬，節(jié)約了網(wǎng)絡(luò)資源。
此外，在步驟103中，如果發(fā)現(xiàn)存在相同的數(shù)字摘要，有時并不一定表 明其文件數(shù)據(jù)也相同，因?yàn)閿?shù)字摘要是存在碰撞可能的，例如較短的數(shù)字摘 要發(fā)生碰撞的幾率是相對較高的。雖然這是一個極小概率事件，但會造成嚴(yán) 重的后果，比如用戶信息的泄漏。例如，客戶端A想要上傳數(shù)據(jù)，但通過 數(shù)字摘要的驗(yàn)證，發(fā)現(xiàn)用戶B中存在具有相同數(shù)字摘要的文件，但實(shí)際的文 件內(nèi)容不同。于是客戶端A結(jié)束上傳，并在隨后的某一時刻清空緩存，丟 失了欲上傳的數(shù)據(jù)。當(dāng)客戶端再次需要獲取該數(shù)據(jù)時，通過發(fā)送請求，從服 務(wù)器端獲得了用戶B對應(yīng)文件的地址，并錯誤地下栽了用戶B的數(shù)據(jù)，而 該數(shù)據(jù)對用戶B來講，可能是對安全性要求較高的敏感數(shù)據(jù)。另外，也可能 存在客戶端惡意偽造數(shù)字摘要，以竊取其他用戶文件數(shù)據(jù)，或者破壞系統(tǒng)正 常運(yùn)行的潛在危險。
這種情況在本發(fā)明的較佳實(shí)施例中，是可以進(jìn)一步避免的，即通it^:戶 端和服務(wù)器之間的進(jìn)一步校驗(yàn)，校驗(yàn)文件數(shù)據(jù)的有效性，是否數(shù)據(jù)內(nèi)容確實(shí) 相同；如果進(jìn)一步校驗(yàn)失敗，文件內(nèi)容并不相同，此時，則請求下一個具有 同樣hash值的文件，同樣進(jìn)一步校驗(yàn)，直到確認(rèn)沒有相同文件為止，這時 候才繼續(xù)上傳數(shù)據(jù)。進(jìn)一步校驗(yàn)的方法可以是客戶端向服務(wù)器發(fā)送更為詳 細(xì)的校驗(yàn)信息，由服務(wù)器負(fù)責(zé)進(jìn)一步驗(yàn)證；或客戶端請求更為詳細(xì)的檢驗(yàn)信 息，由客戶端進(jìn)一步驗(yàn)證，或者是雙方交換校驗(yàn)信息，由雙方共同驗(yàn)證。所 述更為詳細(xì)的校驗(yàn)信息，包括但不僅限于使用更高強(qiáng)度的hash算法算出 的hash值；對文件內(nèi)容進(jìn)行分塊(segment)，并且對每個子塊分別計算hash 值。 一種特殊的情況，所述更為詳細(xì)的校驗(yàn)信息也可以是文件數(shù)據(jù)內(nèi)容本身， 即通過全部文件內(nèi)容進(jìn)行校驗(yàn)，這種方法當(dāng)然可以完全避免碰撞的發(fā)生，但 為保證安全性，應(yīng)將文件數(shù)據(jù)內(nèi)容使用公鑰加密，.
所述的更為詳細(xì)的校驗(yàn)信息，可以是在客戶端發(fā)送請求的時候立即生 成，也可以是在客戶端請求之前已經(jīng)生成并且保存在系統(tǒng)中。例如如果所述更為詳細(xì)的校驗(yàn)信息是指更高強(qiáng)度的hash值，而客戶端直接向服務(wù)器請 求所述hash值時，該hash值可以是其它客戶端以前在上傳文件數(shù)據(jù)時同時 上傳的，也可以是當(dāng)前客戶端請求更為詳細(xì)的校驗(yàn)信息時，根據(jù)文件數(shù)據(jù)計 算而成。
所述客戶端請求更為詳細(xì)的校驗(yàn)信息，可以是客戶直接向服務(wù)器請求， 也可以是客戶端向服務(wù)器請求獲知具有該hash值文件內(nèi)容的( 一個或多個) 客戶端，然后向該(一個或多個)客戶端請求，還可以是兩種模式混合。
在本發(fā)明的較佳實(shí)施例中，能夠?qū)Πl(fā)送端和服務(wù)器端間傳輸?shù)南?nèi)容 加密，保證了安全性。
在本發(fā)明的另 一較佳實(shí)施案例中，客戶端不需要保存文件的數(shù)據(jù)內(nèi)容， 只有當(dāng)需要用到該文件時才向服務(wù)器請求數(shù)據(jù)，把數(shù)據(jù)下栽到客戶端本地緩 存，當(dāng)不需要用到數(shù)據(jù)時，可以把數(shù)據(jù)內(nèi)容從本地緩存刪除，同時通知服務(wù) 器本客戶端不擁有相應(yīng)數(shù)據(jù)內(nèi)容。
在本發(fā)明的另一較佳實(shí)施例中，當(dāng)服務(wù)器端通過數(shù)字摘要獲知發(fā)送端欲 上傳已有文件時，除了中止文件傳輸外，還標(biāo)記該客戶端擁有該文件的數(shù)據(jù) 內(nèi)容，同時服務(wù)器跟蹤并記錄客戶端是否在線的信息，當(dāng)其它客戶端想要下 載該文件時，不僅可以提供從服務(wù)器下栽(從服務(wù)器下栽只是可選的，圖3 中也一樣)，還可通過P2P的方式，將存有該文件數(shù)據(jù)內(nèi)容并且在線的客戶 端信息發(fā)送給所述其它客戶端，所述其它客戶端可以從多個下栽地址下載文 件的不同片段，提高了下栽速度。其具體流程如圖3所示
下載方法
步驟106、客戶端B向服務(wù)器端發(fā)送欲下栽文件的文件名。如該文件名 為b. mp3。該消息同樣可以加密保護(hù)。
步驟107、服務(wù)器端根據(jù)文件名查找該文件的locate ID，通過locate ID 的映射關(guān)系，定位文件數(shù)據(jù)內(nèi)容。(同時定位其他擁有該文件數(shù)據(jù)并且在線 的客戶端，并把這些客戶端信息發(fā)送給請求的客戶端B)
步驟108、客戶端B開始下載數(shù)據(jù)，客戶端B可以從其他擁有數(shù)據(jù)的客戶端(以下稱提供服務(wù)客戶端)下載數(shù)據(jù)，可以從服務(wù)器下載數(shù)據(jù)，也可以 是兩者的組合。較佳的實(shí)施案例是當(dāng)提供服務(wù)客戶端不能提供足夠的下栽速 度時，才從服務(wù)器下栽數(shù)據(jù)，以降低服務(wù)器的負(fù)載。下栽文件數(shù)據(jù)時，可以 從多個提供服務(wù)客戶端同時下載，每個提供服務(wù)客戶端提供文件數(shù)據(jù)的一部 分。下栽文件數(shù)據(jù)時，客戶對文件數(shù)據(jù)進(jìn)行校驗(yàn)，如杲發(fā)現(xiàn)錯誤則對錯誤數(shù)
據(jù)部分進(jìn)行重新傳輸。服務(wù)器端建立與客戶端B的連接，并開始傳輸文件數(shù) 據(jù)內(nèi)容，同時查詢客戶端A是否在線，如果在線，則將客戶端A的地址信 息及"目錄1/a，mp3"發(fā)送給客戶端B。如杲存在多個具有該文件的客戶端， 則選擇發(fā)送部分優(yōu)先級較高的客戶端的相關(guān)信息。
存在一種情況是，客戶端A不一定有文件數(shù)據(jù)內(nèi)容，因?yàn)榭蛻舳薃在 應(yīng)用過程中可能已經(jīng)把本地的數(shù)據(jù)內(nèi)容清理掉了。當(dāng)客戶端A需要a.mp3 的時候，先訪問"目錄l/a.mp3"檢查是否本地存在，如果存在，就直接使 用；否則，就向服務(wù)器請求。如果客戶端A的用戶從別的機(jī)器登陸，那臺 機(jī)器上面只會下栽文件系統(tǒng)信息，即"目錄l/a.mp3"，而數(shù)據(jù)內(nèi)容是在需 要的時候才下栽的，因此，服務(wù)器端需要維護(hù)哪些客戶端在本地保存有文件 數(shù)據(jù)的信息，向某客戶端請求數(shù)據(jù)時，它不僅要在線，還要有數(shù)據(jù)內(nèi)容。圖 5是服務(wù)器端維護(hù)的某一客戶端保存的文件數(shù)據(jù)信息，其中"LocateID"是 文件數(shù)據(jù)內(nèi)容在該客戶端上保存的地址，"是否在線"標(biāo)識該客戶端當(dāng)前是 否在線。
步驟109、客戶端建立與客戶端A的連接，傳輸數(shù)據(jù)，
步驟IIO、服務(wù)器端記錄所述客戶端擁有該文件。
在一種相反的情況中，假設(shè)客戶端B想要上傳文件b. mp3，其內(nèi)容與 a.mp3相同，客戶端B發(fā)送請求后，服務(wù)器發(fā)現(xiàn)文件重復(fù)，于是拒絕B上傳 文件數(shù)據(jù)，并建立新的映射關(guān)系，如圖4所示，并標(biāo)識客戶端B擁有該文件 數(shù)據(jù)內(nèi)容，并記錄圖5的信息。
在以上流程中，請求下栽文件的客戶端可以同時從服務(wù)器端和存有該文 件的其它客戶端下栽數(shù)據(jù)，極大提高了傳輸速度。此外，當(dāng)客戶端之間進(jìn)行P2P傳輸時，如果源端離線，則下載端可繼續(xù)向具有該文件的其它客戶端建
立連接，下栽數(shù)據(jù).
圖6本發(fā)明的數(shù)據(jù)傳輸系統(tǒng)實(shí)施例的結(jié)構(gòu)圖，該系統(tǒng)包括客戶端和服務(wù)
器端兩部分，其中，客戶端包括
數(shù)字摘要創(chuàng)建模塊61，用于創(chuàng)建文件數(shù)據(jù)的數(shù)字摘要； 數(shù)字摘要上傳模塊62,用于將所述數(shù)字摘要上傳到服務(wù)器端； 文件數(shù)據(jù)傳輸模塊63，用于向服務(wù)器端上傳文件數(shù)據(jù)的內(nèi)容； 服務(wù)器端包括
數(shù)字摘要檢索分析模塊64，用于接收所述客戶端的數(shù)字摘要上傳模塊 62上傳的數(shù)字摘要，并獲取是否存在具有相同數(shù)字摘要的文件數(shù)據(jù)的信息；
上傳判決模塊65，用于根據(jù)所述信息，確定客戶端是否上傳所述數(shù)據(jù) 文件的內(nèi)容；
存儲器66，用于保存數(shù)據(jù)文件的內(nèi)容及其數(shù)字摘要。 該系統(tǒng)通過客戶端上傳文件數(shù)據(jù)的數(shù)字摘要，在服務(wù)器端對該數(shù)字摘要 進(jìn)行檢索，判定是否已經(jīng)保存了相同內(nèi)容的文件數(shù)據(jù)，如果有的話，就無需 客戶端再重復(fù)上傳數(shù)據(jù)，從而節(jié)約了服務(wù)器的存儲空間，并減少了對網(wǎng)絡(luò)資 源的占用。
為提高消息和數(shù)據(jù)傳輸?shù)陌踩?，該系統(tǒng)的服務(wù)器端和客戶端還可以進(jìn) 一步包括
加解密單元67，用于對發(fā)送和接收到的消息以及其它數(shù)據(jù)進(jìn)行加密和 解密。
此外，為保證接收數(shù)據(jù)的有效性，該系統(tǒng)的客戶端還可以進(jìn)一步包括
數(shù)據(jù)校驗(yàn)單元68，用于對接收到的文件數(shù)據(jù)進(jìn)行校驗(yàn)，
圖6僅為本系統(tǒng)的一個較佳實(shí)施例，即所有消息和數(shù)據(jù)都通過加解密單
元進(jìn)行傳輸，以提高傳輸安全性。
總之，以上所述僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的
保護(hù)范圍。
權(quán)利要求
1、一種數(shù)據(jù)傳輸?shù)姆椒?，客戶端在保存文件?shù)據(jù)時，其特征在于，包括以下步驟客戶端將所述文件數(shù)據(jù)的數(shù)字摘要上傳給服務(wù)器，服務(wù)器根據(jù)數(shù)字摘要，獲取是否存在與所述文件數(shù)據(jù)具有相同數(shù)據(jù)內(nèi)容的文件數(shù)據(jù)的信息，如果存在，則不需客戶端上傳所述數(shù)據(jù)文件，直接指示客戶端上傳結(jié)束。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述將數(shù)字摘要上傳給 服務(wù)器具體包括客戶端向服務(wù)器發(fā)送創(chuàng)建文件請求及上傳數(shù)據(jù)請求，所述上傳數(shù)據(jù)請求 包括所述文件數(shù)據(jù)的數(shù)字摘要。
3、 根據(jù)權(quán)利要求2所述的方法，其特征在于，該方法進(jìn)一步包括對所 述數(shù)字摘要加密。
4、 根據(jù)權(quán)利要求2或3所述的方法，其特征在于，所述服務(wù)器獲取信 息進(jìn)一步包括服務(wù)器接收到所述創(chuàng)建文件請求后，創(chuàng)建指定文件；服務(wù)器接收到所述上傳數(shù)據(jù)請求后，檢索所述數(shù)字摘要，定位本地是否 存在與所述文件數(shù)據(jù)內(nèi)容相同的文件數(shù)據(jù)，如果不存在，則通知客戶端上傳 所述文件數(shù)據(jù)。
5、 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述通知客戶端上傳文 件數(shù)據(jù)進(jìn)一步包括服務(wù)器向客戶端發(fā)送請求數(shù)據(jù)消息； 客戶端將文件數(shù)據(jù)發(fā)送給服務(wù)器；服務(wù)器接收到文件數(shù)據(jù)后進(jìn)行保存，并建立所述文件數(shù)據(jù)在服務(wù)器上的 存儲地址、文件名及文件數(shù)據(jù)的數(shù)字摘要之間的映射關(guān)系，并指示客戶端上 傳結(jié)束。
6、 根據(jù)權(quán)利要求4所述的方法，其特征在于，該方法進(jìn)一步包括如果存在與所述文件數(shù)據(jù)內(nèi)容相同的文件數(shù)據(jù)，則指示客戶端上傳結(jié)束，建立所述文件數(shù)據(jù)的文件名和文件數(shù)據(jù)內(nèi)容所在位置的映射關(guān)系；或客戶端與服務(wù)器之間進(jìn)行更高強(qiáng)度校驗(yàn)，進(jìn)一步校驗(yàn)所述文件數(shù)據(jù)內(nèi)容 是否相同，如杲是，則指示客戶端上傳結(jié)束，建立所述文件數(shù)據(jù)的文件名和 文件數(shù)據(jù)內(nèi)容所在位置的映射關(guān)系；否則，客戶端上傳文件數(shù)據(jù)。
7、 根據(jù)權(quán)利要求6所述的方法，其特征在于，該方法進(jìn)一步包括所 述客戶端向服務(wù)器請求獲知具有所述文件數(shù)據(jù)內(nèi)容的其它一個或多個客戶 端信息，該客戶端與服務(wù)器和/或所述一個或多個客戶端之間進(jìn)行更高強(qiáng)度 的校驗(yàn)。
8、 根據(jù)權(quán)利要求6所迷的方法，其特征在于，當(dāng)服務(wù)器指示客戶端上 傳結(jié)束后，還要進(jìn)一步標(biāo)記所述客戶端擁有所述文件數(shù)據(jù)內(nèi)容，并持續(xù)跟蹤 記錄該客戶端是否在線的信息；當(dāng)客戶端刪除所述文件數(shù)據(jù)的內(nèi)容時，向服 務(wù)器發(fā)送自己不再擁有所述文件數(shù)據(jù)內(nèi)容的信息。
9、 根據(jù)權(quán)利要求5所述的方法，其特征在于，所述客戶端上傳文件數(shù)據(jù)后，再次訪問該文件時，先檢查所述文件數(shù)據(jù) 內(nèi)容是否在本地存在，如果不存在，則向服務(wù)器請求下栽所述文件數(shù)據(jù)，或 另一客戶端下栽所述文件數(shù)據(jù)時，先檢查所述文件數(shù)據(jù)內(nèi)容是否在本地存在，如果不存在，則向服務(wù)器請求下栽所述文件數(shù)據(jù)， 該方法進(jìn)一步包括客戶端向服務(wù)器發(fā)送欲下載文件數(shù)據(jù)的文件名；服務(wù)器根據(jù)所述文件名查找所述文件數(shù)據(jù)在服務(wù)器上的存儲地址，并根 據(jù)所述存儲地址的映射關(guān)系，定位文件數(shù)據(jù)的內(nèi)容；所述客戶端從擁有所述文件數(shù)據(jù)內(nèi)容的其它一個或多個在線客戶端和/ 或服務(wù)器上下栽文件數(shù)據(jù)。
10、 根據(jù)權(quán)利要求9所述的方法，其特征在于，所迷另一客戶端在下栽 文件數(shù)據(jù)時，對文件數(shù)據(jù)的內(nèi)容進(jìn)行校驗(yàn)，如果發(fā)現(xiàn)錯誤，則對錯誤數(shù)據(jù)部分進(jìn)行重傳。
11、 一種數(shù)據(jù)傳輸?shù)南到y(tǒng)，其特征在于，包括客戶端和服務(wù)器端兩部分，其中，客戶端包括數(shù)字摘要創(chuàng)建模塊，用于創(chuàng)建文件數(shù)據(jù)的數(shù)字摘要； 數(shù)字摘要上傳模塊，用于將所述數(shù)字摘要上傳到服務(wù)器端； 文件數(shù)據(jù)傳輸模塊，用于向服務(wù)器端上傳文件數(shù)據(jù)； 服務(wù)器端包括數(shù)字摘要檢索分析模塊，用于接收所述客戶端上傳的數(shù)字摘要，并獲取 是否存在具有相同數(shù)字摘要的文件數(shù)據(jù)的信息；上傳判決模塊，用于根據(jù)所述信息，確定客戶端是否上傳所述數(shù)據(jù)文件； 存儲器，用于保存數(shù)據(jù)文件的內(nèi)容及其數(shù)字摘要，
12、 根據(jù)權(quán)利要求11所述的系統(tǒng)，其特征在于，該系統(tǒng)的服務(wù)器端和 客戶端進(jìn)一步包括加解密單元，用于對發(fā)送和接收到的消息進(jìn)行加密和解密。
13、 根據(jù)權(quán)利要求11或12所迷的系統(tǒng)，其特征在于，該系統(tǒng)的客戶端 進(jìn)一步包括數(shù)據(jù)校驗(yàn)單元，用于對接收到的文件數(shù)據(jù)進(jìn)行校驗(yàn)。
全文摘要
本發(fā)明公開了一種數(shù)據(jù)傳輸?shù)姆椒ǎ蛻舳嗽诒４嫖募?shù)據(jù)時，包括以下步驟客戶端將所述文件數(shù)據(jù)的數(shù)字摘要上傳給服務(wù)器，服務(wù)器根據(jù)數(shù)據(jù)摘要，獲取是否存在與所述文件數(shù)據(jù)具有相同數(shù)據(jù)內(nèi)容的文件數(shù)據(jù)的信息，如果存在，則不需客戶端上傳所述數(shù)據(jù)文件，直接指示客戶端上傳結(jié)束。本發(fā)明還公開了一種數(shù)據(jù)傳輸?shù)南到y(tǒng)，包括數(shù)字摘要創(chuàng)建模塊、數(shù)字摘要上傳模塊、文件數(shù)據(jù)傳輸模塊、數(shù)字摘要檢索分析模塊、上傳判決模塊及存儲器。本發(fā)明通過比對數(shù)據(jù)文件的數(shù)字摘要，避免重復(fù)保存內(nèi)容相同的文件，減少了服務(wù)器端存儲空間的占用，提高網(wǎng)絡(luò)帶寬利用率。在下載文件時，通過P2P傳輸，減少了對服務(wù)器的訪問負(fù)載。
文檔編號H04L9/32GK101552669SQ20081010327
公開日2009年10月7日 申請日期2008年4月2日 優(yōu)先權(quán)日2008年4月2日
發(fā)明者林兆祥 申請人:林兆祥