專利名稱：一種本地下載的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域中的數(shù)據(jù)交換技術(shù)，特別是涉及一種本地下載的方法及系統(tǒng)、客戶端及服務(wù)器。
背景技術(shù)：
串口協(xié)議XMODEM是一種個人計算機通信中廣泛使用的異步文件傳輸協(xié)議。參見圖1所示，目前，利用串口協(xié)議XMODEM傳輸文件時，用戶首先要在服務(wù)器側(cè)啟動文件發(fā)送，之后在客戶端啟動文件接收。用戶手動完成這兩步操作后，文件才會從服務(wù)器下載到客戶端。
這種協(xié)議雖然提供了可靠的數(shù)據(jù)傳輸能力，但是沒有提供客戶端與服務(wù)器之間的自動交互流程，尤其是在多文件下載時，需要用戶反復(fù)手動操作，給用戶的使用帶來不便。
進(jìn)一步，由于目前沒有自動交互流程，用戶無法直接獲知待下載文件的屬性。這樣會導(dǎo)致客戶端可能在接收了一部分?jǐn)?shù)據(jù)后，因為存儲空間不足而接收失敗，浪費了時間和系統(tǒng)資源，而且給用戶帶來了不好的體驗。
進(jìn)一步，由于目前沒有自動交互流程，而且服務(wù)器側(cè)沒有設(shè)置文件路徑，給文件查找?guī)砹瞬槐恪?br>
發(fā)明內(nèi)容
本發(fā)明提供一種本地下載的方法、系統(tǒng)、客戶端及服務(wù)器，用以解決目前本地協(xié)議中沒有提供自動交互流程的問題。
本發(fā)明方法應(yīng)用基于本地下載協(xié)議的數(shù)據(jù)交換系統(tǒng)，包括下列步驟A、客戶端向服務(wù)器發(fā)出下載文件請求；
B、服務(wù)器根據(jù)所述的下載文件請求，去查尋并獲得滿足該下載文件請求的文件；C、服務(wù)器發(fā)送所述的滿足該下載文件請求的文件，客戶端接收該文件。
所述下載文件至少為一個。
所述步驟A中包括步驟A1、客戶端向服務(wù)器發(fā)送下載通知消息；A2、服務(wù)器當(dāng)前允許下載，則向所述客戶端發(fā)送下載通知響應(yīng)消息；A3、客戶端向服務(wù)器發(fā)送攜帶待下載文件的文件名的下載請求消息。
客戶端發(fā)出的所述下載請求消息中還攜帶有待下載文件的文件格式，服務(wù)器根據(jù)下載請求消息中的文件名及文件格，在指定路徑下查找。
所述服務(wù)器確定存在相應(yīng)的文件后，進(jìn)一步查詢所述待下載文件的屬性信息并下發(fā)到客戶端。
所述步驟C中還包括步驟客戶端根據(jù)收到的待下載文件的屬性信息決定是否下載所述文件；當(dāng)決定下載時，客戶端向服務(wù)器發(fā)送確認(rèn)下載消息；服務(wù)器收到所述確認(rèn)下載消息后，向所述客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
所述屬性信息至少包括待下載文件的大小信息。
所述步驟C之后還包括步驟客戶端接收了完整的文件后，進(jìn)行數(shù)據(jù)校驗。
所述本地下載協(xié)議包括串口協(xié)議XMODEM、紅外傳輸協(xié)議或藍(lán)牙傳輸協(xié)議。
本發(fā)明的系統(tǒng)，應(yīng)用基于本地下載協(xié)議的數(shù)據(jù)交換系統(tǒng)，包括客戶端和通過數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述客戶端連接的服務(wù)器；所述客戶端，包括消息發(fā)送單元，與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連；第一分析單元，與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連；所述服務(wù)器，包括第二分析單元，通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述消息發(fā)送單元相連；執(zhí)行單元，與所述第二分析單元相連，以及通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述第一分析單元相連。
所述客戶端還包括傳輸控制單元，當(dāng)存在多個待下載文件時，控制多個文件的下載。
所述消息發(fā)送單元，用于根據(jù)用戶的指令，通過數(shù)據(jù)傳輸網(wǎng)絡(luò)向服務(wù)器發(fā)送下載請求消息及查詢請求消息；所述第一分析單元，用于分析服務(wù)器反饋的消息，以提示用戶是否執(zhí)行下載操作；所述第二分析單元，用于分析客戶端發(fā)來的下載請求消息和查詢請求消息，并發(fā)送分析結(jié)果；所述執(zhí)行單元，用于根據(jù)所述第二分析單元的分析結(jié)果，發(fā)送反饋消息及文件數(shù)據(jù)。
本發(fā)明的本地下載客戶端，應(yīng)用于本地下載協(xié)議，包括消息發(fā)送單元，其接收用戶的指令，并向服務(wù)器發(fā)送下載請求消息及查詢請求消息；第一分析單元，接收網(wǎng)絡(luò)側(cè)發(fā)來的反饋消息，并提示用戶是否執(zhí)行下載操作。所述客戶端還包括傳輸控制單元，當(dāng)存在多個待下載文件時，控制多個文件的下載。
本發(fā)明的本地下載服務(wù)器，應(yīng)用于本地下載協(xié)議，包括第二分析單元，其接收網(wǎng)絡(luò)側(cè)發(fā)來的下載請求消息和查詢請求消息，發(fā)送分析結(jié)果；執(zhí)行單元，與所述執(zhí)行第二單元相連，解析第二分析單元發(fā)出的分析結(jié)果，并發(fā)送反饋消息及文件數(shù)據(jù)。
本發(fā)明有益效果如下本發(fā)明方法提供了一種在本地下載時，客戶端與服務(wù)器交互的流程?？蛻舳耸盏接脩舻闹甘竞螅园l(fā)送消息的形式向服務(wù)器請求下載文件；服務(wù)器確認(rèn)待下載文件存在后，自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
本發(fā)明方法無須用于在客戶端和服務(wù)器這兩端都進(jìn)行手動操作，而是通過客戶端與服務(wù)器的消息交互，自動完成所述待下載文件的查找及下載觸發(fā)。尤其是在多文件下載時，本發(fā)明的優(yōu)勢更加顯著，給用戶帶來了更好的體驗。
進(jìn)一步，在服務(wù)器側(cè)為存儲的文件設(shè)置了文件路徑，即不是所有文件都處于同一根目錄下。這樣服務(wù)器在查找待下載文件時就有的放矢，節(jié)約了查找文件帶來的系統(tǒng)消耗，同時減小了查找所需的時間。
進(jìn)一步，服務(wù)器在查找到待下載文件時，還查詢該文件的屬性信息(例如該文件的大小信息)，并在下發(fā)待下載文件之前，先將所述屬性信息下發(fā)到客戶端，這樣用戶就可在下載開始之前預(yù)先獲知待下載文件的屬性，據(jù)此用戶可以決定是否繼續(xù)下載(例如根據(jù)大小信息判斷存儲空間是否足夠)。通過這種優(yōu)選方案的實施，從用戶的角度避免了盲目下載給用戶帶來了不好體驗；從服務(wù)器的角度節(jié)約了系統(tǒng)資源，以便為更多的用戶提供服務(wù)。
為了支撐本發(fā)明方法，本發(fā)明還提供了一種本地下載的系統(tǒng)、客戶端及服務(wù)器。


圖1為現(xiàn)有利用串口協(xié)議傳輸文件的示意圖；圖2為本發(fā)明系統(tǒng)結(jié)構(gòu)示意圖；圖3為本發(fā)明方法步驟流程圖；圖4為本發(fā)明方法消息交互示意圖；圖5為本發(fā)明方法實例三的信令流程圖。
具體實施例方式
為了在本地下載過程中，使客戶端和服務(wù)器以消息的形式進(jìn)行交互，從而將用戶的“手動”操作變?yōu)椤白詣印?，本發(fā)明提供了一種本地下載的系統(tǒng)，應(yīng)用于本地下載協(xié)議，所述本地下載協(xié)議包括但不限于串口協(xié)議XMODEM、紅外傳輸協(xié)議或藍(lán)牙傳輸協(xié)議。
參見圖2所示，所述系統(tǒng)包括客戶端和通過數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述客戶端連接的服務(wù)器。所述客戶端(即本發(fā)明的客戶端)中包括與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連的消息發(fā)送單元；與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連的第一分析單元；進(jìn)一步還可包括傳輸控制單元。所述服務(wù)器(即本發(fā)明的服務(wù)器)中包括通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述消息發(fā)送單元相連的第二分析單元；與所述第二分析單元相連，以及通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述第一分析單元相連的執(zhí)行單元。
所述第一分析單元，用于分析服務(wù)器反饋的消息，以提示用戶是否執(zhí)行下載操作。
所述消息發(fā)送單元，用于根據(jù)用戶的指示，通過數(shù)據(jù)傳輸網(wǎng)絡(luò)向服務(wù)器發(fā)送相應(yīng)的消息。
所述傳輸控制單元，用于控制多個文件的下載。
所述第二分析單元，用于分析客戶端發(fā)來的消息。
所述執(zhí)行單元，用于根據(jù)所述第二分析單元的分析結(jié)果，自動執(zhí)行相應(yīng)的操作。
應(yīng)用上述系統(tǒng)及裝置，本發(fā)明提供了一種本地下載的方法，同樣應(yīng)用于但不限于串口協(xié)議XMODEM、紅外傳輸協(xié)議或藍(lán)牙傳輸協(xié)議。參見圖3所示，包括下列步驟S1、客戶端向服務(wù)器請求下載文件。
S2、服務(wù)器查找待下載文件是否存在，若存在，則轉(zhuǎn)入步驟S3，否則，返回失敗消息。
S3、服務(wù)器自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
S4、客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)。
以下通過4個實例具體描述本發(fā)明方法。
方法實例一服務(wù)器從根目錄查找到待下載文件后，直接下發(fā)文件數(shù)據(jù)。
S101、客戶端向服務(wù)器請求下載文件。
客戶端收到用戶的下載指示后，通過內(nèi)置的消息發(fā)送單元生成下載通知消息，并向服務(wù)器發(fā)送。
服務(wù)器收到所述下載通知消息后，通過內(nèi)置的第二分析單元分析出所述客戶端當(dāng)前欲啟動下載流程。之后，判斷自身剩余的系統(tǒng)資源是否可以滿足下載操作，若可以滿足，則通過執(zhí)行單元向所述客戶端返回下載通知響應(yīng)消息；否則，通過執(zhí)行單元向所述客戶端返回失敗消息。
若客戶端收到下載通知響應(yīng)消息，則通過內(nèi)置的第一分析單元分析出當(dāng)前允許發(fā)起下載流程。之后，通過消息發(fā)送單元生成攜帶有待下載文件的文件名的下載請求消息，并向服務(wù)器發(fā)送，以啟動下載流程，即轉(zhuǎn)入步驟S102。所述待下載文件可以是一個，也可以是多個，本處以多個待下載文件為例。
若客戶端收到失敗消息，則通過內(nèi)置的第一分析單元分析出當(dāng)前不允許發(fā)起下載流程，用戶可通過客戶端再次與服務(wù)器交互。
S102、服務(wù)器查找待下載文件是否存在，若存在，則轉(zhuǎn)入步驟S103，否則，返回失敗消息。
在本例中，服務(wù)器沒有為存儲的文件設(shè)置文件路徑，即所有文件都存儲于根目錄下。
服務(wù)器通過第二分析單元從客戶端發(fā)來的下載請求消息中獲取待下載文件的文件名，并通過執(zhí)行單元，以所述文件名為依據(jù)在根目錄下查找所述待下載文件是否存在。若查找到了相應(yīng)的文件，則轉(zhuǎn)入步驟S103；否則，向客戶端發(fā)返回失敗消息，客戶端通過內(nèi)置的第一分析單元分析出待下載文件不存在，用戶可選擇其它的文件下載。
S103、服務(wù)器自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
所述執(zhí)行單元查找到相應(yīng)的文件后，無須用戶再進(jìn)行操作，而是直接向客戶端同時下發(fā)各個待下載文件的文件數(shù)據(jù)。
S104、客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)。
客戶端通過內(nèi)置的傳輸控制單元控制多個文件數(shù)據(jù)的同時接收。當(dāng)全部文件下載完畢后，結(jié)束下載流程。
方法實例二服務(wù)器在指定的文件路徑下查找待下載文件，并在用戶根據(jù)文件屬性確認(rèn)下載后，下發(fā)文件數(shù)據(jù)。
S201、客戶端向服務(wù)器請求下載文件。(與S101相同)S202、服務(wù)器查找待下載文件是否存在，若存在，則轉(zhuǎn)入步驟S203，否則，返回失敗消息。
在本例中，服務(wù)器為存儲的文件設(shè)置文件路徑，例如MP3格式的文件被存儲于“音頻”路徑下，AVI格式的文件被存儲于“視頻”路徑下。
服務(wù)器通過第二分析單元從客戶端發(fā)來的下載請求消息中獲取待下載文件的文件名，所述文件名包括了文件名稱及文件格式信息(例如文件格式為MP3)。之后，通過執(zhí)行單元，以所述文件名為依據(jù)在指定的文件路徑下(“音頻”路徑下)查找所述待下載文件是否存在。若查找到了相應(yīng)的文件，則同時獲取查找到的文件的屬性信息，例如文件的大小信息，文件版本信息等，之后轉(zhuǎn)入步驟S203；否則，向客戶端發(fā)返回失敗消息，客戶端通過內(nèi)置的第一分析單元分析出待下載文件不存在，用戶可選擇其它的文件下載。
S203、服務(wù)器自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
在本例中，服務(wù)器在向客戶端下發(fā)文件數(shù)據(jù)之前，先通過執(zhí)行單元將所述查找到的文件的屬性信息下發(fā)到客戶端?？蛻舳送ㄟ^第一分析單元分析出待下載文件的大小等信息后，顯示給用戶，同時還可顯示出所述客戶端所在終端的剩余存儲空間，用戶據(jù)此判斷是否有必要繼續(xù)下載流程。
若用戶決定繼續(xù)下載，則通過消息發(fā)送單元生成確認(rèn)下載消息，并向服務(wù)器發(fā)送；否則，終止下載流程。
服務(wù)器收到所述確認(rèn)下載消息后，通過第二分析單元分析出用戶確認(rèn)下載，之后無須用戶再進(jìn)行操作，而是通過執(zhí)行單元自動向客戶端逐一下發(fā)各個待下載文件的文件數(shù)據(jù)。
S204、客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)。
客戶端通過內(nèi)置的傳輸控制單元控制多個文件數(shù)據(jù)的逐一接收。當(dāng)全部文件下載完畢后，結(jié)束下載流程。
方法實例三服務(wù)器在指定的文件路徑下查找待下載文件，并在用戶根據(jù)文件屬性確認(rèn)下載后，下發(fā)文件數(shù)據(jù)。但是用戶在下載過程中中止了下載。參見圖4和圖5所示，并結(jié)合圖3，包括以下具體內(nèi)容S301、客戶端向服務(wù)器請求下載文件。(與S101相同)S302、服務(wù)器查找待下載文件是否存在，若存在，則轉(zhuǎn)入步驟S303，否則，返回失敗消息。(與S202相同)
S303、服務(wù)器自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。(與S203相同)S304、客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)。
客戶端通過內(nèi)置的傳輸控制單元控制多個文件數(shù)據(jù)的逐一接收。在本例中，用戶在下載過程中中止了下載。例如在下載第一個文件的過程中，用戶發(fā)現(xiàn)該文件以前下載過，則指示消息發(fā)送單元生成取消下載消息，并向服務(wù)器發(fā)送。
服務(wù)器收到所述取消下載消息后，通過第二分析單元分析出用戶要求中止下載，則通過執(zhí)行單元中止當(dāng)前文件的下發(fā)，或者中止所有文件的下發(fā)，并向客戶端發(fā)送取消下載響應(yīng)消息。
方法實例四在客戶端向服務(wù)器請求下載文件之前，先對用戶進(jìn)行鑒權(quán)；以及，在客戶端接收了完整的文件后，進(jìn)行數(shù)據(jù)校驗。
S401、客戶端向服務(wù)器請求下載文件。
用戶在通過客戶端向服務(wù)器請求下載文件之前，先要以用戶名和密碼登錄到服務(wù)器，即對該用的身份進(jìn)行鑒權(quán)。在登錄到服務(wù)器后，用戶才可通過客戶端指示下載。本步驟的后續(xù)內(nèi)容與S101相同。
S402、服務(wù)器查找待下載文件是否存在，若存在，則轉(zhuǎn)入步驟S403，否則，返回失敗消息。(與S202相同)S403、服務(wù)器自動向客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。(與S203相同)S404、客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)。
本步驟中客戶端接收并存儲服務(wù)器發(fā)來的數(shù)據(jù)與S204相同。
當(dāng)所述客戶端接收到了一個完整的文件后(即收到了該文件的包頭和包尾數(shù)據(jù))，客戶端對該文件進(jìn)行數(shù)據(jù)校驗，以判斷接收到的文件的完整性。若發(fā)現(xiàn)接收的文件丟失了若干數(shù)據(jù)包，則可向服務(wù)器要求補發(fā)所述數(shù)據(jù)包。
顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
1.一種本地下載的方法，應(yīng)用基于本地下載協(xié)議的數(shù)據(jù)交換系統(tǒng)，其特征在于，包括下列步驟A、客戶端向服務(wù)器發(fā)出下載文件請求；B、服務(wù)器根據(jù)所述的下載文件請求，去查尋并獲得滿足該下載文件請求的文件；C、服務(wù)器發(fā)送所述的滿足該下載文件請求的文件，客戶端接收該文件。
2.如權(quán)利要求1所述的方法，其特征在于，所述下載文件至少為一個。
3.如權(quán)利要求2所述的方法，其特征在于，所述步驟A中包括步驟A1、客戶端向服務(wù)器發(fā)送下載通知消息；A2、服務(wù)器當(dāng)前允許下載，則向所述客戶端發(fā)送下載通知響應(yīng)消息；A3、客戶端向服務(wù)器發(fā)送攜帶待下載文件的文件名的下載請求消息。
4.如權(quán)利要求3所述的方法，其特征在于，客戶端發(fā)出的所述下載請求消息中還攜帶有待下載文件的文件格式，服務(wù)器根據(jù)下載請求消息中的文件名及文件格式，在指定路徑下查找。
5.如權(quán)利要求4所述的方法，其特征在于，步驟B中，當(dāng)所述服務(wù)器查詢到滿足該下載文件請求的文件后，進(jìn)一步查詢所述待下載文件的屬性信息并下發(fā)到客戶端。
6.如權(quán)利要求5所述的方法，其特征在于，所述步驟C中還包括步驟-客戶端根據(jù)收到的待下載文件的屬性信息決定是否下載所述文件；-當(dāng)決定下載時，客戶端向服務(wù)器發(fā)送確認(rèn)下載消息；-服務(wù)器收到所述確認(rèn)下載消息后，向所述客戶端對應(yīng)下發(fā)文件數(shù)據(jù)。
7.如權(quán)利要求5或6所述的方法，其特征在于，所述屬性信息至少包括待下載文件的大小信息。
8.如權(quán)利要求7所述的方法，其特征在于，所述步驟C之后還包括步驟客戶端接收了完整的文件后，進(jìn)行數(shù)據(jù)校驗。
9.如權(quán)利要求1所述的方法，其特征在于，所述本地下載協(xié)議包括串口協(xié)議XMODEM、紅外傳輸協(xié)議或藍(lán)牙傳輸協(xié)議。
10.一種本地下載的系統(tǒng)，應(yīng)用基于本地下載協(xié)議的數(shù)據(jù)交換系統(tǒng)，包括客戶端和通過數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述客戶端連接的服務(wù)器，其特征在于所述客戶端，包括消息發(fā)送單元，與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連；第一分析單元，與所述數(shù)據(jù)傳輸網(wǎng)絡(luò)相連；所述服務(wù)器，包括第二分析單元，通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述消息發(fā)送單元相連；執(zhí)行單元，與所述第二分析單元相連，以及通過所述數(shù)據(jù)傳輸網(wǎng)絡(luò)與所述第一分析單元相連。
11.如權(quán)利要求10所述的系統(tǒng)，其特征在于，所述客戶端還包括傳輸控制單元，當(dāng)存在多個待下載文件時，控制多個文件的下載。
12.如權(quán)利要求10或11所述的系統(tǒng)，其特征在于，所述消息發(fā)送單元，用于根據(jù)用戶的指令，通過數(shù)據(jù)傳輸網(wǎng)絡(luò)向服務(wù)器發(fā)送下載請求消息及查詢請求消息；所述第一分析單元，用于分析服務(wù)器反饋的消息，以提示用戶是否執(zhí)行下載操作；所述第二分析單元，用于分析客戶端發(fā)來的下載請求消息和查詢請求消息，并發(fā)送分析結(jié)果；所述執(zhí)行單元，用于根據(jù)所述第二分析單元的分析結(jié)果，發(fā)送反饋消息及文件數(shù)據(jù)。
13.如權(quán)利要求12所述的系統(tǒng)，其特征在于，所述本地下載協(xié)議包括串口協(xié)議XMODEM、紅外傳輸協(xié)議或藍(lán)牙傳輸協(xié)議。
14.一種本地下載客戶端，應(yīng)用于本地下載協(xié)議，其特征在于，包括消息發(fā)送單元，其接收用戶的指令，并向服務(wù)器發(fā)送下載請求消息及查詢請求消息；第一分析單元，接收網(wǎng)絡(luò)側(cè)發(fā)來的反饋消息，并提示用戶是否執(zhí)行下載操作。
15.如權(quán)利要求14所述的客戶端，其特征在于，所述客戶端還包括傳輸控制單元，當(dāng)存在多個待下載文件時，控制多個文件的下載。
16.一種本地下載服務(wù)器，應(yīng)用于本地下載協(xié)議，其特征在于，包括第二分析單元，其接收網(wǎng)絡(luò)側(cè)發(fā)來的下載請求消息和查詢請求消息，并發(fā)送分析結(jié)果；執(zhí)行單元，與所述執(zhí)行第二單元相連，解析第二分析單元發(fā)出的分析結(jié)果，并發(fā)送反饋消息及文件數(shù)據(jù)。
全文摘要
本發(fā)明公開了一種本地下載的方法、系統(tǒng)、客戶端及服務(wù)器，用以解決目前本地協(xié)議中沒有提供自動交互流程的問題。本發(fā)明方法包括步驟A.客戶端向服務(wù)器發(fā)出下載文件請求；B.服務(wù)器根據(jù)所述的下載文件請求，去查尋并獲得滿足該下載文件請求的文件；C.服務(wù)器發(fā)送所述的滿足該下載文件請求的文件，客戶端接收該文件。
文檔編號H04L29/06GK1996844SQ20051013721
公開日2007年7月11日 申請日期2005年12月31日 優(yōu)先權(quán)日2005年12月31日
發(fā)明者賀建國, 張坤, 趙瑞 申請人:華為技術(shù)有限公司