專利名稱：一種多文件上傳的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種多文件上傳的方法及系統(tǒng)。
背景技術(shù)：
目前在廣域網(wǎng)內(nèi)傳輸批量文件是一件非常耗時的事情，批量文件在進行傳輸時傳輸效率較低，主要是由于傳輸控制命令和人工操作占據(jù)了文件傳輸耗時中相當大的比例。
現(xiàn)有的文件傳輸技術(shù)中主要有兩種處理多個文件上傳的方法一種是多個文件分別上傳的方法，該方法是通過簡單的多次調(diào)用單個文件傳輸函數(shù)的方法實現(xiàn)的。對于該多文件上傳方法，從用戶設(shè)備端看，每上傳一個文件，都需要發(fā)送一次文件上傳請求命令，即需要一次人工參與，人工操作的次數(shù)和時間都是與待上傳文件的數(shù)目成正比的，通常人工操作消耗的時間與文件傳輸本身的耗時等數(shù)量級甚至是大于文件傳輸耗時，所以當上傳文件的數(shù)目龐大且每個文件較小時，人工操作所消耗的時間將遠遠大于文件傳輸本身所消耗的時間，成為多文件上傳總耗時中的主要部分，導致該多文件上傳方法的效率極低。而從服務器端看，上傳后的文件仍然以不相關(guān)聯(lián)的多個獨立文件的形式存儲于服務器中，當文件數(shù)量龐大時管理起來非常不便。
另外一種多文件上傳方法是多文件磁盤打包上傳，該方法是指把多個待上傳的文件在磁盤中打包成一個包文件上傳，利用該方法上傳存儲于一個文件源端中的多個文件的具體流程如圖1所示，包括以下步驟步驟s101，用戶設(shè)備向主控板發(fā)送多文件磁盤打包上傳請求，該請求中包括待上傳的所述多文件的文件標識信息及其所在文件源端的地址信息。
步驟s102，主控板根據(jù)所述文件源端地址信息和所述文件標識信息向所述文件源端發(fā)送數(shù)據(jù)上傳請求。
步驟s103，文件源端向主控板發(fā)送對應的數(shù)據(jù)幀。
步驟s104，主控板將接收到主控板內(nèi)存中的數(shù)據(jù)幀讀取到主控板的磁盤中。
步驟s105，主控板在磁盤中將數(shù)據(jù)打包。
步驟s106，主控板將數(shù)據(jù)上傳至服務器。
步驟s107，判斷該文件源端中待上傳文件的數(shù)據(jù)是否已經(jīng)全部上傳完畢，若已上傳完畢，進入步驟s108，否則，主控板繼續(xù)向該文件源端發(fā)送數(shù)據(jù)上傳請求，轉(zhuǎn)步驟s103。
步驟s108，主控板關(guān)閉與服務器的連接，返回成功響應并結(jié)束。
若要實現(xiàn)來自多個文件源端的多文件磁盤打包上傳，可多次調(diào)用上述步驟實現(xiàn)，文件上傳完成后在服務器中形成多個包文件。
與上述多個文件分別上傳的方法相比，多文件磁盤打包上傳的方法可以將從同一文件源端中上傳的多個文件按照一定的格式組織在同一個文件中，在服務器端更便于文件的管理。同時將文件打包后再上傳也避免了分別上傳時針對每個文件都要重新建立控制連接和數(shù)據(jù)連接的麻煩，有效壓縮了傳輸控制命令的數(shù)量，提高了傳輸?shù)男阅?。但是該上傳方法仍然存在明顯的不足首先，采用磁盤打包上傳方法需要頻繁地讀寫磁盤，因為讀寫磁盤的速度比讀寫內(nèi)存的速度慢，所以使得文件傳輸效率受到制約。
其次，對于存儲于不同源端的多個文件，利用該方法需要用戶設(shè)備進行多次操作才能完成打包上傳，并且來自多個文件源端的文件在服務器端相應形成多個包文件也不便于文件管理。

發(fā)明內(nèi)容
本發(fā)明要解決的問題是提供一種多文件上傳的方法及系統(tǒng)，以克服現(xiàn)有技術(shù)中多文件上傳效率低的缺陷。
為達到上述目的，本發(fā)明提供一種多文件上傳的方法，包括以下步驟接收多文件上傳請求；根據(jù)所述多文件上傳請求從多個文件源端獲取多文件數(shù)據(jù)；
將所述多文件數(shù)據(jù)在內(nèi)存中打包并上傳至目的端。
按照本發(fā)明的一個方面，所述多文件上傳請求包括文件標識信息；或文件標識信息和文件源端地址信息。
按照本發(fā)明的另一個方面，當所述多文件上傳請求包括文件標識信息時，所述從多個文件源端獲取多文件數(shù)據(jù)包括以下步驟根據(jù)所述文件標識信息，獲取文件源端地址信息；根據(jù)所述文件源端地址信息和所述文件標識信息，向?qū)奈募炊税l(fā)送數(shù)據(jù)上傳請求；所述文件源端發(fā)送對應的數(shù)據(jù)幀。
按照本發(fā)明的再一個方面，所述獲取文件源端地址信息的過程具體為根據(jù)所述文件標識信息，在所有文件源端中進行匹配查找，獲取文件源端地址信息。
按照本發(fā)明的再一個方面，所述獲取文件源端地址信息的過程具體為根據(jù)所述文件標識信息，在文件標識信息與文件源端地址信息的對應關(guān)系表中進行查找，獲取文件源端地址信息。
按照本發(fā)明的再一個方面，當所述多文件上傳請求包括文件標識信息和文件源端地址信息時，所述從多個文件源端獲取多文件數(shù)據(jù)包括以下步驟根據(jù)所述文件源端地址信息和所述文件標識信息，向?qū)奈募炊税l(fā)送數(shù)據(jù)上傳請求；所述文件源端發(fā)送對應的數(shù)據(jù)幀。
按照本發(fā)明的再一個方面，所述多文件上傳請求中還包括數(shù)據(jù)處理請求。
按照本發(fā)明的再一個方面，所述數(shù)據(jù)處理請求包括數(shù)據(jù)加密請求和/或壓縮處理請求。
按照本發(fā)明的再一個方面，所述多文件數(shù)據(jù)在內(nèi)存中的打包過程與上傳過程同時進行，實現(xiàn)多文件數(shù)據(jù)的實時上傳。
按照本發(fā)明的再一個方面，上傳后的包文件為一個文件。
本發(fā)明還提供一種多文件上傳系統(tǒng)，包括多文件上傳控制端、文件源端和目的端，所述多文件上傳控制端分別與所述文件源端和所述目的端連接；所述多文件上傳控制端，用于從多個所述文件源端中獲取多文件數(shù)據(jù)，并對所述多文件數(shù)據(jù)在內(nèi)存中進行打包，并上傳至所述目的端；所述文件源端，用于存儲所述多文件數(shù)據(jù)；所述目的端，用于接收并存儲所述多文件打包后形成的包文件。
按照本發(fā)明的再一個方面，所述多文件上傳控制端中存儲有文件標識信息與文件源端地址信息的對應關(guān)系表。
按照本發(fā)明的再一個方面，所述多文件上傳控制端還用于對所述獲取的多文件數(shù)據(jù)進行處理。
按照本發(fā)明的再一個方面，所述數(shù)據(jù)處理包括數(shù)據(jù)加密和/或壓縮處理。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點本發(fā)明采用在內(nèi)存中將多文件進行打包并上傳的技術(shù)，減少了頻繁讀寫磁盤造成的時間耗損。
而且，當待上傳的文件存儲于不同的文件源端時，采用本發(fā)明，減少了多文件上傳時的人工操作，提高了多文件上傳的效率。
進一步，來自不同文件源端的多個文件上傳后在服務器中形成單一的包文件，非常便于文件的管理。
另外，本發(fā)明中對多文件數(shù)據(jù)的加密及壓縮功能滿足了不同用戶對于文件傳輸安全以及節(jié)約磁盤空間的需求。


圖1是現(xiàn)有技術(shù)中多文件磁盤打包上傳的流程圖；圖2是本發(fā)明一種多文件上傳的系統(tǒng)圖；圖3是本發(fā)明一種多文件上傳的流程圖；圖4是本發(fā)明中實施例一的流程圖；圖5是本發(fā)明中實施例二的流程圖。
具體實施例方式
本發(fā)明的一種多文件上傳系統(tǒng)如圖2所示，該系統(tǒng)包括用戶設(shè)備21，多文件上傳控制端22，文件源端23a、23b、23c、23d和目的端24。
多文件上傳控制端22分別與用戶設(shè)備21、文件源端23a、23b、23c、23d和目的端24連接，用于接收用戶設(shè)備21發(fā)送的多文件上傳請求，從多個所述文件源端中獲取多文件數(shù)據(jù)，對所述多文件數(shù)據(jù)在內(nèi)存中進行打包，并上傳至目的端24，以及向用戶設(shè)備21發(fā)送上傳成功響應；多文件上傳控制端22還可以對獲取的多文件數(shù)據(jù)進行數(shù)據(jù)加密和/或壓縮等處理。
用戶設(shè)備21用于向多文件上傳控制端22發(fā)送多文件上傳請求，以及接收多文件上傳控制端22發(fā)出的上傳成功響應，同時，用戶設(shè)備21還可以用于察看并管理上傳后的包文件。文件源端23a、23b、23c、23d用于接收多文件上傳控制端22的數(shù)據(jù)上傳請求，并將存儲的文件數(shù)據(jù)傳送至多文件上傳控制端22。目的端24用于接收并存儲上傳的包文件。
本發(fā)明的一種多文件上傳的流程如圖3所示，包括以下步驟步驟s301，接收多文件上傳請求。即用戶設(shè)備21向多文件上傳控制端22發(fā)送多文件上傳請求，多文件上傳控制端22接收該請求，該請求包括文件標識信息；或文件標識信息和文件源端地址信息。
步驟s302，根據(jù)所述多文件上傳請求從多個文件源端獲取多文件數(shù)據(jù)。即多文件上傳控制端22根據(jù)所述文件源端地址信息，依次向與所述多文件對應的文件源端發(fā)送數(shù)據(jù)上傳請求，各所述文件源端在接收到所述數(shù)據(jù)上傳請求后響應請求，向多文件上傳控制端22發(fā)送數(shù)據(jù)幀。
當所述多文件請求僅包括所述多文件的文件標識信息時，多文件上傳控制端22在發(fā)送數(shù)據(jù)上傳請求之前，還需要根據(jù)所述文件標識信息，獲取文件源端地址信息，然后根據(jù)所述文件源端地址信息和所述文件標識信息發(fā)送數(shù)據(jù)上傳請求。
獲取文件源端地址信息的過程具體為多文件上傳控制端22根據(jù)所述文件標識信息，在所有文件源端中進行匹配查找，獲取文件源端地址信息。如果多文件上傳控制端22中存儲有文件標識信息與文件源端地址信息的對應關(guān)系表，則多文件上傳控制端22根據(jù)所述文件標識信息，在文件標識信息與文件源端地址信息的對應關(guān)系表中進行查找，獲取文件源端地址信息。
步驟s303，將所述多文件數(shù)據(jù)在內(nèi)存中打包并上傳至目的端。多文件上傳控制端22將所述文件源端發(fā)送的數(shù)據(jù)幀讀取到內(nèi)存中，并在內(nèi)存中對所述數(shù)據(jù)幀進行打包，并上傳至目的端24，形成一個包文件。在目的端24接收完所述多文件的全部數(shù)據(jù)之后，多文件上傳控制端22向用戶設(shè)備21返回成功響應。在本步驟中，多文件上傳控制端22根據(jù)所述多文件上傳請求中的數(shù)據(jù)處理請求，還可以對所述多文件數(shù)據(jù)進行處理，該數(shù)據(jù)處理包括加密和/或壓縮處理等。
以下結(jié)合具體實施例及附圖對本發(fā)明進行詳細說明實施例一，當采用圖2所示多文件上傳系統(tǒng)時，本發(fā)明的一種多文件上傳的流程如圖4所示。假設(shè)待上傳的文件分別存儲在文件源端23a、文件源端23b、文件源端23c和文件源端23d中，而且用戶設(shè)備21發(fā)送的多文件上傳請求命令中包括所述多文件的文件標識信息及其所在文件源端的地址信息。參照圖4，本發(fā)明包括以下步驟步驟s401，用戶設(shè)備21向多文件上傳控制端22發(fā)送多文件上傳請求。所述多文件上傳請求中包括所述多文件的文件標識信息及其所在文件源端的地址信息，還要求對所述多文件數(shù)據(jù)進行加密和壓縮處理。
步驟s402，多文件上傳控制端22根據(jù)所述文件源端的地址信息和所述文件標識信息向與待上傳文件對應的其中一個文件源端發(fā)送數(shù)據(jù)上傳請求。
步驟s403，該文件源端回應請求并向多文件上傳控制端22發(fā)送對應的數(shù)據(jù)幀。
步驟s404，多文件上傳控制端22將數(shù)據(jù)讀取到內(nèi)存中，并判斷用戶設(shè)備21是否要求進行數(shù)據(jù)加密和/或壓縮處理，若要求進行數(shù)據(jù)加密和/或壓縮處理，則轉(zhuǎn)步驟s410，否則，轉(zhuǎn)步驟s405。因為本實施例中要求進行數(shù)據(jù)加密和壓縮處理，所以轉(zhuǎn)步驟s410。
步驟s405，多文件上傳控制端22在內(nèi)存中將數(shù)據(jù)幀打包。
步驟s406，多文件上傳控制端22將數(shù)據(jù)上傳至目的端24。
步驟s407，判斷該文件源端中待上傳文件的數(shù)據(jù)是否已經(jīng)全部上傳完畢，若已上傳完畢，進入步驟s408，否則，轉(zhuǎn)步驟s411。
步驟s408，多文件上傳控制端22判斷是否所有文件源端中的待上傳文件都已上傳完畢，若已上傳完畢，轉(zhuǎn)步驟s409，否則，轉(zhuǎn)步驟s412。
步驟s409，多文件上傳控制端22關(guān)閉與目的端24的連接，向用戶設(shè)備21返回成功響應并結(jié)束。
步驟s410，多文件上傳控制端22對數(shù)據(jù)進行加密及壓縮處理，并轉(zhuǎn)步驟s405。本步驟采用通用的數(shù)據(jù)加密和/或壓縮技術(shù)，可利用winrar進行解密及解壓縮。
步驟s411，多文件上傳控制端22繼續(xù)向步驟s407中所述文件源端發(fā)送數(shù)據(jù)上傳請求，并返回步驟s403。
步驟s412，多文件上傳控制端22向另一存儲待上傳文件的文件源端發(fā)送數(shù)據(jù)上傳請求，并返回步驟s403。
實施例二，當采用圖2所示多文件上傳系統(tǒng)時，本發(fā)明的另一種多文件上傳的流程如圖5所示。假設(shè)待上傳的文件分別存儲在文件源端23a、文件源端23b、文件源端23c和文件源端23d中，用戶設(shè)備21發(fā)送的多文件上傳請求命令中包括所述多文件的文件標識信息，但不包括所述多文件所在文件源端的地址信息。參照圖5，本發(fā)明包括以下步驟步驟s501，用戶設(shè)備21向多文件上傳控制端22發(fā)送多文件上傳請求。所述多文件上傳請求中包括所述多文件的文件標識信息，還要求對所述多文件數(shù)據(jù)進行加密和壓縮處理。
步驟s502，多文件上傳控制端22根據(jù)所述文件標識信息，獲取文件源端地址信息。即多文件上傳控制端22根據(jù)所述文件標識信息，在文件源端23a、文件源端23b、文件源端23c和文件源端23d中進行匹配查找，獲取文件源端地址信息。如果多文件上傳控制端22中存儲有文件標識信息與文件源端地址信息的對應關(guān)系表，則多文件上傳控制端22根據(jù)預先設(shè)置的文件標識信息與文件源端地址信息的對應關(guān)系進行查找，獲取文件源端地址信息。
步驟s503，多文件上傳控制端22根據(jù)所述文件源端的地址信息和所述文件標識信息向與待上傳文件對應的其中一個文件源端發(fā)送數(shù)據(jù)上傳請求。
步驟s504，所述文件源端向多文件上傳控制端22發(fā)送對應的數(shù)據(jù)幀。
步驟s505，多文件上傳控制端22將數(shù)據(jù)讀取到內(nèi)存中，并判斷用戶設(shè)備21是否要求進行數(shù)據(jù)加密和/或壓縮處理，若要求進行數(shù)據(jù)加密和/或壓縮處理，則轉(zhuǎn)步驟s511，否則，轉(zhuǎn)步驟s506。因為本實施例中要求進行數(shù)據(jù)加密和壓縮處理，所以轉(zhuǎn)步驟s511。
步驟s506，多文件上傳控制端22在內(nèi)存中將數(shù)據(jù)幀打包。
步驟s507，多文件上傳控制端22將數(shù)據(jù)上傳至目的端24。
步驟s508，判斷該文件源端中待上傳文件的數(shù)據(jù)是否已經(jīng)全部上傳完畢，若已上傳完畢，進入步驟s509，否則，轉(zhuǎn)步驟s512。
步驟s509，多文件上傳控制端22判斷是否所有文件源端中的待上傳文件都已上傳完畢，若已上傳完畢，則轉(zhuǎn)步驟s510，否則，轉(zhuǎn)步驟s513。
步驟s510，多文件上傳控制端22關(guān)閉與目的端24的連接，向用戶設(shè)備21返回成功響應并結(jié)束。
步驟s511，多文件上傳控制端22對數(shù)據(jù)進行加密及壓縮處理，并轉(zhuǎn)步驟s506。本步驟采用通用的數(shù)據(jù)加密和/或壓縮技術(shù)，可利用winrar進行解密及解壓縮。
步驟s512，多文件上傳控制端22繼續(xù)向步驟s508中所述文件源端發(fā)送數(shù)據(jù)上傳請求，并返回步驟s504。
步驟s513，多文件上傳控制端22向另一存儲待上傳文件的文件源端發(fā)送數(shù)據(jù)上傳請求，并返回步驟s504。
以上公開的僅為本發(fā)明的一個具體實施例，但是，本發(fā)明并非局限于此，任何本領(lǐng)域的技術(shù)人員能思之的變化都應落入本發(fā)明的保護范圍。
權(quán)利要求
1.一種多文件上傳的方法，其特征在于，包括以下步驟接收多文件上傳請求；根據(jù)所述多文件上傳請求從多個文件源端獲取多文件數(shù)據(jù)；將所述多文件數(shù)據(jù)在內(nèi)存中打包并上傳至目的端。
2.如權(quán)利要求1所述多文件上傳的方法，其特征在于，所述多文件上傳請求包括文件標識信息；或文件標識信息和文件源端地址信息。
3.如權(quán)利要求2所述多文件上傳的方法，其特征在于，當所述多文件上傳請求包括文件標識信息時，所述從多個文件源端獲取多文件數(shù)據(jù)包括以下步驟根據(jù)所述文件標識信息，獲取文件源端地址信息；根據(jù)所述文件源端地址信息和所述文件標識信息，向?qū)奈募炊税l(fā)送數(shù)據(jù)上傳請求；所述文件源端發(fā)送對應的數(shù)據(jù)幀。
4.如權(quán)利要求3所述多文件上傳的方法，其特征在于，所述獲取文件源端地址信息的過程具體為根據(jù)所述文件標識信息，在所有文件源端中進行匹配查找，獲取文件源端地址信息。
5.如權(quán)利要求3所述多文件上傳的方法，其特征在于，所述獲取文件源端地址信息的過程具體為根據(jù)所述文件標識信息，在文件標識信息與文件源端地址信息的對應關(guān)系表中進行查找，獲取文件源端地址信息。
6.如權(quán)利要求2所述多文件上傳的方法，其特征在于，當所述多文件上傳請求包括文件標識信息和文件源端地址信息時，所述從多個文件源端獲取多文件數(shù)據(jù)包括以下步驟根據(jù)所述文件源端地址信息和所述文件標識信息，向?qū)奈募炊税l(fā)送數(shù)據(jù)上傳請求；所述文件源端發(fā)送對應的數(shù)據(jù)幀。
7.如權(quán)利要求1所述多文件上傳的方法，其特征在于，所述多文件上傳請求中還包括數(shù)據(jù)處理請求。
8.如權(quán)利要求7所述多文件上傳的方法，其特征在于，所述數(shù)據(jù)處理請求包括數(shù)據(jù)加密請求和/或壓縮處理請求。
9.如權(quán)利要求1所述多文件上傳的方法，其特征在于，所述多文件數(shù)據(jù)在內(nèi)存中的打包過程與上傳過程同時進行，實現(xiàn)多文件數(shù)據(jù)的實時上傳。
10.如權(quán)利要求1或9所述多文件上傳的方法，其特征在于，上傳后的包文件為一個文件。
11.一種多文件上傳系統(tǒng)，其特征在于，包括多文件上傳控制端、文件源端和目的端，所述多文件上傳控制端分別與所述文件源端和所述目的端連接；所述多文件上傳控制端，用于從多個所述文件源端中獲取多文件數(shù)據(jù)，對所述多文件數(shù)據(jù)在內(nèi)存中進行打包，并上傳至所述目的端；所述文件源端，用于存儲所述多文件數(shù)據(jù)；所述目的端，用于接收并存儲所述多文件打包后形成的包文件。
12.如權(quán)利要求11所述多文件上傳系統(tǒng)，其特征在于，所述多文件上傳控制端中存儲有文件標識信息與文件源端地址信息的對應關(guān)系表。
13.如權(quán)利要求11所述多文件上傳系統(tǒng)，其特征在于，所述多文件上傳控制端還用于對所述獲取的多文件數(shù)據(jù)進行處理。
14.如權(quán)利要求13所述多文件上傳系統(tǒng)，其特征在于，所述數(shù)據(jù)處理包括數(shù)據(jù)加密和/或壓縮處理。
全文摘要
本發(fā)明提供一種多文件上傳系統(tǒng)，包括多文件上傳控制端、文件源端和目的端，所述多文件上傳控制端分別與所述文件源端和所述目的端連接。本發(fā)明還提供一種多文件上傳的方法，首先接收多文件上傳請求，然后根據(jù)所述多文件上傳請求從多個文件源端獲取多文件數(shù)據(jù)，最后將所述多文件數(shù)據(jù)在內(nèi)存中打包并上傳至目的端。本發(fā)明采用在內(nèi)存中將多文件進行打包并上傳的技術(shù)，減少了頻繁讀寫磁盤造成的時間耗損；而且，當待上傳的文件存儲于不同的文件源端時，采用本發(fā)明，減少了多文件上傳時的人工操作，提高了多文件上傳的效率。
文檔編號H04L29/06GK1921397SQ20061015211
公開日2007年2月28日 申請日期2006年9月13日 優(yōu)先權(quán)日2006年9月13日
發(fā)明者李斌, 孫曉冬 申請人:華為技術(shù)有限公司