文件傳輸方法、設備及系統(tǒng)的制作方法
【專利摘要】本發(fā)明提供了一種文件傳輸方法、設備及系統(tǒng)。其中,文件傳輸方法包括:根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件;查詢文件上傳服務器中是否已存儲有本文件的部分塊文件;根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳。采用本發(fā)明實施能夠節(jié)約網(wǎng)絡資源,節(jié)省客戶端上傳文件的時間,提高用戶體驗。
【專利說明】文件傳輸方法、設備及系統(tǒng)
【技術領域】
[0001]本發(fā)明涉及互聯(lián)網(wǎng)應用領域,特別是涉及一種文件傳輸方法、設備及系統(tǒng)。
【背景技術】
[0002]目前對文件進行傳輸主要是通過計算文件的哈希值(以下簡稱hash值)比對。如果客戶端準備進行文件傳輸,先行將文件的hash值發(fā)送到服務端進行查詢。如果發(fā)現(xiàn)該hash值在服務端已經(jīng)存在,則客戶端不用上傳該文件,服務器端已存儲有該文件,從而達到加速文件上傳或者秒傳的功能。圖1示出了根據(jù)【背景技術】的文件傳輸方法的處理流程圖。由于該文件傳輸方法通常能夠在秒級別內(nèi)完成文件上傳,因此,也被稱為文件秒傳方法。參見圖1,文件傳輸方法包括步驟S102至步驟SllO:
[0003]步驟S102、客戶端上傳文件hash值至文件上傳服務器;
[0004]步驟S104、文件上傳服務器將hash值發(fā)送至文件消重服務器,查詢該文件是否存在;
[0005]步驟S106、文件消重服務器返回該hash值已存在;
[0006]步驟S108、文件上傳服務器將該文件與客戶端關聯(lián)添加;
[0007]步驟S110、文件上傳服務器通知客戶端文件上傳已完成。
[0008]參見圖1所示流程可知,上述文件傳輸方式所使用的文件秒傳是以文件粒度為級別的控制。對于這種方式,至少存在以下問題:
[0009]當一個文件在未上傳完成時,如果客戶端斷開導致文件終止上傳,那么,當客戶端再次開機后上傳時,對于已經(jīng)上傳的部份,仍需要從頭開始上傳。這極大的浪費了用戶的網(wǎng)絡資源、服務器的帶寬資源,并大大增加了客戶端上傳文件的時間。
【發(fā)明內(nèi)容】
[0010]鑒于上述問題,提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的文件傳輸方法、設備和相應的文件傳輸系統(tǒng)。
[0011]依據(jù)本發(fā)明的一個方面,提供了一種文件傳輸方法,用于將文件從客戶端上傳至文件上傳服務器,該方法包括:根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件;查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件;根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
[0012]可選地,查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件,包括:計算每個塊文件的hash值;將各hash值發(fā)送至文件消重服務器,其中,所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系;查詢所述文件消重服務器中是否存儲有該hash值,若有,則表明所述文件上傳服務器中已存儲有該hash值所對應的塊文件。
[0013]可選地,所述映射關系為一對一的映射關系。
[0014]可選地,所述預設規(guī)則包括:將本文件分為相同塊長的塊文件;或者將本文件分為不同塊長的塊文件。
[0015]依據(jù)本發(fā)明的另一個方面,還提供了一種客戶端,用于把文件上傳至文件上傳服務器,其包括:分塊器,配置為根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件;查詢器,配置為查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件;傳輸器,配置為根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
[0016]可選地,所述查詢器還配置為:計算每個塊文件的hash值;將各hash值發(fā)送至文件消重服務器,其中,所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系;查詢所述文件消重服務器中是否存儲有該hash值,若有,則表明所述文件上傳服務器中已存儲有該hash值所對應的塊文件。
[0017]可選地,其中,所述映射關系為一對一的映射關系。
[0018]可選地,所述分塊器還配置為:將本文件分為相同塊長的塊文件;或者將本文件分為不同塊長的塊文件。
[0019]依據(jù)本發(fā)明的另一個方面,還提供了一種文件傳輸系統(tǒng),包括客戶端以及文件上傳服務器:所述文件上傳服務器,配置為存儲不同客戶端上傳的文件;任一客戶端,配置為根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件;查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件;根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
[0020]可選地,還包括:文件消重服務器,配置為所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系;所述客戶端,還配置為計算每個塊文件的hash值;將各hash值發(fā)送至所述文件消重服務器,查詢所述文件上傳服務器中是否存儲有該hash值對應的塊文件。
[0021]依據(jù)本發(fā)明實施例,客戶端對即將上傳的文件進行分塊之后,客戶端首先查詢文件上傳服務器中是否已存儲有本文件的部分塊文件,其次,客戶端根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,解決了現(xiàn)有技術提到的,當客戶端對已上傳部分文件的文件進行上傳時,仍需要從頭開始上傳文件的問題。本發(fā)明實施例中,客戶端對文件進行傳輸時,能夠僅選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,并不需要對已上傳部分再次進行重傳,達到了節(jié)約網(wǎng)絡資源(包括用戶所使用的網(wǎng)絡資源以及服務器的帶寬資源等)的有益效果,節(jié)省客戶端上傳文件的時間,提高用戶體驗。
[0022]上述說明僅是本發(fā)明技術方案的概述,為了能夠更清楚了解本發(fā)明的技術手段,而可依照說明書的內(nèi)容予以實施,并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂,以下特舉本發(fā)明的【具體實施方式】。
[0023]根據(jù)下文結(jié)合附圖對本發(fā)明具體實施例的詳細描述,本領域技術人員將會更加明了本發(fā)明的上述以及其他目的、優(yōu)點和特征。
【專利附圖】
【附圖說明】
[0024]通過閱讀下文優(yōu)選實施方式的詳細描述,各種其他的優(yōu)點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的,而并不認為是對本發(fā)明的限制。而且在整個附圖中,用相同的參考符號表示相同的部件。在附圖中:[0025]圖1示出了根據(jù)【背景技術】的文件傳輸方法的處理流程圖;
[0026]圖2示出了根據(jù)本發(fā)明一個實施例的文件傳輸方法的處理流程圖;
[0027]圖3示出了根據(jù)本發(fā)明一個實施例的客戶端的結(jié)構(gòu)示意圖;
[0028]圖4示出了根據(jù)本發(fā)明一個實施例的文件傳輸系統(tǒng)的結(jié)構(gòu)示意圖;
[0029]圖5示出了根據(jù)本發(fā)明一個優(yōu)選實施例的文件傳輸方法的處理流程圖;以及
[0030]圖6示出了根據(jù)本發(fā)明另一個優(yōu)選實施例的文件傳輸方法的處理流程圖。
【具體實施方式】
[0031]在此提供的算法和顯示不與任何特定計算機、虛擬系統(tǒng)或者其它設備固有相關。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述,構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外,本發(fā)明也不針對任何特定編程語言。應當明白,可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容,并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。
[0032]相關技術中提及,在一個文件上傳過程中,若客戶端斷開導致文件終止上傳,那么再次上傳時,仍需要從頭開始上傳。這極大地浪費了網(wǎng)絡資源、帶寬資源,并增加客戶端上傳文件的時間。
[0033]為解決上述技術問題,本發(fā)明實施例提供了一種文件傳輸方法,用于將文件從客戶端上傳至文件上傳服務器。圖2示出了根據(jù)本發(fā)明一個實施例的文件傳輸方法的處理流程圖。如圖2所示,該流程至少包括步驟S202到步驟S206。
[0034]步驟S202、客戶端根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件。
[0035]步驟S204、客戶端查詢文件上傳服務器中是否已存儲有本文件的部分塊文件。
[0036]步驟S206、客戶端根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳。
[0037]依據(jù)本發(fā)明實施例,客戶端對即將上傳的文件進行分塊之后,客戶端首先查詢文件上傳服務器中是否已存儲有本文件的部分塊文件,其次,客戶端根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,解決了現(xiàn)有技術提到的,當客戶端對已上傳部分文件的文件進行上傳時,仍需要從頭開始上傳文件的問題。本發(fā)明實施例中,客戶端對文件進行傳輸時,能夠僅選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,并不需要對已上傳部分再次進行重傳,達到了節(jié)約網(wǎng)絡資源(包括用戶所使用的網(wǎng)絡資源以及服務器的帶寬資源等)的有益效果,節(jié)省客戶端上傳文件的時間。
[0038]具體地,如圖2中步驟S202所示,客戶端根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件。本發(fā)明實施例中,客戶端對即將上傳的文件進行分塊所依據(jù)的預設規(guī)則可以是根據(jù)文件內(nèi)容對本文件進行分塊,還可以是根據(jù)文件的大小對本文件進行分塊,本發(fā)明實施例并不對此加以限定。優(yōu)選地,本發(fā)明實施例中,該預設規(guī)則可以是將本文件分為相同塊長的塊文件,還可以是將本文件分為不同塊長的塊文件??蛻舳四軌蚋鶕?jù)具體傳輸路徑、帶寬等信息確定使用哪種預設規(guī)則將本文件分為塊文件。
[0039]當客戶端根據(jù)預設規(guī)則將本文件分為至少兩個塊文件之后,執(zhí)行如圖2所述的步驟S204,客戶端查詢文件上傳服務器中是否已存儲有本文件的部分塊文件。查詢的具體方式有多種,例如,可以在每個塊文件上設置一個可查詢的唯一標識,利用該唯一標識進行查詢,也可以利用每個塊文件的自身的性能及信息進行查詢,等等。
[0040]本發(fā)明實施例提供了一種任選的查詢方式,S卩,利用hash值進行查詢,具體地,客戶端計算每個塊文件的hash值,并將各個塊文件的hash值發(fā)送至文件消重服務器。文件消重服務器接收到每個塊文件的hash值之后,對文件上傳服務器中存儲的塊文件進行消重,并存儲消重后的塊文件與hash值的映射關系??蛻舳瞬樵兾募蟼鞣掌髦惺欠褚汛鎯τ形募牟糠謮K文件時,查詢文件消重服務器中是否存儲有與該塊文件有映射關系的hash值。若文件消重服務器中已存儲有該hash值,則表明文件上傳服務器中已存儲有該hash值所對應的塊文件。
[0041]上文提及,hash值與塊文件間存在映射關系,該映射關系可以預先設置為一對一,或一對多,或多對一,等等。若同一塊文件具備不同的hash值,那么,同一塊文件可能會被多次上傳,造成浪費資源。同理,若不同塊文件具備相同的hash值,則可能造成部分塊文件無法上傳,使得文件數(shù)據(jù)包丟失。因此,本發(fā)明實施例中,文件消重服務器中存儲的塊文件與hash值的可選映射關系為一對一的映射關系。由于塊文件與hash值的映射關系為一對一映射關系,即一個hash值僅代表一個塊文件,則客戶端能夠通過查詢文件消重服務器中是否存儲有與該塊文件對應的hash值判斷該塊文件是否已上傳至文件上傳服務器,減少了查找塊文件的時間,進而提高文件傳輸效率。
[0042]客戶端查詢到文件上傳服務器中已存儲的部分塊文件之后,參見圖2中的步驟S206,客戶端根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳。
[0043]基于上文各優(yōu)選實施例提供的文件傳輸方法,基于同一發(fā)明構(gòu)思,本發(fā)明實施例提供了一種客戶端,用于把文件上傳至文件上傳服務器,以實現(xiàn)上述文件傳輸方法。
[0044]圖3示出了根據(jù)本發(fā)明一個實施例的客戶端的結(jié)構(gòu)示意圖。參見圖3,本發(fā)明實施例的客戶端300至少包括:分塊器310、查詢器320以及傳輸器330。
[0045]現(xiàn)介紹本發(fā)明實施例的客戶端300的各器件或組成的功能以及各部分間的連接關系:
[0046]分塊器310,配置為根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件。
[0047]查詢器320,與分塊器310耦合,配置為查詢文件上傳服務器中是否已存儲有分塊器310分塊得到的即將上傳的文件的部分塊文件。
[0048]傳輸器330,與查詢器320耦合,配置為根據(jù)查詢器320的查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳。
[0049]依據(jù)本發(fā)明實施例,客戶端300對即將上傳的文件進行分塊之后,客戶端300首先查詢文件上傳服務器中是否已存儲有本文件的部分塊文件,其次,客戶端300根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,解決了現(xiàn)有技術提到的,當客戶端300對已上傳部分文件的文件進行上傳時,仍需要從頭開始上傳文件的問題。本發(fā)明實施例中,客戶端300對文件進行傳輸時,能夠僅選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,并不需要對已上傳部分再次進行重傳,達到了節(jié)約網(wǎng)絡資源(包括用戶所使用的網(wǎng)絡資源以及服務器的帶寬資源等)的有益效果,節(jié)省客戶端300上傳文件的時間。
[0050]具體地,如圖3所示,客戶端300中的分塊器310根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件。本發(fā)明實施例中,分塊器310對即將上傳的文件進行分塊所依據(jù)的預設規(guī)則可以是根據(jù)文件內(nèi)容對本文件進行分塊,還可以是根據(jù)文件的大小對本文件進行分塊,本發(fā)明實施例并不對此加以限定。任選地,本發(fā)明實施例中,該預設規(guī)則可以是將本文件分為相同塊長的塊文件,還可以是將本文件分為不同塊長的塊文件??蛻舳?00能夠根據(jù)具體傳輸路徑、帶寬等信息確定使用哪種預設規(guī)則將本文件分為塊文件。
[0051]當分塊器310根據(jù)預設規(guī)則將本文件分為至少兩個塊文件之后,查詢器320執(zhí)行查詢操作,查詢文件上傳服務器中是否已存儲有本文件的部分塊文件。查詢器320查詢的具體過程有多種,例如,可以在每個塊文件上設置一個可查詢的唯一標識,利用該唯一標識進行查詢,也可以利用每個塊文件的自身的性能及信息進行查詢,等等。
[0052]本發(fā)明實施例提供了一種可選的查詢方式,S卩,利用hash值進行查詢,具體地,查詢器320計算每個塊文件的hash值,并將各個塊文件的hash值發(fā)送至文件消重服務器。文件消重服務器接收到每個塊文件的hash值之后,對文件上傳服務器中存儲的塊文件進行消重,并存儲消重后的塊文件與hash值的映射關系。查詢器320查詢文件上傳服務器中是否存儲有本文件的塊文件時,查詢文件消重服務器中是否存儲有與該塊文件有映射關系的hash值。若文件消重服務器中已存儲有該hash值,則表明文件上傳服務器中已存儲有該hash值對應的塊文件。
[0053]上文提及,hash值與塊文件間存在映射關系,該映射關系可以預先設置為一對一,或一對多,或多對一,等等。若同一塊文件具備不同的hash值,那么,同一塊文件可能會被多次上傳,造成浪費資源。同理,若不同塊文件具備相同的hash值,則可能造成部分塊文件無法上傳,使得文件數(shù)據(jù)包丟失。因此,本發(fā)明實施例中,文件消重服務器中存儲的塊文件與hash值的可選映射關系為一對一的映射關系。由于塊文件與hash值的映射關系為一對一映射關系,即一個hash值僅代表一個塊文件,則查詢器320能夠通過查詢文件消重服務器中是否存儲有與該塊文件對應的hash值判斷該塊文件是否已上傳至文件上傳服務器,減少了查找塊文件的時間,進而提高文件傳輸效率。
[0054]查詢器320查詢到文件上傳服務器中已存儲的部分塊文件之后,傳輸器330根據(jù)查詢器320的查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,將本文件傳輸至文件上傳服務器。
[0055]基于上文各優(yōu)選實施例提供的文件傳輸方法以及文件傳輸設備,基于同一發(fā)明構(gòu)思,本發(fā)明實施例還提供了一種文件傳輸系統(tǒng)。圖4示出了根據(jù)本發(fā)明一個實施例的文件傳輸系統(tǒng)的結(jié)構(gòu)示意圖。如圖4所示,本發(fā)明實施例中的文件傳輸系統(tǒng)至少包括:客戶端300、文件上傳服務器400以及文件消重服務器500。
[0056]現(xiàn)介紹本發(fā)明實施例的文件傳輸系統(tǒng)中的各器件或組成的功能以及各部分間的連接關系。文件傳輸系統(tǒng)中的文件上傳服務器400存儲不同客戶端上傳的文件。如圖4所示的客戶端300首先根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件,并查詢文件上傳服務器400中是否已存儲有本文件的部分塊文件。其次,客戶端300根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器400中的部分塊文件進行上傳。
[0057]依據(jù)本發(fā)明實施例,客戶端300對即將上傳的文件進行分塊之后,客戶端300首先查詢文件上傳服務器400中是否已存儲有本文件的部分塊文件,其次,客戶端300根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器400中的部分塊文件進行上傳,解決了現(xiàn)有技術提到的,當客戶端300對已上傳部分文件的文件進行上傳時,仍需要從頭開始上傳文件的問題。本發(fā)明實施例中,客戶端300對文件進行傳輸時,能夠僅選擇未存儲在文件上傳服務器400中的部分塊文件進行上傳,并不需要對已上傳部分再次進行重傳,達到了節(jié)約網(wǎng)絡資源(包括用戶所使用的網(wǎng)絡資源以及服務器的帶寬資源等)的有益效果,節(jié)省客戶端300上傳文件的時間,提聞用戶體驗。
[0058]具體地,如圖4所示,客戶端300中的分塊器310根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件。本發(fā)明實施例中,分塊器310對即將上傳的文件進行分塊所依據(jù)的預設規(guī)則可以是根據(jù)文件內(nèi)容對本文件進行分塊,還可以是根據(jù)文件的大小對本文件進行分塊,本發(fā)明實施例并不對此加以限定。優(yōu)選地,本發(fā)明實施例中,該預設規(guī)則可以是將本文件分為相同塊長的塊文件,還可以是將本文件分為不同塊長的塊文件??蛻舳?00能夠根據(jù)具體傳輸路徑、帶寬等信息確定使用哪種預設規(guī)則將本文件分為塊文件。
[0059]當分塊器310根據(jù)預設規(guī)則將文件分為至少兩個塊文件之后,查詢器320查詢文件上傳服務器400中是否已存儲有文件的部分塊文件。查詢器320查詢的具體過程有多種,例如,可以在每個塊文件上設置一個可查詢的唯一標識,利用該唯一標識進行查詢,也可以利用每個塊文件的自身的性能及信息進行查詢,等等。
[0060]本發(fā)明實施例提供了一種優(yōu)選的查詢方式,S卩,利用hash值進行查詢,具體地,查詢器320計算每個塊文件的hash值,并將各個塊文件的hash值發(fā)送至文件消重服務器500。文件消重服務器500接收到每個塊文件的hash值之后,對文件上傳服務器400中存儲的塊文件進行消重,并存儲消重后的塊文件與hash值的映射關系。查詢器320查詢文件上傳服務器400是否存儲有文件的塊文件時,查詢文件消重服務器500中是否存儲有與該塊文件有映射關系的hash值。若文件消重服務器500中已存儲有該hash值,則表明文件上傳服務器400中已存儲有該hash值對應的塊文件。
[0061]上文提及,hash值與塊文件間存在映射關系,該映射關系可以預先設置為一對一,或一對多,或多對一,等等。若同一塊文件具備不同的hash值,那么,同一塊文件可能會被多次上傳,造成浪費資源。同理,若不同塊文件具備相同的hash值,則可能造成部分塊文件無法上傳,使得文件數(shù)據(jù)包丟失。因此,本發(fā)明實施例中,文件消重服務器500中存儲的塊文件與hash值的優(yōu)選映射關系,即一個hash值僅代表一個塊文件,則查詢器320能夠通過查詢文件消重服務器500中是否存儲有與該塊文件對應的hash值判斷該塊文件是否已上傳至文件上傳服務器400,減少了查找塊文件的時間,進而提高文件傳輸效率。
[0062]查詢器320查詢到文件上傳服務器400中已存儲的部分塊文件之后,傳輸器330根據(jù)查詢器320的查詢結(jié)果選擇未存儲在文件上傳服務器400中的部分塊文件進行上傳,將文件傳輸至文件上傳服務器400。文件上傳服務器400存儲不同客戶端上傳的文件。
[0063]實施例一
[0064]圖5示出了根據(jù)本發(fā)明一個優(yōu)選實施例的文件傳輸方法的流程圖,用于支持上述任意一個文件傳輸方法、設備及系統(tǒng),將上述文件傳輸方法、設備及系統(tǒng)闡述得更清楚明白。需要注意的是,圖5所示的文件傳輸方法為上傳一個文件上傳服務器中不存在的文件的流程圖。
[0065]如圖5所示,客戶端根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件??蛻舳藢⒓磳⑸蟼鞯奈募譃橹辽賰蓚€塊文件之后,執(zhí)行如圖5所示的步驟S501,計算每個塊文件的hash值,并將各個塊文件的hash值上傳至文件上傳服務器,由文件上傳服務器發(fā)送hash值至文件消重服務器,通過hash值查看文件上傳服務器中是否存在本文件的塊文件。文件消重服務器接收到每個塊文件的hash值之后,執(zhí)行步驟S502,查詢是否存在每個塊文件的hash值,并執(zhí)行如圖5中的步驟S503,返回代表塊文件不存在的狀態(tài)碼。
[0066]參見圖5中的步驟S504,客戶端接收到該狀態(tài)碼,得到查詢結(jié)果,即文件上傳服務器中不存在即將上傳的文件。根據(jù)該查詢結(jié)果,客戶端執(zhí)行步驟S505,將即將上傳的文件的每個塊文件以及每個塊文件的hash值逐一進行上傳。文件上傳服務器執(zhí)行如圖5中所示的步驟S506,存儲客戶端傳輸?shù)膲K文件。由文件消重服務器執(zhí)行步驟S507,接收每個塊文件的hash值,對文件上傳服務器中存儲的塊文件進行消重,并存儲消重后的塊文件與hash值一對一的映射關系。
[0067]另外,文件上傳服務器執(zhí)行步驟S508,返回塊文件已存儲的結(jié)果至客戶端??蛻舳藞?zhí)行步驟S509,對即將上傳的文件的每個塊文件進行循環(huán)上傳,直至即將上傳的文件全部傳輸至文件上傳服務器,或者客戶端與文件上傳服務器之間的連接斷開。
[0068]實施例二
[0069]圖6示出了根據(jù)本發(fā)明另一個優(yōu)選實施例的文件傳輸方法的流程圖,用于支持上述任意一個文件傳輸方法、設備及系統(tǒng),將上述文件傳輸方法、設備及系統(tǒng)闡述得更清楚明白。需要注意的是,圖6所示的文件傳輸方法中傳輸?shù)奈募槲募蟼鞣掌髦幸汛嬖诓糠謮K文件的文件。
[0070]如圖6所示,客戶端根據(jù)預設規(guī)則對即將上傳的文件進行分塊,得到至少兩個塊文件??蛻舳藢⒓磳⑸蟼鞯奈募譃橹辽賰蓚€塊文件之后,執(zhí)行如圖6所示的步驟S601,計算每個塊文件的hash值,并將各個塊文件分為至少兩個塊文件之后,計算每個塊文件的hash值,并將各個塊文件的hash值上傳至文件上傳服務器,由文件上傳服務器發(fā)送hash值至文件消重服務器,通過hash值查看文件上傳服務器中是否存在塊文件。文件消重服務器接收到每個塊文件的hash值之后,執(zhí)行步驟S602,查詢是否存在每個塊文件的hash值,并執(zhí)行如圖6中的步驟S603,返回存在的部分塊文件的狀態(tài)碼。
[0071]參見圖6中的步驟S604,客戶端接收到該狀態(tài)碼,得到查詢結(jié)果。根據(jù)查詢結(jié)果,客戶端執(zhí)行步驟S605,上傳文件上傳服務器中未存儲的塊文件及其hash值。文件上傳服務器執(zhí)行如圖6中所示的步驟S606,存儲客戶端傳輸?shù)膲K文件。由文件消重服務器執(zhí)行步驟S607,接收每個未存儲的塊文件的hash值,對文件上傳服務器中存儲的塊文件進行消重,并存儲消重后的塊文件與hash值一對一的映射關系。
[0072]另外,文件上傳服務器執(zhí)行如圖6中所示的步驟S608,返回塊文件已存儲的結(jié)果至客戶端??蛻舳藞?zhí)行步驟S609,對塊文件進行循環(huán)上傳,直至文件上傳服務器未存儲的塊文件全部存儲至文件上傳服務器,或者客戶端與文件上傳服務器之間的連接斷開。
[0073]根據(jù)上述任意一個優(yōu)選實施例或多個優(yōu)選實施例的組合,本發(fā)明實施例能夠達到如下有益效果:
[0074]依據(jù)本發(fā)明實施例,客戶端對即將上傳的文件進行分塊之后,客戶端首先查詢文件上傳服務器中是否已存儲有本文件的部分塊文件,其次,客戶端根據(jù)查詢結(jié)果選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,解決了現(xiàn)有技術提到的,當客戶端對已上傳部分文件的文件進行上傳時,仍需要從頭開始上傳文件的問題。本發(fā)明實施例中,客戶端對文件進行傳輸時,能夠僅選擇未存儲在文件上傳服務器中的部分塊文件進行上傳,并不需要對已上傳部分再次進行重傳,達到了節(jié)約網(wǎng)絡資源(包括用戶所使用的網(wǎng)絡資源以及服務器的帶寬資源等)的有益效果,節(jié)省客戶端上傳文件的時間,提高用戶體驗。
[0075]在此處所提供的說明書中,說明了大量具體細節(jié)。然而,能夠理解,本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中,并未詳細示出公知的方法、結(jié)構(gòu)和技術,以便不模糊對本說明書的理解。
[0076]類似地,應當理解,為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個,在上面對本發(fā)明的示例性實施例的描述中,本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而,并不應將該公開的方法解釋成反映如下意圖:即所要求保護的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說,如下面的權(quán)利要求書所反映的那樣,發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此,遵循【具體實施方式】的權(quán)利要求書由此明確地并入該【具體實施方式】,其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。
[0077]本領域那些技術人員可以理解,可以對實施例中的設備中的模塊進行自適應性地改變并且把它們設置在與該實施例不同的一個或多個設備中??梢园褜嵤├械哪K或單元或組件組合成一個模塊或單元或組件,以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外,可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述,本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。
[0078]此外,本領域的技術人員能夠理解,盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征,但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如,在權(quán)利要求書中,所要求保護的實施例的任意之一都可以以任意的組合方式來使用。
[0079]本發(fā)明的各個部件實施例可以以硬件實現(xiàn),或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn),或者以它們的組合實現(xiàn)。本領域的技術人員應當理解,可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP )來實現(xiàn)根據(jù)本發(fā)明實施例的文件傳輸設備中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設備或者裝置程序(例如,計算機程序和計算機程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質(zhì)上,或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到,或者在載體信號上提供,或者以任何其他形式提供。
[0080]應該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制,并且本領域技術人員在不脫離所附權(quán)利要求的范圍的情況下可設計出替換實施例。在權(quán)利要求中,不應將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中,這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。
[0081]至此,本領域技術人員應認識到,雖然本文已詳盡示出和描述了本發(fā)明的多個示例性實施例,但是,在不脫離本發(fā)明精神和范圍的情況下,仍可根據(jù)本發(fā)明公開的內(nèi)容直接確定或推導出符合本發(fā)明原理的許多其他變型或修改。因此,本發(fā)明的范圍應被理解和認定為覆蓋了所有這些其他變型或修改。
【權(quán)利要求】
1.一種文件傳輸方法,用于將文件從客戶端上傳至文件上傳服務器,該方法包括: 根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件; 查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件; 根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
2.根據(jù)權(quán)利要求1所述的方法,其中,查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件,包括: 計算每個塊文件的哈希hash值; 將各hash值發(fā)送至文件消重服務器,其中,所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系; 查詢所述文件消重服務器中是否存儲有該hash值,若有,則表明所述文件上傳服務器中已存儲有該hash值所對應的塊文件。
3.根據(jù)權(quán)利要求2所述的方法,其中,所述映射關系為一對一的映射關系。
4.根據(jù)權(quán)利要求1至3任一項所述的方法,其中,所述預設規(guī)則包括: 將本文件分為相同塊長的塊文件;或者 將本文件分為不同塊長的塊文件。
5.一種客戶端,用于把文件上傳至文件上傳服務器,其包括: 分塊器,配置為根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件;查詢器,配置為查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件;傳輸器,配置為根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
6.根據(jù)權(quán)利要求5所述的客戶端,其中,所述查詢器還配置為: 計算每個塊文件的hash值; 將各hash值發(fā)送至文件消重服務器,其中,所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系; 查詢所述文件消重服務器中是否存儲有該hash值,若有,則表明所述文件上傳服務器中已存儲有該hash值所對應的塊文件。
7.根據(jù)權(quán)利要求6所述的客戶端,其中,所述映射關系為一對一的映射關系。
8.根據(jù)權(quán)利要求5至7任一項所述的客戶端,其中,所述分塊器還配置為: 將本文件分為相同塊長的塊文件;或者 將本文件分為不同塊長的塊文件。
9.一種文件傳輸系統(tǒng),包括客戶端以及文件上傳服務器: 所述文件上傳服務器,配置為存儲不同客戶端上傳的文件; 任一客戶端,配置為根據(jù)預設規(guī)則對即將上傳的文件進行分塊以得到至少兩個塊文件;查詢所述文件上傳服務器中是否已存儲有所述文件的部分塊文件;根據(jù)查詢結(jié)果選擇未存儲在所述文件上傳服務器中的部分塊文件進行上傳。
10.根據(jù)權(quán)利要求9所述的系統(tǒng),其中,還包括: 文件消重服務器,配置為所述文件消重服務器對所述文件上傳服務器中存儲的塊文件進行消重,存儲消重后的塊文件與hash值的映射關系; 所述客戶端,還配置為計算每個塊文件的hash值;將各hash值發(fā)送至所述文件消重服務器,查詢所述文件上 傳服務器中是否存儲有該hash值對應的塊文件。
【文檔編號】H04L29/08GK103561056SQ201310476415
【公開日】2014年2月5日 申請日期:2013年10月12日 優(yōu)先權(quán)日:2013年10月12日
【發(fā)明者】楊銀波, 陳超 申請人:北京奇虎科技有限公司, 奇智軟件(北京)有限公司