專利名稱：：文件上傳方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及電子地圖
技術(shù)領(lǐng)域：
，尤指一種文件上傳方法。
背景技術(shù)：
：互聯(lián)網(wǎng)的應(yīng)用幾乎滲透到人們工作和生活的各個角落,人們通過網(wǎng)絡(luò)下載文件，或者通過網(wǎng)絡(luò)上傳文件，這些都是稀+>平常的事情。下載文件是指將遠端(或者稱為發(fā)送方)的文件下載到本地(或者稱為接收方)，如圖l所示，接收方發(fā)送控制流，或者稱下載請求給發(fā)送方，發(fā)送方發(fā)送數(shù)據(jù)^i會接收方。在Internet網(wǎng)絡(luò)中傳輸照片(或大的文件)，通常^it到網(wǎng)絡(luò)不穩(wěn)定，傳輸過程不正常中斷，導(dǎo)致文件傳輸失敗。下載文件通常采用斷點續(xù)傳的方式，來保證下栽文件過程的成功，例如下載軟件Flashget等等就是采用斷點續(xù)傳的方式，也就是說在下載被不正常中斷后，會自動重新連4妄^務(wù)器，從斷點開始重新下載。該方式需要FTP協(xié)議或HTTP協(xié)議支持。這種方式又被稱為拉的技術(shù)，適用于下載文件。上傳文件是指將本地的文件上傳給服務(wù)器(或者稱遠端)。在遇到網(wǎng)絡(luò)上傳中斷時，這種拉的技術(shù)不適合上傳，只能采用重新傳輸?shù)姆绞剑蟠罄速M了網(wǎng)絡(luò)資源。這是由于如果上傳的客戶端是無線上網(wǎng)的PDA(英文全稱PersonalDigitalAssistant,即個人數(shù)字助理，一般指掌上電腦)，接收方(服務(wù)器)是任務(wù)的^者，需要在一個任務(wù)^前知道傳輸?shù)膬?nèi)容是什么，在發(fā)送方(PDA)不在線，或在線情況不頭￡#的情況下(這意味著IP地址可能變化)，接收方不知道怎么和發(fā)起方通信。
發(fā)明內(nèi)容本發(fā)明要解決的問M提供一種節(jié)約資源的文件上傳方法。為了解決上述問題，本發(fā)明文件上傳方法的技術(shù)方案包括客戶端向服務(wù)器發(fā)送上傳請求,所述上傳請求包括上傳文件的文件名和總長度；服務(wù)器向客戶端返回其已接收的所述上傳文件的字節(jié)數(shù)；客戶端從所述總長度減去已傳輸?shù)淖止?jié)數(shù)處開始傳輸所述上傳文件。進一步地，本發(fā)明文件上傳方法還包括步驟月良務(wù)H4^U'J的字節(jié)數(shù)等于所述總長度后，向客戶端返回標(biāo)志完成；客戶端接4tJ'J標(biāo)志完成后，斷開連4妄。與現(xiàn)有技^M目比，本發(fā)明文件上傳方法的有益效果為由于客戶端每次向服務(wù)器發(fā)^i^接請求的時4美銅奪^"上傳的文件的文件名和總長;l^it^服務(wù)器，月良務(wù)11#已接收的文件的字節(jié)數(shù)返回給客戶端，客戶端才i悉長度減去已接收的字節(jié)數(shù)處開始向服務(wù)器上傳文件。這樣，對于已經(jīng)上傳了的數(shù)悟，客戶端就不必再重新上傳，而只接著傳輸尚未傳輸?shù)臄?shù)據(jù)即可，從而大大節(jié)約了網(wǎng)絡(luò)資源。本方法除了在'隨中斷傳輸時節(jié)省資源外，還提供某種便利性，如客戶端不需一直在線，只需要絲傳輸需求的時候連接到網(wǎng)絡(luò)中，這比較適^^^i殳備的互聯(lián)網(wǎng)連接情況。圖l是文件下載的示意圖2是本發(fā)明文件上傳方法的^艮圖3M用本發(fā)明文件上傳方法的統(tǒng)一建模語言序列圖4A^用本發(fā)明文件上傳方法的一個文件傳輸?shù)臓顟B(tài)值示意圖。具體實施例方式如圖2所示，本發(fā)明文件上傳方法包括下述步驟1)客戶端向服務(wù)器發(fā)itJi^t求，所itJi^^"求中包括上傳文件的文件名和總長度；2)月良務(wù)器向客戶端返回其已接收的所i^Ji傳文件的字節(jié)數(shù)；3)客戶端從所述總長度減去已接收的字節(jié)數(shù)處開始傳輸所iiJi傳文件。由上述可知，客戶端作為發(fā)送方，月良務(wù)H^乍為接J]t^，客戶端向服務(wù)器上傳文件。首先，客戶端向服務(wù)器發(fā)i^Ji^^青求，所iiJ^H青求中包括上傳文件的文件名和總長度，也IU3兌，客戶端^^上傳的文件的文件名和總長度傳給服務(wù)器。月良務(wù)器將其已接收的字節(jié)數(shù)傳給客戶端，如果是一個新文件，服務(wù)器向客戶端返回的字節(jié)數(shù)就是0，也;^U:沒有接收^^可數(shù)據(jù)；如果是由于異常情況而中斷傳輸?shù)奈募?服務(wù)器向客戶端返回的就^^一個非0值?？蛻舳私?^ij服務(wù)器返回的已接收字節(jié)數(shù)后，客戶端l^人悉長度減去已接收字節(jié)狄開始向服務(wù)器上傳文件。這樣，對于中斷傳輸?shù)奈募呀?jīng)上傳的數(shù)悟不必再重新傳輸，只要接著傳輸未傳輸?shù)臄?shù)梧即可。從而大大節(jié)約了網(wǎng)絡(luò)資源。進一步地，如圖2所示，本發(fā)明文件上傳方法還包括步驟4)月良務(wù)器接jji^的字節(jié)數(shù)等于所述總長^,向客戶端返回標(biāo)志完成；5)客戶端接收到標(biāo)志完成后，斷開連接。如圖3所示，是UML(UnifiedModelingLanguage,統(tǒng)一建模語言)序列圖，UML是一種軟件開發(fā)中圖形化的設(shè)計語言。本發(fā)明文件上傳方法的技術(shù)方案用其來實現(xiàn)。在圖3中，上傳J^方向接JRI良務(wù)器上傳照片，其過程如下上傳發(fā)起方第一次發(fā)起請求上傳照片指令PDA—UPLOAD—REQUEST(0x2071);接收服務(wù)器第一次返回請求上傳照片回復(fù)指令JD—UPLOAD—REQ_ACK(0x2072);上傳狄方第一次傳照片數(shù)據(jù)指令PDA—UPLOAD_DATA(0x2074);上傳狄方第n次傳照片數(shù)據(jù)指令PDA_UPLOAD_DATA(0x2074)接j)iJ良務(wù)器發(fā)itJi傳結(jié)束指令JD—UPLOAD—END—ACK(0x2073)。其中，請求上傳照片的指令PDA—UPLOAD—REQUEST(0x2071)的包格式如下:<table>tableseeoriginaldocumentpage5</column></row><table>表l在表1中的文件名和文件長度字段中存放的;tU:要上傳的照片的名稱及總長度。請求上傳照片回復(fù)指令JD—UPLOAD—REQ_ACK(0x2072)的包格式<table>tableseeoriginaldocumentpage6</column></row><table>表2在表2中，接4tl良務(wù)器回復(fù)的指令中包括文件名和StartPos字段。StartPos字段為服務(wù)器已接收的文件長度(偏移量)，若是新文件該字段返回的值為0。傳照片數(shù)據(jù)指令PDAJJPLOAD—DATA(0x2074)的包格式<table>tableseeoriginaldocumentpage6</column></row><table>表3在表3中，上傳發(fā)送方向服務(wù)鼎輸照片數(shù)據(jù)。上傳結(jié)^^旨令JD—UPLOAD_END_ACK(0x2073)的包格式:<table>tableseeoriginaldocumentpage6</column></row><table>表4#4中的命令字段0x2073表示上傳結(jié)束，月良務(wù)器已接收了該照片的dNp數(shù)據(jù)。^^L講，在服務(wù)器端，始終維護著一個狀態(tài)表，如圖4所示，其表示一個文件傳輸?shù)臓顟B(tài)值。狀態(tài)值以分號間隔1)文件在發(fā)送端的命名2)文件在服務(wù)端的相對^f諸^4圣3)已接收長度4)是否完成(此字段通常不用)月良務(wù)器通過1)、2)和3)三項數(shù)據(jù)就可知道一個文件在服務(wù)器端的接收情況。例如，PDA準(zhǔn)備上傳一個叫l(wèi).jpg的剛剛拍攝的照片文件。這個文件有4M大。首先，PDA傳輸一個4M大的l.jpg給服務(wù)器。月l務(wù)器負責(zé)接收。開始PDA將文件總長度和文件名傳輸給服務(wù)器，然后PDA4錄內(nèi)容。過禾錄傳輸?shù)?M時異常中斷。PDA檢測到異常，然后重新和服務(wù)器建立socketi^接。將"l.jpg"發(fā)給服務(wù)器，查詢已上傳字節(jié)數(shù)。月良務(wù)器返回"l.jpg"文件的已接收字節(jié)數(shù)為2M。PDA得到已上傳字節(jié)紀(jì)M時，將從斷點開始將余下的2M(4M-2M-2M)內(nèi)容發(fā)送給服務(wù)器。如a傳輸過程中還有中斷，則重復(fù)^f亍上述步驟。月良務(wù)器接4tfiJ所有文件內(nèi)容后，返回一個完成標(biāo)志給PDA。PDA接4U'j完成標(biāo)志后，斷開連接，或進行下一個文件的傳輸。綜上所述，由于客戶端每次向服務(wù)器發(fā)iH^接請求的時候銅夸要上傳的文件的文件名和總長狄it^服務(wù)器，月良務(wù)器將已接收的文件的字節(jié)數(shù)返回給客戶端，客戶端就從悉長度減去已接收的字節(jié)1:開始向服務(wù)器上傳文件。這樣，對于已經(jīng)上傳了的數(shù)據(jù)，客戶端就不必再重新上傳，而只接著傳輸尚未傳輸?shù)臄?shù)據(jù)即可，從而大大節(jié)約了網(wǎng)絡(luò)資源。本方法除了在'隨中斷傳輸時節(jié)省資源外，還提供某種便利性，如客戶端不需一直在線，只需要在有傳^^求的時候連接到網(wǎng)絡(luò)中，這比較適襯^i殳備的互聯(lián)網(wǎng)連接情況。權(quán)利要求1、一種文件上傳方法，其特征在于，包括步驟客戶端向服務(wù)器發(fā)送上傳請求，所述上傳請求包括上傳文件的文件名和總長度；服務(wù)器向客戶端返回其已接收的所述上傳文件的字節(jié)數(shù)；客戶端從所述總長度減去已傳輸?shù)淖止?jié)數(shù)處開始傳輸所述上傳文件。2、如權(quán)利要求1所述的文件上傳方法，其特征在于，還包括步驟服務(wù)器接收到的字節(jié)數(shù)等于所述總長度后，向客戶端返回標(biāo)志完成；客戶端接收到標(biāo)志完成后，斷開連接。全文摘要本發(fā)明公開一種文件上傳方法包括客戶端向服務(wù)器發(fā)送上傳請求，所述上傳請求包括上傳文件的文件名和總長度；服務(wù)器向客戶端返回其已接收的所述上傳文件的字節(jié)數(shù)；客戶端從所述總長度減去已傳輸?shù)淖止?jié)數(shù)處開始傳輸所述上傳文件。因此，采用本發(fā)明文件上傳方法的技術(shù)方案能夠節(jié)約資源。文檔編號H04L29/08GK101483661SQ20081000046公開日2009年7月15日申請日期2008年1月11日優(yōu)先權(quán)日2008年1月11日發(fā)明者鄒逵生申請人:高德軟件有限公司