本發(fā)明涉及電子數(shù)據(jù)傳輸技術領域，特別涉及一種文件傳輸控制方法和系統(tǒng)。

背景技術：

在實際工作中，由于用戶往往無法直接接觸到服務器，所以，一般用戶需要利自己的客戶端通過網(wǎng)絡或線纜向服務器端傳輸需要上傳的電子文件，以便服務器接收到該電子文件后，能按照用戶要求或指示，對該文件進行保存或者進一步的處理。

目前，一般大都采用基于TCP(Transmission Control Protocol，傳輸控制協(xié)議)的FTP(File Transfer Protocol，文件傳輸協(xié)議)模式連接進行上述文件傳輸。該方法可以在客戶端和服務器端中間建立文件傳輸通道和FTP連接通道。其中，文件傳輸通道可以用于客戶端向服務器端傳輸待傳輸文件。而FTP連接通道可以用于發(fā)送或傳輸FTP指令，例如：創(chuàng)建待傳輸文件列表指令和分配待傳輸文件存儲位置的指令等。但是，由于FTP連接通道自身技術上的局限性，不能通過該通道發(fā)送或傳遞傳輸暫停命令或傳輸恢復命令。因此，使用該方法傳輸文件時，往往存在不能暫停和/或恢復待傳輸文件傳輸?shù)募夹g問題。導致用戶無法通過客戶端對待傳輸文件的傳輸過程進行主動的控制，即，無法按照用戶的要求，主動暫?；蛘呋謴痛齻鬏斘募膫鬏?，從而給用戶傳輸文件帶來了很多的不便，降低了用戶的體驗度。

針對上述問題，目前尚未提出有效的解決方案。

技術實現(xiàn)要素：

本發(fā)明實施例提供了一種文件傳輸控制方法和系統(tǒng)，通過設計命令通道，以實現(xiàn)用戶可以通過該命令通道對文件傳輸進行主動控制的目的。

本發(fā)明實施例提供了一種文件傳輸控制方法，包括：

客戶端在所述客戶端和服務器端之間建立命令通道；

所述客戶端獲取待傳輸文件后，向所述服務器端發(fā)送所述待傳輸文件的傳輸請求，并建立所述待傳輸文件的文件傳輸通道；

所述客戶端通過所述文件傳輸通道，將所述待傳輸文件發(fā)送至所述服務器端；

其中，在所述客戶端通過所述文件傳輸通道，將所述待傳輸文件發(fā)送至所述服務器端的過程中，所述客戶端可通過所述命令通道向所述服務器端發(fā)送控制命令，以控制所述待傳輸文件的傳輸，其中，所述控制命令包括：傳輸暫停命令和/或傳輸恢復命令。

在一個實施方式中，在所述控制命令為傳輸暫停命令的情況下，所述方法還包括：

所述服務器端根據(jù)所述傳輸暫停命令，暫停所述文件傳輸通道中所述待傳輸文件的傳輸；

將所述待傳輸文件中已上傳至所述服務器端的內容，作為緩存文件保存在所述服務器端。

在一個實施方式中，在所述控制命令為傳輸恢復命令的情況下，所述方法還包括：

所述服務器端根據(jù)所述傳輸恢復命令，檢測所述服務器端是否存在所述待傳輸文件的緩存文件；

如果所述服務器端存在所述待傳輸文件的緩存文件，則將所述緩存文件的數(shù)據(jù)信息發(fā)送至所述客戶端；

所述客戶端根據(jù)所述緩存文件的數(shù)據(jù)信息，確定所述待傳輸文件的傳輸斷點位置；

所述客戶端以所述斷點位置作為所述待傳輸文件續(xù)傳的起始位置，通過所述文件傳輸通道，向服務器端續(xù)傳所述待傳輸文件。

在一個實施方式中，在所述服務器端根據(jù)所述傳輸恢復命令，檢測所述服務器端是否存在所述待傳輸文件的緩存文件之后，所述方法還包括：

如果所述服務器端不存在所述待傳輸文件的緩存文件，則所述服務器端向所述客戶端發(fā)送重傳指令，其中，所述重傳指令用于指示所述客戶端再次將所述待傳輸文件通過所述文件傳輸通道發(fā)送至所述服務器端。

在一個實施方式中，所述緩存文件的數(shù)據(jù)信息包括：所述待傳輸文件的緩存文件的文件大小和所述緩存文件的MD5信息。

在一個實施方式中，所述客戶端獲取待傳輸文件后，建立所述待傳輸文件的文件傳輸通道，包括：

所述客戶端將所述待傳輸文件寫入數(shù)據(jù)庫，以等待傳輸；

所述客戶端通過傳輸執(zhí)行線程取出所述待傳輸文件，并根據(jù)所述待傳輸文件，創(chuàng)建所述待傳輸文件的獨立傳輸線程；

通過所述獨立傳輸線程，在所述客戶端和所述服務器端之間，為所述待傳輸文件建立所述待傳輸文件的所述文件傳輸通道。

在一個實施方式中，在創(chuàng)建所述待傳輸文件的獨立傳輸線程后，在通過所述文件傳輸通道向所述服務器端傳輸所述待傳輸文件的過程中，所述客戶端和所述服務器端可通過所述獨立傳輸線程交互傳輸信息，其中，所述傳輸信息包括：所述待傳輸文件的傳輸狀態(tài)和所述服務器端接收所述待傳輸文件的進度。

在一個實施方式中，在所述待傳輸文件中包括多個文件的情況下，所述方法還包括：

所述客戶端根據(jù)所述多個文件生成文件列表數(shù)據(jù)；

所述客戶端將所述多個文件寫入數(shù)據(jù)庫，并將所述多個文件中的各個文件在數(shù)據(jù)庫中的狀態(tài)記錄標記為未完成；

所述客戶端通過傳輸執(zhí)行線程取出所述待傳輸文件，包括：所述客戶端根據(jù)所述文件列表數(shù)據(jù)，通過所述傳輸執(zhí)行線程，依次取出所述多個文件中的各個文件。

在一個實施方式中，在所述服務器端完成所述待傳輸文件的接收后，所述方法還包括：

所述服務器端對已接收的所述待傳輸文件的完整性進行校驗，得到校驗結果；

通過所述獨立傳輸線程，將所述校驗結果反饋至所述客戶端；

所述客戶端接收所述校驗結果，并根據(jù)所述校驗結果確定傳輸至服務器端的待傳輸文件是否完整；

如果完整，則釋放所述待傳輸文件的獨立傳輸線程，并將數(shù)據(jù)庫中所述待傳輸文件的狀態(tài)記錄改為完成。

在一個實施方式中，所述命令通道包括：UDT命令通道或TCP命令通道。

本發(fā)明實施例提供了又一種文件傳輸控制方法，包括：

接收客戶端發(fā)送的待傳輸文件的傳輸請求；

接收所述客戶端通過文件傳輸通道發(fā)送的所述待傳輸文件；

其中，在接收所述客戶端通過所述文件傳輸通道發(fā)送的所述待傳輸文件的過程中，接收客戶端發(fā)送的控制命令，并根據(jù)所述控制命令控制所述待傳輸文件的傳輸，其中，所述控制命令包括：傳輸暫停命令和/或傳輸恢復命令。

在一個實施方式中，在所述控制命令為傳輸暫停命令的情況下，根據(jù)所述控制命令控制所述待傳輸文件的傳輸包括：

根據(jù)所述傳輸暫停命令，暫停所述文件傳輸通道中的所述待傳輸文件的傳輸；

將所述待傳輸文件中已上傳至所述服務器端的內容，作為緩存文件，保存在所述服務器端。

在一個實施方式中，在所述控制命令為傳輸恢復命令的情況下，根據(jù)所述控制命令控制所述待傳輸文件的傳輸包括：

根據(jù)所述傳輸恢復命令，檢測所述服務器端是否存在所述待傳輸文件的緩存文件；

如果所述服務器端存在所述待傳輸文件的緩存文件，則將所述緩存文件的數(shù)據(jù)信息發(fā)送至所述客戶端。

在一個實施方式中，在根據(jù)所述傳輸恢復命令，檢測所述服務器端是否存在所述待傳輸文件的緩存文件之后，所述方法還包括：

如果所述服務器端不存在所述待傳輸文件的緩存文件，則向所述客戶端發(fā)送重傳指令，其中，所述重傳指令用于指示所述客戶端再次將所述待傳輸文件通過所述文件傳輸通道發(fā)送至所述服務器端。

在一個實施方式中，在接收所述客戶端通過文件傳輸通道發(fā)送的所述待傳輸文件后，所述方法還包括：

對已接收的所述待傳輸文件的完整性進行校驗，得到校驗結果；

將所述校驗結果反饋至所述客戶端。

本發(fā)明提供了再一種文件傳輸控制方法，包括：

在所述客戶端和服務器端之間建立命令通道；

獲取待傳輸文件后，向所述服務器端發(fā)送所述待傳輸文件的傳輸請求，并建立所述待傳輸文件的文件傳輸通道；

通過所述文件傳輸通道，將所述待傳輸文件發(fā)送至所述服務器端；

其中，在將所述待傳輸文件發(fā)送至所述服務器端的過程中，可通過所述命令通道向所述服務器端發(fā)送控制命令，以控制所述待傳輸文件的傳輸，其中，所述控制命令包括：傳輸暫停命令和/或傳輸恢復命令。

在一個實施方式中，在所述控制命令為傳輸暫停命令的情況下，所述方法還包括：

暫停所述文件傳輸通道中所述待傳輸文件的傳輸。

在一個實施方式中，在所述控制命令為傳輸恢復命令，且所述服務器端存在所述待傳輸文件的緩存文件的情況下，所述方法還包括：

接收所述待傳輸文件的緩存文件的數(shù)據(jù)信息；

根據(jù)所述緩存文件的數(shù)據(jù)信息，確定所述待傳輸文件的傳輸斷點位置；

以所述斷點位置作為所述待傳輸文件續(xù)傳的起始位置，通過所述文件傳輸通道，向所述服務器端續(xù)傳所述待傳輸文件。

在一個實施方式中，在所述控制命令為傳輸恢復命令，且所述服務器端不存在所述待傳輸文件的緩存文件的情況下，所述方法還包括：

接收所述服務器端發(fā)送的重傳指令；

根據(jù)所述重傳指令，將所述待傳輸文件通過所述文件傳輸通道再次發(fā)送至所述服務器端。

在一個實施方式中，所述獲取待傳輸文件后，建立所述待傳輸文件的文件傳輸通道，包括：

將所述待傳輸文件寫入數(shù)據(jù)庫，以等待傳輸；

通過傳輸執(zhí)行線程取出所述待傳輸文件，并根據(jù)所述待傳輸文件，創(chuàng)建所述待傳輸文件的獨立傳輸線程；

通過所述獨立傳輸線程，在所述客戶端和所述服務器端之間，為所述待傳輸文件建立所述待傳輸文件的文件傳輸通道。

在一個實施方式中，在所述待傳輸文件中包括多個文件的情況下，所述方法還包括：

根據(jù)所述多個文件生成文件列表數(shù)據(jù)；

將所述多個文件寫入數(shù)據(jù)庫，并將所述多個文件中各個文件在數(shù)據(jù)庫中的狀態(tài)記錄標記為未完成；

通過傳輸執(zhí)行線程取出所述待傳輸文件，包括：根據(jù)所述文件列表數(shù)據(jù)，通過所述傳輸執(zhí)行線程，依次取出所述多個文件中的各個文件。

在一個實施方式中，在將所述待傳輸文件發(fā)送至所述服務器端后，所述方法還包括：

接收所述服務器端發(fā)送的校驗結果，并根據(jù)所述校驗結果確定傳輸至所述服務器端的所述待傳輸文件是否完整；

如果完整，則釋放所述待傳輸文件的獨立傳輸線程，并將數(shù)據(jù)庫中所述待傳輸文件的狀態(tài)記錄改為完成。

本發(fā)明實施例還提供了一種文件傳輸控制系統(tǒng)，包括：

客戶端，用于通過文件傳輸通道傳輸待傳輸文件，并可通過命令通道傳輸控制命令，其中，所述控制命令包括：傳輸暫停命令和/或傳輸恢復命令；

服務器端，用于接收所述客戶端通過所述文件傳輸通道傳輸?shù)乃龃齻鬏斘募屯ㄟ^所述命令通道傳輸?shù)乃隹刂泼睿M而根據(jù)所述控制命令，控制所述待傳輸文件的傳輸。

在本發(fā)明實施例中，通過設計命令通道，客戶端可以利用該命令通道向服務器端發(fā)送傳輸暫?；蛘邆鬏敾謴兔?，解決了現(xiàn)有方法中存在的文件傳輸時不能暫停和/或恢復待傳輸文件傳輸?shù)募夹g問題，實現(xiàn)了用戶可以通過命令通道對文件傳輸過程進行主動控制的目的，從而，提高了用戶的體驗度。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，并不構成對本發(fā)明的限定。在附圖中：

圖1是根據(jù)本發(fā)明實施例的文件傳輸控制方法的處理流程圖；

圖2是根據(jù)本發(fā)明實施例的文件傳輸控制方法中處理多個待傳輸文件傳輸?shù)奶幚砹鞒虉D；

圖3是根據(jù)本發(fā)明實施例的文件傳輸控制方法的具體應用的場景示意圖；

圖4是根據(jù)本發(fā)明實施例的又一個文件傳輸控制方法的處理流程圖；

圖5是根據(jù)本發(fā)明實施例的文件傳輸控制方法具體實施時服務器端在接收待傳輸文件前的數(shù)據(jù)處理流程圖；

圖6是根據(jù)本發(fā)明實施例的文件傳輸控制方法具體實施時服務器端接收待傳輸文件過程中的數(shù)據(jù)處理流程圖；

圖7是根據(jù)本發(fā)明實施例的再一個文件傳輸控制方法的處理流程圖；

圖8是根據(jù)本發(fā)明實施例的文件傳輸控制方法具體實施時客戶端在傳輸待傳輸文件前的數(shù)據(jù)處理流程圖；

圖9是根據(jù)本發(fā)明實施例的文件傳輸控制方法具體實施時客戶端在傳輸待傳輸文件過程中的數(shù)據(jù)處理流程圖

圖10是根據(jù)本發(fā)明實施例的文件傳輸控制系統(tǒng)的結構示意圖。

具體實施方式

為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，下面結合實施方式和附圖，對本發(fā)明做進一步詳細說明。在此，本發(fā)明的示意性實施方式及其說明用于解釋本發(fā)明，但并不作為對本發(fā)明的限定。

考慮到，在利用基于TCP的FTP模式連接進行文件傳輸時，該方法雖然可以在客戶端和服務器端之間建立文件傳輸通道和FTP連接通道。但是，由于該方法建立的FTP連接通道自身的技術上存在的局限性，通過該通道只可以發(fā)送或傳輸FTP指令，不能發(fā)送或傳遞傳輸暫停命令和/或傳輸恢復命令，從而，導致使用該方法傳輸文件時，存在不能暫停或恢復待傳輸文件傳輸?shù)募夹g問題，降低了用戶的體驗度。針對產(chǎn)生上述技術問題的實質原因，考慮可以在原有的文件傳輸通道以外，設計專門用于傳輸控制命令的命令通道。其中，上述控制命令可以包括：傳輸暫停命令和/或傳輸恢復命令。從而，用戶可以通過該命令通道向服務器端發(fā)送傳輸暫停或傳輸恢復的控制命令，以實現(xiàn)主動控制待傳輸文件的傳輸?shù)哪康摹?/p>

基于上述思路，請參閱圖1，本發(fā)明實施例提供了一種文件傳輸控制方法，具體可以包括：

步驟101：客戶端在客戶端和服務器端之間建立命令通道。

在本實施方式中，客戶端一般可以是用戶直接操作或使用的終端設備或者軟件。具體可以是用戶使用的硬件設備，例如：智能手機、平板電腦、筆記本電腦、臺式計算機或者智能手表等終端設備。也可以是某些能夠實現(xiàn)具體功能的應用軟件，例如：某手機聊天軟件、某手機圖片傳輸軟件或者XX瀏覽器等應用軟件。

在本實施方式中，服務器端可以是由具有數(shù)據(jù)存儲和數(shù)據(jù)處理功能的一個計算機或多個計算機組成。其中，服務器端和客戶端一般可以通過移動網(wǎng)絡、有線網(wǎng)絡、無線網(wǎng)絡等互聯(lián)網(wǎng)絡或者線纜進行文件數(shù)據(jù)的傳輸。

在本實施方式中，為了解決現(xiàn)有方法中存在的由于不能發(fā)送暫?；蚧謴兔睿瑢е碌牟荒軐Υ齻鬏斘募膫鬏斶M行相應的控制，本實施例通過客戶端在客戶端和服務端之間先建立一個命令通道。其中，該命令通道專門用于傳輸控制命令。此外，一般情況下，一個客戶端與一個服務器端之間一般配置一個命令通道能較好地滿足用戶需求，然而，值得注意的是，如果需要，也可以在一個客戶端與一個服務器端之間建立多個命令通道，根據(jù)本發(fā)明實施例的文件傳輸控制方法同樣適用。對此，本申請不做限定。

步驟102：客戶端獲取待傳輸文件后，向服務器端發(fā)送待傳輸文件的傳輸請求，并建立該待傳輸文件的文件傳輸通道。

在本實施方式中，所述傳輸請求可以是一種按照預設格式編寫的代碼。其中，由于該代碼按照預設格式編寫，使得上述代碼可以被對應的服務器端準確識別、解析、處理。此外，該代碼內還可以包含有用戶請求傳輸待傳輸文件的基本信息。具體地，該基本信息可以包括：待傳輸文件的大小、傳輸待傳輸文件的客戶端名稱和傳輸該待傳輸文件的時間等。

在本實施方式中，客戶端在接收待傳輸文件后，為了向服務器端傳輸該待傳輸文件，需要先在客戶端和服務器端建立該待傳輸文件的文件傳輸通道。具體建立待傳輸文件的文件傳輸通道的過程具體可以參閱以下實施方式。

在一個實施方式中，為了建立該文件的傳輸通道，具體可以包括：客戶端將待傳輸文件寫入數(shù)據(jù)庫，以等待傳輸；客戶端通過傳輸執(zhí)行線程取出待傳輸文件，并根據(jù)待傳輸文件，創(chuàng)建待傳輸文件的獨立傳輸線程；通過獨立傳輸線程，在客戶端和服務器端之間，為該待傳輸文件建立該待傳輸文件的文件傳輸通道。其中，本實施方式中，傳輸執(zhí)行線程是一直存在的線程，具有較高的權限等級。相對的，獨立傳輸線程權限等級較低，且只有在客戶端接收到待傳輸文件后，通過傳輸執(zhí)行線程，才針對該待傳輸文件建立專門負責協(xié)助該待傳輸文件傳輸?shù)莫毩鬏斁€程，一旦該待傳輸文件完成完整的傳輸，該獨立傳輸線程隨即被釋放。然而，值得注意的是，在本實施方式中，在一個客戶端和一個服務器端之間只有一個傳輸執(zhí)行線程，一般一個傳輸執(zhí)行線程就可以滿足該客戶端的基本需求。但是，如果有需要，也可在一個客戶端和一個服務器端之間設置多個傳輸執(zhí)行線程，并根據(jù)本發(fā)明實施例的文件傳輸控制方法，同樣適用。對此，本申請在此不做限定。

在一個實施方式中，在待傳輸文件中包括多個文件的情況下，為了保證客戶端可以按照次序依次完成多個文件中的各個文件的傳輸，可以參閱圖2，按照以下方式處理：

步驟201：客戶端根據(jù)待傳輸文件的多個文件生成文件列表數(shù)據(jù)；

步驟202：客戶端將多個文件寫入數(shù)據(jù)庫，并將多個文件中的各個文件在數(shù)據(jù)庫中的狀態(tài)記錄標記為未完成；

步驟203：客戶端通過傳輸執(zhí)行線程依次取出待傳輸文件中的多個文件的各個文件，該步驟具體又可以包括：客戶端根據(jù)文件列表數(shù)據(jù)，通過傳輸執(zhí)行線程，依次取出多個文件中的各個文件，再對取出的各個文件分別進行后續(xù)處理。

在本實施方式中，進行步驟203時，根據(jù)多個文件建立對應的對個文件傳輸通道。需要說明的是，根據(jù)本發(fā)明實施例的文件傳輸控制方法，對于在一個客戶端與一個服務器端之間存在多個文件傳輸通道傳輸待傳輸文件的情形，同樣適用。但是，由于客戶端以及服務器端自身硬件設備的局限，導致其處理能力有限，因此在一個客戶端與一個服務器端之間的文件通道個數(shù)有上限。為了提高該上限，一般可以通過處理能力更強的客戶端以及服務器端來提升設備自身的處理能力，從而提高該上限。

在一個實施方式中，為了讓用戶通過客戶端可以實時了解文件傳輸?shù)那闆r，進而可以參考具體的文件傳輸?shù)那闆r進行主動控制，在創(chuàng)建待傳輸文件的獨立傳輸線程后，在通過文件傳輸通道向服務器端傳輸待傳輸文的過程中，客戶端和服務器端還可以通過獨立傳輸線程交互傳輸信息，其中，上述傳輸信息具體可以包括：該待傳輸文件的傳輸狀態(tài)和服務器端接收待傳輸文件的進度。然而，值得注意的是，上述所列舉的傳輸信息僅是一種示意性描述，是為了更好地說明本發(fā)明，在實際執(zhí)行的過程中，還可以包括其他用戶需要或者服務器端和/或客戶端在文件傳輸過程中所能提供的傳輸信息，具體可以根據(jù)實際情況進行選取，本申請對此不作限定。在客戶端通過獨立傳輸線程接收到具體的傳輸信息后，可以進一步地將該信息發(fā)送給客戶端的顯示設備或其他數(shù)據(jù)輸出設備，通過客戶端的顯示設備或其他數(shù)據(jù)輸出設備將用戶需要了解的信息呈現(xiàn)直觀地給用戶，從而，改善用戶體驗度。

步驟103：客戶端通過文件傳輸通道，將待傳輸文件發(fā)送至服務器端。

在本實施方式中，通過文件傳輸通道，客戶端即可將待傳輸文件發(fā)送至對應的服務器端。具體地，客戶端可以將待傳輸文件按照預設規(guī)則，處理成滿足網(wǎng)絡通信協(xié)議的數(shù)據(jù)代碼。通過已經(jīng)設立好的文件傳輸通道傳輸該待傳輸文件的過程，可以是根據(jù)通信網(wǎng)絡協(xié)議將該待傳輸文件對應的數(shù)據(jù)代碼，通過互聯(lián)網(wǎng)絡或者線纜傳輸至客戶端?？蛻舳私邮赵摂?shù)據(jù)代碼，進而根據(jù)網(wǎng)絡通信協(xié)議識別、并獲取該數(shù)據(jù)代碼對應的待傳輸文件，從而，完成待傳輸文件的傳輸。

在一個實施方式中，為了確保已經(jīng)完整地接收了該待傳輸文件，在接收該待傳輸文件之后，根據(jù)本發(fā)明實施例的文件傳輸控制方法還包括：服務器端對已接收的待傳輸文件的完整性進行校驗，得到校驗結果；通過獨立傳輸線程，將校驗結果反饋至客戶端；客戶端接收該校驗結果，并根據(jù)該校驗結果確定傳輸至服務器端的待傳輸文件是否完整；如果完整，則釋放待傳輸文件的獨立傳輸線程，并將數(shù)據(jù)庫中待傳輸文件的狀態(tài)記錄改為完成；如果不完整，則將校驗結果通過客戶端的數(shù)據(jù)輸出設備反饋給用戶，并提示用戶該文件需重傳。

步驟104：在客戶端通過文件傳輸通道，將待傳輸文件發(fā)送至服務器端的過程中，客戶端可以通過命令通道向服務器端發(fā)送控制命令，以控制待傳輸文件的傳輸，其中，控制命令可以包括：傳輸暫停命令和/或傳輸恢復命令。

在本實施方式中，在客戶端通過文件傳輸通道向服務器端傳輸待傳輸文件的過程中，客戶端可以通過命令通道向服務器端發(fā)出具體的控制命令，服務器端根據(jù)接收到的控制命令，執(zhí)行相應的暫停傳輸或恢復傳輸?shù)牟僮?。具體地，當客戶端通過命令通道向服務器端發(fā)送傳輸暫停命令時，服務器端根據(jù)接收的傳輸暫停命令，暫停文件傳輸通道中帶傳輸文件的傳輸。當客戶端通過命令通道向服務器端發(fā)送傳輸恢復命令時，服務器端根據(jù)接收的傳輸恢復命令，恢復文件傳輸通道中被暫?；蛘咧袛嗟拇齻鬏斘募膫鬏?。從而，實現(xiàn)了對文件傳輸?shù)闹鲃涌刂啤?/p>

在一個實施方式中，為了避免恢復傳輸時對待傳輸文件的某些已上傳內容的重復傳輸，首先執(zhí)行暫停命令，暫停待傳輸文件的傳輸?shù)耐瑫r，可以將已上傳至服務器端的內容保存在服務器端。即，在控制命令為傳輸暫停命令的情況下，可以按照以下方式處理：服務器端根據(jù)傳輸暫停命令，暫停文件傳輸通道中待傳輸文件的傳輸；將待傳輸文件中已上傳至服務器端的內容，作為緩存文件保存在服務器端。

在一個實施方式中，為了在恢復傳輸時，可以根據(jù)已保存在服務器端的文件，只續(xù)傳待傳輸文件中還沒有上傳至服務器端的內容，從而減少客戶端傳輸?shù)娜蝿樟?，可以先檢測服務器端是否存在該待傳輸文件的緩存文件，根據(jù)檢測結果，在有針對性地只續(xù)傳待傳輸文件尚未傳輸至服務器端的內容。即，在控制命令為傳輸恢復命令的情況下，可以按照以下方式處理：服務器端根據(jù)傳輸恢復命令，檢測服務器端是否存在待傳輸文件的緩存文件；如果服務器端存在待傳輸文件的緩存文件，則將該緩存文件的數(shù)據(jù)信息發(fā)送至客戶端；客戶端根據(jù)緩存文件的數(shù)據(jù)信息，確定待傳輸文件的傳輸斷點位置；客戶端以斷點位置作為待傳輸文件續(xù)傳的起始位置，通過文件傳輸通道，向服務器端續(xù)傳待傳輸文件。

在本實施方式中，上述緩存文件的數(shù)據(jù)信息具體可以包括：待傳輸文件的緩存文件的文件大小和該緩存文件的MD5信息。然而，值得注意的是，上述所列舉的緩存文件的數(shù)據(jù)信息僅是一種示意性描述，是為了更好地說明本發(fā)明，在實際執(zhí)行的過程中，還可以包括其他可用于確定待傳輸文件的傳輸斷點位置的數(shù)據(jù)信息，具體可以根據(jù)實際情況進行選取，本申請對此不作限定。需要說明的是，客戶端根據(jù)待傳輸文件的緩存文件的文件大小和該緩存文件的MD5信息等數(shù)據(jù)信息，可以確定待傳輸文件的傳輸斷點位置。其中，上述的MD5(Message Digest Algorithm MD5，第五版消息摘要算法)信息，具體是指計算機安全領域廣泛使用的一種散列函數(shù)，用以提供消息的完整性保護。本發(fā)明實施例具體實施主要通過MD5算法獲取緩存文件的MD5信息。具體應用時，也可以使用SHA-128或者SHA-256等hash算法獲取緩存文件的MD5信息。對此，本申請不做限定。

在一個實施方式中，當服務器端中不存在待傳輸文件的緩存文件時，意味著可能客戶端之前未向該服務器端傳輸過該待傳輸文件，或者可能是之前有傳輸，但由于某些原因，服務器端未保存該待傳輸文件已上傳至服務器端的內容。這種情況，往往服務器端要指示客戶端重新上傳該待傳輸文件。具體執(zhí)行時，可以按照以下方式執(zhí)行：如果服務器端不存在該待傳輸文件的緩存文件，則服務器端向客戶端發(fā)送重傳指令，其中，重傳指令用于指示客戶端再次將待傳輸文件通過文件傳輸通道發(fā)送至服務器端。從而，完成了對該待傳輸文件的傳輸通道。

在本發(fā)明實施例中，通過設計命令通道，客戶端可以利用該命令通道向服務器端發(fā)送傳輸暫?；蛘邆鬏敾謴兔?，解決了現(xiàn)有方法中存在的文件傳輸時不能暫停和/或恢復待傳輸文件傳輸?shù)募夹g問題，實現(xiàn)了用戶可以通過命令通道對文件傳輸過程進行主動控制的目的，從而，提高了用戶的體驗度。

在一個實施例中，請參閱圖3，用戶想要通過臺式計算機向服務器端傳輸一個文件：具體實施時，用戶的臺式計算機在臺式計算機和服務器之間建立命令通道。臺式計算機在接收到用戶想要上傳的文件后，先將該文件寫入數(shù)據(jù)庫等待傳輸，并根據(jù)該文件向服務器發(fā)出文件傳輸請求。服務器接收到文件傳輸請求后，根據(jù)文件傳輸請求中的信息，檢測該服務器端是否存在該文件的緩存文件，如果存在，則將該緩存文件的文件大小和MD5信息等緩存文件的數(shù)據(jù)信息發(fā)送給計算機，如果不存在，則向計算機發(fā)送重傳指令。除進行緩存檢測外，服務器還要進行其他的接收準備工作，例如：確定傳輸該文件的計算機名稱和位置，并為該文件分配相應的存儲位置等。服務器完成準備工作后，向計算機發(fā)出允許文件傳輸?shù)闹甘?。臺式計算機通過傳輸執(zhí)行線程取出該文件，并根據(jù)該文件，創(chuàng)建該文件的獨立傳輸線程，進而，通過該獨立傳輸線程，在臺式計算機和服務器之間為該文件建立文件傳輸通道。在開始傳輸時，如果服務器端發(fā)送給計算機的是緩存文件的數(shù)據(jù)信息，臺式計算機則根據(jù)該文件的緩存文件的數(shù)據(jù)信息確定該文件傳輸?shù)臄帱c位置，以該斷點位置為續(xù)傳起始位置，續(xù)傳該文件。如果服務器端發(fā)送給計算機的是重傳指令，臺式計算機則根據(jù)重傳指令，重新上傳該文件。在具體傳輸過程中，用戶根據(jù)自己的需要可以隨時通過臺式計算機通過命令通道向服務器端發(fā)送傳輸暫停命令。服務器端接收到傳輸暫停命令后暫停文件傳輸通道中該文件傳輸?shù)耐瑫r，將該文件已上傳至服務器端的內容做為緩存文件保存在服務器端。用戶同樣也可以在發(fā)送傳輸暫停命令后通過命令通道向服務器端發(fā)出傳輸恢復命令。服務器端接收該傳輸恢復命令，檢測服務器端是否存在該文件的緩存文件，并將緩存文件的數(shù)據(jù)信息發(fā)送給臺式計算機。臺式計算機跟據(jù)緩存文件的數(shù)據(jù)細信息，確定恢復傳輸時續(xù)傳的斷點位置，再以這個新的斷點位置為續(xù)傳起始位置，續(xù)傳該文件。除此外，在整個傳輸過程中，服務器端和臺式計算機可以通過該文件的獨立傳輸線程，交互該文件的傳輸信息。具體地，例如服務器端可以將該文件的接收進度通過該文件的獨立傳輸線程發(fā)送至臺式計算機，臺式計算機再將該文件的接收進度通過臺式機的顯示屏呈現(xiàn)給用戶，從而讓用戶了解該文件的傳輸情況，以便用戶根據(jù)具體情況，決定是否對該文件的傳輸進行控制。最后，在服務器端完成該文件的接收之后，服務器端還要對已接收的文件的完整性進行校驗，得到校驗結果；通過獨立傳輸線程，將該校驗結果反饋至臺式計算機；臺式計算機接收該校驗結果，并根據(jù)該校驗結果確定傳輸至服務器端的該文件是否完整；如果完整，則釋放該文件的獨立傳輸線程，并將數(shù)據(jù)庫中該文件的狀態(tài)記錄改為完成；如果不完整，則通過顯示屏向用戶反饋校驗結果，并提示用戶該文件需重傳。通過本發(fā)明實施例的文件傳輸控制方法實現(xiàn)了用戶對文件傳輸?shù)膶嵤┛刂疲€通過信息的交互，進一步改善了用戶的體驗。

在一個實施方式中，為了滿足用戶更高的文件傳輸要求，本發(fā)明實施例根據(jù)UDT數(shù)據(jù)傳輸協(xié)議建立上述命令通道。由于，UDT的主要目的是支持高速廣域網(wǎng)上的海量數(shù)據(jù)傳輸，相比于互聯(lián)網(wǎng)標準數(shù)據(jù)傳輸協(xié)議TCP在高帶寬長距離網(wǎng)絡上具有更好的性能，從而，使得根據(jù)本發(fā)明實施例的文件傳輸控制方法能夠滿足用戶更加嚴苛的要求，再進一步地提高了用戶體驗。當然，如果用戶不需要，也可以只根據(jù)TCP數(shù)據(jù)傳輸協(xié)議建立上述命令通道，同樣可以根據(jù)本發(fā)明實施例實現(xiàn)對文件傳輸?shù)闹鲃涌刂?。因此，對于具體選擇哪種協(xié)議建立命令通道，可以根據(jù)用戶需求或者具體情況進行選取，本發(fā)明實施例對此不做限定。

參閱圖4，本發(fā)明實施例提供了又一種文件傳輸控制方法，其實施步驟具體可以包括：

步驟401：接收客戶端發(fā)送的待傳輸文件的傳輸請求；

步驟402：接收客戶端通過文件傳輸通道發(fā)送的待傳輸文件；

步驟403：在接收客戶端通過文件傳輸通道發(fā)送的待傳輸文件的過程中，接收客戶端通過命令通道發(fā)送的控制命令，并根據(jù)控制命令控制待傳輸文件的傳輸，其中，上述控制命令可以包括：傳輸暫停命令和/或傳輸恢復命令。

在一個實施方式中，服務器端為了通過傳輸暫停命令對待傳輸文件的傳輸按要求進行有效暫停，在上述控制命令為傳輸暫停命令的情況下，可以按照以下方式根據(jù)傳輸暫停命令進行相應的暫停操作：根據(jù)傳輸暫停命令，暫停文件傳輸通道中的待傳輸文件的傳輸；將待傳輸文件中已上傳至服務器端的內容，作為緩存文件，保存在服務器端。

在一個實施方式中，服務器端為了通過傳輸恢復命令對待傳輸文件的傳輸按要求進行有效恢復，在上述控制命令為傳輸恢復命令的情況下，可以按照以下方式根據(jù)傳輸恢復命令進行相應的恢復傳輸操作：根據(jù)傳輸恢復命令，檢測服務器端是否存在待傳輸文件的緩存文件；如果服務器端存在待傳輸文件的緩存文件，則將緩存文件的數(shù)據(jù)信息發(fā)送至客戶端。

在一個實施方式中，服務器端為了通過傳輸恢復命令對待傳輸文件的傳輸按要求進行有效恢復，在上述控制命令為傳輸恢復命令的情況下，對于服務器端不存在待傳輸文件的緩存文件時，還可以按照以下方式進行相應的恢復傳輸操作：如果服務器端不存在待傳輸文件的緩存文件，則向客戶端發(fā)送重傳指令，其中，重傳指令用于指示客戶端再次將待傳輸文件通過文件傳輸通道發(fā)送至服務器端。

在一個實施方式中，為了確保服務器端所接收的待傳輸文件完整，還需要對已經(jīng)上傳到服務器端的待傳輸文件進行完整性校驗，具體在接收客戶端通過文件傳輸通道發(fā)送的待傳輸文件后可以按照以下步驟執(zhí)行：對已接收的待傳輸文件的完整性進行校驗，得到校驗結果；將校驗結果反饋至客戶端。

在一個實施方式中，為了具體應用本發(fā)明實施例的文件傳輸控制方法進行對文件傳輸?shù)目刂?，具體還可以參閱圖5和圖6。其中，如圖5是具體應用本發(fā)明實施例的文件傳輸控制方法，在傳輸文件前，服務器端的數(shù)據(jù)處理流程圖。如圖6是具體應用本發(fā)明實施例的文件傳輸控制方法，在傳輸文件過程中，服務器端的數(shù)據(jù)處理流程圖。在傳輸文件前，參閱圖5所示的數(shù)據(jù)流，服務器端根據(jù)文件傳輸請求，對待傳輸文件的MD5進行性校驗，根據(jù)校驗結果指示客戶端是否要重傳該文件。在傳輸文件時，參閱圖6所示的數(shù)據(jù)流，服務器端根據(jù)控制命令執(zhí)行相應的控制操作，以實現(xiàn)主動暫?；蚧謴臀募鬏斖ǖ乐械奈募鬏敗?/p>

參閱圖7，本發(fā)明實施例提供了再一種文件傳輸控制方法，其實施步驟具體可以包括：

步驟701：在客戶端和服務器端之間建立命令通道；

步驟702：獲取待傳輸文件后，向服務器端發(fā)送待傳輸文件的傳輸請求，并建立待傳輸文件的文件傳輸通道；

步驟703：通過文件傳輸通道，將待傳輸文件發(fā)送至服務器端；

步驟704：在將待傳輸文件發(fā)送至服務器端的過程中，可通過命令通道向服務器端發(fā)送控制命令，以控制待傳輸文件的傳輸，其中，上述控制命令可以包括：傳輸暫停命令和/或傳輸恢復命令。

在一個實施方式中，客戶端為了通過傳輸暫停命令對待傳輸文件的傳輸按要求進行有效暫停，在上述控制命令為傳輸暫停命令的情況下，可以按照以下方式進行相應的暫停操作：按照用戶的要求發(fā)送傳輸暫停命令；根據(jù)傳輸暫停命令，暫停文件傳輸通道中待傳輸文件的傳輸。

在一個實施方式中，客戶端為了通過傳輸恢復命令對待傳輸文件的傳輸按要求進行有效恢復，在上述控制命令為傳輸恢復命令的情況下，可以按照以下方式進行相應的恢復傳輸操作：接收待傳輸文件的緩存文件的數(shù)據(jù)信息；根據(jù)緩存文件的數(shù)據(jù)信息，確定待傳輸文件的傳輸斷點位置；以該斷點位置作為待傳輸文件續(xù)傳的起始位置，通過文件傳輸通道，向服務器端續(xù)傳待傳輸文件。

在一個實施方式中，客戶端為了通過傳輸恢復命令對待傳輸文件的傳輸按要求進行有效恢復，在上述控制命令為傳輸恢復命令的情況下，對于服務器端不存在待傳輸文件的緩存文件時，還可以按照以下方式進行相應的恢復傳輸操作：接收服務器端發(fā)送的重傳指令；根據(jù)重傳指令，將待傳輸文件通過文件傳輸通道再次發(fā)送至服務器端。

在一個實施方式中，客戶端為了建立用于傳輸待傳輸文件的文件傳輸通道，具體可以按照以下方式實施：將待傳輸文件寫入數(shù)據(jù)庫，以等待傳輸；通過傳輸執(zhí)行線程取出待傳輸文件，并根據(jù)待傳輸文件，創(chuàng)建待傳輸文件的獨立傳輸線程；通過獨立傳輸線程，在客戶端和服務器端之間，為待傳輸文件建立待傳輸文件的文件傳輸通道。

在一個實施方式中，當客戶端同時接收到多個文件需要傳輸時，可以將多個文件先寫入數(shù)據(jù)庫，再按照順序，依次逐個取出進行傳輸。具體可以是：根據(jù)多個文件生成文件列表數(shù)據(jù)；將多個文件寫入數(shù)據(jù)庫，并將多個文件中各個文件在數(shù)據(jù)庫中的狀態(tài)記錄標記為未完成；通過傳輸執(zhí)行線程取出待傳輸文件，具體執(zhí)行時可以包括：根據(jù)文件列表數(shù)據(jù)，通過傳輸執(zhí)行線程，依次取出多個文件中的各個文件。

在一個實施方式中，客戶端為了確保發(fā)送至服務器端的待傳輸文件完整，在將待傳輸文件發(fā)送至服務器端后，具體可以按照以下方式處理：接收服務器端發(fā)送的校驗結果，并根據(jù)校驗結果確定傳輸至服務器端的待傳輸文件是否完整；如果完整，則釋放該待傳輸文件的獨立傳輸線程，并將數(shù)據(jù)庫中該待傳輸文件的狀態(tài)記錄改為完成；如果不完整，則將校驗結果通過客戶端的數(shù)據(jù)輸出設備反饋給用戶，并提示用戶該文件需重傳。

在一個實施方式中，為了具體應用本發(fā)明實施例的文件傳輸控制方法進行對文件傳輸?shù)目刂?，具體還可以參閱圖8和圖9。其中，如圖8所示，是具體應用本發(fā)明實施例的文件傳輸控制方法，在傳輸文件前，客戶端的數(shù)據(jù)處理流程圖。如圖9所示，是具體應用本發(fā)明實施例的文件傳輸控制方法，在傳輸文件過程中，客戶端的數(shù)據(jù)處理流程圖。在傳輸文件前，參閱圖8的數(shù)據(jù)流，客戶端根據(jù)MD5信息，決定是否要重傳該文件。在傳輸文件時，參閱圖9的數(shù)據(jù)流，客戶端根據(jù)用戶的指示，通過命令通道向服務器端發(fā)送對應的控制命令以實現(xiàn)主動暫?；蚧謴臀募鬏斖ǖ乐械奈募鬏敗?/p>

基于同一發(fā)明構思，本發(fā)明實施例中還提供了一種文件傳輸控制系統(tǒng)，如下面的實施例所述。由于文件傳輸控制系統(tǒng)解決問題的原理與文件傳輸控制方法相似，因此文件傳輸控制系統(tǒng)的實施可以參見文件傳輸控制方法的實施，重復之處不再贅述。以下所使用的，術語“單元”或者“模塊”可以實現(xiàn)預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的系統(tǒng)較佳地以軟件來實現(xiàn)，但是硬件，或者軟件和硬件的組合的實現(xiàn)也是可能并被構想的。請參閱圖10，是本發(fā)明實施例的文件傳輸控制系統(tǒng)的一種結構框圖，如圖10所示，可以包括：客戶端1001和服務器端1002，客戶端1001和服務器端1002之間又設置有文件傳輸通道和命令通道。下面對該結構各個部分進行具體說明。

客戶端1001，用于通過文件傳輸通道傳輸待傳輸文件，并可通過命令通道傳輸控制命令，其中，上述控制命令可以包括：傳輸暫停命令和/或傳輸恢復命令；

服務器1002，用于接收客戶端通過文件傳輸通道傳輸?shù)拇齻鬏斘募屯ㄟ^命令通道傳輸?shù)目刂泼睿M而根據(jù)控制命令，控制文件傳輸通道中待傳輸文件的傳輸。

在另外一個實施例中，還提供了一種軟件，該軟件用于執(zhí)行上述實施例及優(yōu)選實施方式中描述的技術方案。

從以上的描述中，可以看出，本發(fā)明實施例實現(xiàn)了如下技術效果：通過設計命令通道，客戶端可以利用該命令通道向服務器端發(fā)送傳輸暫停或者傳輸恢復命令，解決了現(xiàn)有方法中存在的文件傳輸時不能暫停和/或恢復待傳輸文件傳輸?shù)募夹g問題，實現(xiàn)了用戶可以通過命令通道對文件傳輸過程進行主動控制的目的，從而，提高了用戶的體驗度；此外，本發(fā)明實施例在暫停待傳輸文件傳輸?shù)耐瑫r將待傳輸文件中已上傳至服務器端的內容作為緩存文件保存在服務器端，當接收傳輸恢復命令后，恢復該待傳輸文件的傳輸時，可以根據(jù)所保存的緩存文件，只續(xù)傳該待傳輸文件還未上傳的內容，從而可以減少對同一個待傳輸文件的相同內容的重復傳輸，減少了傳輸時間；另外，本發(fā)明實施例還可以采用基于UDT傳輸協(xié)議的命令通道，由于UDT命令通道可以支持高速廣域網(wǎng)上的海量數(shù)據(jù)傳輸，因此，可以滿足用戶更高的文件傳輸請求，從而，進一步改善了用戶的使用體驗。

顯然，本領域的技術人員應該明白，上述的本發(fā)明實施例的各模塊或各步驟可以用通用的計算系統(tǒng)來實現(xiàn)，它們可以集中在單個的計算系統(tǒng)上，或者分布在多個計算系統(tǒng)所組成的網(wǎng)絡上，可選地，它們可以用計算系統(tǒng)可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲系統(tǒng)中由計算系統(tǒng)來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明實施例不限制于任何特定的硬件和軟件結合。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明實施例可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。