本發(fā)明涉及數據傳輸技術領域,尤其涉及一種基于云計算環(huán)境下打包文件的傳輸方法及系統(tǒng)。
背景技術:
I/O密集型應用是云計算環(huán)境下最常用的應用之一,如何提高這種特定類型應用的處理效率一直很少有人關注。文件上傳下載是一種典型的I/O密集型應用,海量小文件單獨傳輸需要消耗大量的等待時間,而且每次傳輸都需要進行I/O操作,導致服務器數據中心的數據吞吐率和服務效率較低。傳統(tǒng)的打包策略是全部打包策略,即當一個客戶端請求上傳或下載一個文件夾,就將文件夾整體打包為一個文件。該打包策略在文件夾中有不適合打包的文件時,會浪費了很多時間和資源來給不適合打包的文件進行壓縮打包。
技術實現要素:
本發(fā)明提供了一種基于云計算環(huán)境下打包文件的傳輸方法及系統(tǒng),該方法及系統(tǒng)可以縮短文件的傳輸時間,提升文件傳輸效率,同時也減少文件傳輸過程中的I/O操作。
為實現上述設計,本發(fā)明采用以下技術方案:
一方面,提供了一種基于云計算環(huán)境下打包文件的傳輸方法,包括:
接收傳輸文件夾的命令;
獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列;
將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。
其中,所述將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列之前,還包括:
將所述不適合打包的文件的文件名作為Key值,文件大小作為Value值放入降序樹圖中;
所述將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列,包括:
獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值;
將所述第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值對應的文件放入所述打包隊列;
所述將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸,包括:
獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值;
將所述第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值對應的文件進行傳輸。
其中,所述將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸,包括:
將所述打包隊列中的文件進行壓縮,完成打包,形成打包文件;
給所述打包文件添加預置打包標記;
將添加有所述預置打包標記的打包文件進行傳輸。
其中,所述文件大小為磁盤推算出的文件大小、網絡推算出的文件大小或中斷推算出的文件大小。
其中,所述獲取所述文件夾中所有文件的文件類型和文件大小,具體為:通過文件遍歷算法獲取所述文件夾中所有文件的文件類型和文件大小。
另一方面,提供了一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng),包括:
接收單元,接收傳輸文件夾的命令;
獲取單元,獲取所述文件夾中所有文件的文件類型和文件大??;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列;
傳輸單元,將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。
其中,還包括:
放入單元,將所述不適合打包的文件的文件名作為Key值,文件大小作為Value值放入降序樹圖中;
所述將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列,包括:
獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值;
將所述第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值對應的文件放入所述打包隊列;
所述將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸,包括:
獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值;
將所述第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值對應的文件進行傳輸。
其中,所述將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸,包括:
將所述打包隊列中的文件進行壓縮,完成打包,形成打包文件;
給所述打包文件添加預置打包標記;
將添加有所述預置打包標記的打包文件進行傳輸。
其中,所述文件大小為磁盤推算出的文件大小、網絡推算出的文件大小或中斷推算出的文件大小。
其中,所述獲取所述文件夾中所有文件的文件類型和文件大小,具體為:通過文件遍歷算法獲取所述文件夾中所有文件的文件類型和文件大小。
本發(fā)明的有益效果為:本發(fā)明實施例通過接收傳輸文件夾的命令;獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列;將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。根據文件類型和文件大小將文件夾中適合打包的文件放入打包隊列進行打包,同時將文件夾中剩余的文件即刻進行傳輸,打包隊列打包完畢后再進行傳輸;大大縮短了整個文件夾的傳輸時間,提升了文件傳輸效率,同時也降低文件傳輸過程中的I/O操作,從而可以大大提升數據中心的數據吞吐率和服務效率,增加服務器的使用壽命。
附圖說明
為了更清楚地說明本發(fā)明實施例中的技術方案,下面將對本發(fā)明實施例描述中所需要使用的附圖作簡單的介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領域普通技術人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據本發(fā)明實施例的類型和這些附圖獲得其他的附圖。
圖1是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸方法的第一實施例的方法流程圖。
圖2是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸方法的第二實施例的方法流程圖。
圖3是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的第一實施例的結構方框圖。
圖4是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的第二實施例的結構方框圖。
具體實施方式
為使本發(fā)明解決的技術問題、采用的技術方案和達到的技術效果更加清楚,下面將結合附圖對本發(fā)明實施例的技術方案作進一步的詳細描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例?;诒景l(fā)明中的實施例,本領域技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
本方案適用于兩臺服務器之間的文件傳輸或者服務器與客戶端之間的文件傳輸。
請參考圖1,其是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸方法的第一實施例的方法流程圖。如圖所示,該方法包括:
步驟S101:接收傳輸文件夾的命令。
服務器(或客戶端)接收到另一臺服務器/客戶端發(fā)送過來的要求傳輸文件夾的命令。
步驟S102:獲取所述文件夾中所有文件的文件類型和文件大?。桓鶕鑫募愋蛯⑺鏊形募譃檫m合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列。
在使用打包策略以前,必須首先獲取每一個文件的類型和大?。豢蛇x地,采用文件遍歷算法獲取需要傳輸的文件夾中所有文件的文件類型和文件大小。將適合打包的文件類型的文件放入打包隊列,將不適合打包的文件類型的文件進行大小排序,小于文件閾值的文件也放入打包隊列中。
可選地,獲得文件夾中所有文件的文件類型和文件大小,每獲得一個文件的文件類型和文件大小,就判斷是否屬于適合打包的文件類型,如果屬于適合打包的文件類型,就將該文件放入打包隊列;如果不屬于適合打包的文件類型,就判斷該文件的文件大小是否小于文件閾值,當該文件的文件大小小于文件閾值時,將該文件放入打包隊列;接著再判斷下一個文件,判斷過程與上述過程相同,直到文件夾中所有的文件都判斷完畢為止。
可選地,獲得文件夾中所有文件的文件類型和文件大小,等文件夾中所有文件的文件類型和文件大小都獲知了后,再統(tǒng)一進行是否放入打包隊列的判斷。首先,從這些文件中選出符合適合打包的文件類型的所有文件放入打包隊列中;然后,從文件夾剩下的文件中選出文件大小小于文件閾值的所有文件放入打包隊列中。
其中,適合打包的文件類型主要為文檔類文件,如Word文檔、文本文檔、excel文檔等;不適合打包的文件類型主要多媒體文件,如:視頻文件、音頻文件、MP3等。由于多媒體文件大多數都已經經過了成熟的高度壓縮處理而生成了專門的格式,因此很難會有更好地壓縮方式使其進一步壓縮,甚至已經無法壓縮,就目前的壓縮技術來看,即使可以再進一步壓縮,必定會以犧牲視頻文件、音頻文件的畫質、音質為代價,因此多媒體文件是進一步壓縮中,壓縮比非常小的一類文件。對于壓縮比大的文件,大多指的文本文件數據表格文件或者日志文件等,這些文件中存在大量重復的數據,同時文字信息比較多,壓縮軟件可以通過特定的算法,將這些重復的信息使用某一變量代替,從而盡可能減少文件的大小,在解壓的時候,使用反替換就可以得到原來的文件。這樣對于云計算服務器上海量的數據文件,例如客戶端上傳的日志文件,數據庫文件,檔案文件等,都可以采用打包壓縮的方式進行預處理,對適合打包的小文件進行打包時,打包的時間、打包文件傳輸的時間及解包的時間三者的時間和會大大的小于小文件單獨傳輸的時間和,從而減少傳輸時間。
可選地,文件大小為磁盤推算出的文件大小、網絡推算出的文件大小或中斷推算出的文件大小。
步驟S103:將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。
將文件夾中剩下的文件(即不適合打包的文件中文件大小大于等于文件閾值的文件)即刻進行傳輸,同時將將打包隊列中的文件進行壓縮打包,打包完畢后,將打包后形成的打包文件進行傳輸。其中,文件閾值可根據用戶的需求、設備的性能及網絡傳輸速度進行設定,通常情況下由大量的實驗經驗獲得,可選地,文件閾值為3-5Kb。
當客戶端與服務器進行I/O交互時,每當上傳或者下載一個文件時,都要進行請求和響應。首先,發(fā)送端需要發(fā)送一個請求消息,通知接收端即將發(fā)送文件,請做好準備,如打開端口,用戶密碼認證等,因而每一次請求都需要消耗一定的時間(請求時間)。然后接收端向發(fā)送端發(fā)送一個響應消息,告訴發(fā)送端自己已經準備好,可以接受,這個過程也需要消耗一定的時間(響應時間)。之后雙方建立連接,完成數據傳輸,這個時間是傳輸時間。通常,文件的總體傳輸時間與文件個數,文件的請求時間,文件的傳輸時間和文件的請求響應時間有關。由于離散的小文件是一個接一個的,因此,執(zhí)行某一個文件的請求時,其他文件都處于閑置狀態(tài)。同時,由于網絡帶寬等原因,文件傳輸等待的時間會比較長,因此大量的時間會被消耗在等待連接的響應上,而傳輸一個小文件本身所占用的時間并不長,因此傳輸效率會非常低下。而且,執(zhí)行一次I/O操作必然導致系統(tǒng)中斷產生,每次中斷產生后都需要一定的中斷響應時間。
綜上所述,本發(fā)明實施例通過接收傳輸文件夾的命令;獲取所述文件夾中所有文件的文件類型和文件大??;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列;將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。根據文件類型和文件大小將文件夾中適合打包的文件放入打包隊列進行打包,同時將文件夾中剩余的文件即刻進行傳輸,打包隊列打包完畢后再進行傳輸;大大縮短了整個文件夾的傳輸時間,提升了文件傳輸效率,同時也降低文件傳輸過程中的I/O操作,從而可以大大提升數據中心的數據吞吐率和服務效率,增加服務器的使用壽命。
請參考圖2,其是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸方法的第二實施例的方法流程圖。如圖所示,該方法包括:
步驟S201:接收傳輸文件夾的命令。
步驟S202:獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列;將所述不適合打包的文件的文件名作為Key值,文件大小作為Value值放入降序樹圖中,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列。
可選地,采用廣度優(yōu)先遍歷算法和深度優(yōu)先算法(Depth-First-Search,DFS算法)獲取需要傳輸的文件夾中所有文件的文件類型和文件大小。優(yōu)選地,采用單線程非遞歸的廣度優(yōu)先遍歷算法來遍歷文件夾中平行的子文件夾,采用單線程非遞歸的深度優(yōu)先遍歷算法來遍歷文件夾中的每一個文件。
在文件夾中,整個文件夾相當于一個樹的根節(jié)點,里面的子文件夾相當于一般節(jié)點,文件相當于葉子節(jié)點。使用深度優(yōu)先算法可以完全遍歷這個文件夾,即從根節(jié)點開始遍歷,最終可以到達每一個文件。在深度優(yōu)先算法中,通常會設置標記位來判斷是否訪問過。對于新發(fā)現的節(jié)點v,如果有以此節(jié)點為起點而未探測過的邊,就沿此邊繼續(xù)搜索下去。當節(jié)點v的所有邊都已經被搜索過,搜索將回溯到發(fā)現該節(jié)點v的那條邊的始節(jié)點。這一過程將會一直進行,直到發(fā)現從源節(jié)點出發(fā),可以到達的所有節(jié)點為止。如果此時存在未被訪問過的節(jié)點,則選擇其中一個作為源節(jié)點并重復上述過程,整個過程反復進行,直到該圖中所有可達的節(jié)點都被訪問過為止。在使用DFS算法時,相對于樹來說,節(jié)點v即下一個需要遍歷的文件或者文件夾,當訪問到文件時,保存該文件的路徑和大小后即可立即返回到上一層,進行之后的遍歷。
文件的遍歷算法有很多,然而對于深度優(yōu)先的搜索,遞歸過程會在調用之前進行,為某個目錄分配的搜索資源要在這個目錄所有子目錄搜索完畢之后才能釋放,而廣度優(yōu)先的搜索則是在本次搜索的之后才開始深入搜索,其耗費的系統(tǒng)資源要比深度優(yōu)先搜索要少得多,因此采取廣度優(yōu)先遍歷。其次遞歸算法可以簡化算法的復雜度,但是會占用大量的??臻g,同時也會產生大量的函數調用代碼,當文件夾規(guī)模很大的時候很容易引起“堆棧下溢”,因此采取非遞歸算法。另外,在操作I/O的時候,由于大部分I/O設備是不支持并行存取的,用多線程來進行文件搜索,反而會造成大量的互斥操作,反而影響了速度。
步驟S203:獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值,將所述第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值對應的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件,給所述打包文件添加預置打包標記,將添加有所述預置打包標記的打包文件進行傳輸。
將打包隊列中的文件壓縮打包完畢后,給形成的打包文件添加預置打包標記,然后進行傳輸。當接收端收到的文件時,如果帶有預置打包標記,則解包處理后保存;如果沒有預置打包標記,則表明文件沒有被壓縮打包,只需要按原文件保存即可。
在遍歷完整個文件夾后,每一個文件的信息都被保存起來,這里定義了一個降序樹圖(即TreeMap)用于保存文件信息。在TreeMap中可以通過一個對象來對另一個對象進行索引,用來索引的對象叫做key,被索引的對象叫做value。這里每個文件有兩個信息,一個是文件名的完整名稱,另一個就是該文件的大小。通過文件的完成名稱,可以獲取該文件的后綴。通過分析后綴可以判斷文件的類型。文件類型對于判斷文件是否應該打包十分重要。TreeMap運用到了排序樹的思想,將數據按照有序的順序進行保存。先定義一個打包隊列(Package Queue),初始狀態(tài)置為空,對于將要打包的文件,統(tǒng)一放入打包隊列(Package Queue)里。在文件遍歷算法結束以后,Package Queue中保存的文件會被統(tǒng)一進行打包,打包完畢后會置一個特殊標記符,從而區(qū)分這個打包文件和一般壓縮文件。
綜上所述,本發(fā)明實施例采用廣度優(yōu)先遍歷算法和深度優(yōu)先算法來遍歷需要傳輸的文件夾中的所有文件,獲取需要傳輸的文件夾中所有文件的文件類型和文件大小,將所有的文件類型和文件大小放入降序樹圖中,先通過文件類型找出適合打包的文件放入打包隊列,再通過文件大小找出適合打包的文件放入打包隊列,然后在打包隊列的文件進行打包的同時將文件夾中剩余的文件即刻進行傳輸,打包隊列打包完畢后再進行傳輸,提高文件傳輸的效率,提高網絡資源的使用效率,并減少文件傳輸過程中的IO操作,達到降低能耗、延長物理設備使用壽命的目的。
以下為本方案一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的實施例,一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的實施例基于一種基于云計算環(huán)境下打包文件的傳輸方法的實施例實現,在一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的實施例中未盡的描述,請參考一種基于云計算環(huán)境下打包文件的傳輸方法的實施例。
請參考圖3,其是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的第一實施例的結構方框圖。如圖所示,該系統(tǒng)包括:
接收單元310,接收傳輸文件夾的命令。
獲取單元320,獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列。
可選地,采用文件遍歷算法獲取需要傳輸的文件夾中所有文件的文件類型和文件大小。其中,適合打包的文件類型主要為文檔類文件,如Word文檔、文本文檔、excel文檔等;不適合打包的文件類型主要多媒體文件,如:視頻文件、音頻文件、MP3等。文件大小為磁盤推算出的文件大小、網絡推算出的文件大小或中斷推算出的文件大小。
傳輸單元330,將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。
綜上所述,各單元模塊協同工作,接收單元310,接收傳輸文件夾的命令;獲取單元320,獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列;傳輸單元330,將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。根據文件類型和文件大小將文件夾中適合打包的文件放入打包隊列進行打包,同時將文件夾中剩余的文件即刻進行傳輸,打包隊列打包完畢后再進行傳輸;大大縮短了整個文件夾的傳輸時間,提升了文件傳輸效率,同時也降低文件傳輸過程中的I/O操作,從而可以大大提升數據中心的數據吞吐率和服務效率,增加服務器的使用壽命。
請參考圖4,其是本發(fā)明具體實施方式中提供的一種基于云計算環(huán)境下打包文件的傳輸系統(tǒng)的第二實施例的結構方框圖。如圖所示,該系統(tǒng)包括:
接收單元310,接收傳輸文件夾的命令。
獲取單元320,獲取所述文件夾中所有文件的文件類型和文件大小;根據所述文件類型將所述所有文件分為適合打包的文件和不適合打包的文件;將所述適合打包的文件放入打包隊列,將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列。
可選地,采用廣度優(yōu)先遍歷算法和深度優(yōu)先算法(Depth-First-Search,DFS算法)獲取需要傳輸的文件夾中所有文件的文件類型和文件大??;其中,單線程非遞歸的廣度優(yōu)先遍歷算法來遍歷文件夾中平行的子文件夾,采用單線程非遞歸的深度優(yōu)先遍歷算法來遍歷文件夾中的每一個文件。
傳輸單元330,將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸;將所述打包隊列中的文件進行壓縮打包,將打包后形成的打包文件進行傳輸。
所述將所述不適合打包的文件中文件大小小于文件閾值的文件放入所述打包隊列,包括:獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值;將所述第一個小于所述文件閾值的Value值對應的Key值及所述Value值對應的Key值后面的所有Key值對應的文件放入所述打包隊列。
放入單元340,將所述不適合打包的文件的文件名作為Key值,文件大小作為Value值放入降序樹圖中。
所述將所述不適合打包的文件中文件大小大于等于文件閾值的文件進行傳輸,包括:獲取所述降序樹圖中第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值;將所述第一個小于所述文件閾值的Value值對應的Key值前面的所有Key值對應的文件進行傳輸。
綜上所述,各單元模塊協同工作,放入單元340,將所述不適合打包的文件的文件名作為Key值,文件大小作為Value值放入降序樹圖中。采用廣度優(yōu)先遍歷算法和深度優(yōu)先算法來遍歷需要傳輸的文件夾中的所有文件,獲取需要傳輸的文件夾中所有文件的文件類型和文件大小,將所有的文件類型和文件大小放入降序樹圖中,先通過文件類型找出適合打包的文件放入打包隊列,再通過文件大小找出適合打包的文件放入打包隊列,然后在打包隊列的文件進行打包的同時將文件夾中剩余的文件即刻進行傳輸,打包隊列打包完畢后再進行傳輸,提高文件傳輸的效率,提高網絡資源的使用效率,并減少文件傳輸過程中的IO操作,達到降低能耗、延長物理設備使用壽命的目的。
以上結合具體實施例描述了本發(fā)明的技術原理。這些描述只是為了解釋本發(fā)明的原理,而不能以任何方式解釋為對本發(fā)明保護范圍的限制。基于此處的解釋,本領域的技術人員不需要付出創(chuàng)造性的勞動即可聯想到本發(fā)明的其它具體實施方式,這些方式都將落入本發(fā)明的保護范圍之內。