專利名稱：一種確認封包傳輸?shù)姆椒?br> 技術(shù)領(lǐng)域：
本發(fā)明有關(guān)于無線通訊領(lǐng)域中 一種確認封包傳輸?shù)姆椒?，特別是指封包由 一用戶端傳輸至一伺服器端，并由用戶端記錄數(shù)據(jù)更新結(jié)果與歷程、及維護更 新流程。
背景技術(shù)：
未來的通訊產(chǎn)業(yè)，是一個結(jié)合電腦的產(chǎn)業(yè)，亦是一個實現(xiàn)人類整合寬頻互 聯(lián)網(wǎng)與無線通訊的前瞻性產(chǎn)業(yè)，也是二十一世紀電子資訊的新興產(chǎn)業(yè)之一。因 此，電腦結(jié)合通訊的應(yīng)用便成為新世紀時代的顯學(xué)。觀之現(xiàn)今電腦在通訊上的 應(yīng)用，實與資訊、通訊、視訊技術(shù)密不可分，但談到應(yīng)用便與生活息息相關(guān)， 而溝通訊息、傳遞訊息更是現(xiàn)代生活的重要事項。在無線通訊領(lǐng)域中，通常使用封包(packet)作為一用戶端傳送數(shù)據(jù)至一伺 服器端的基本單位。常見的無線傳輸方式為，在用戶端傳送每一個封包分為三 個程序，即請求、等待及傳送。請求程序是由控制器控制的，收發(fā)器(transceiver) 則進行等待及傳送程序。在伺服器端接收封包必須要有兩個程序，即接收和報 告，接收程序由收發(fā)器進行，報告程序則由控制器控制。目前對每一個封包傳 送指令是自數(shù)據(jù)連結(jié)層(data link layer)的控制器發(fā)出或以軟體方式發(fā)出，在 封包傳輸過程中，每一個封包都會被賦予一個地址碼和偵4晉監(jiān)測值(checksum)。一般來說，通訊服務(wù)都是由伺服器端主動提供服務(wù)及記錄通訊服務(wù)，所以 在用戶端傳送封包前，伺服器端會主動連結(jié)用戶端，并在用戶端傳送封包至伺 服器端過程中，由伺服器端負責(zé)維護整個通訊協(xié)定的更新程序，且更新結(jié)果皆 由伺服器端紀錄。因此，對伺服器端來說會是一大負擔(dān)，且容易造成封包的遺 失。另外，在網(wǎng)絡(luò)上封包(如數(shù)據(jù))的傳輸，由于習(xí)知技術(shù)采用通道(socket)的 連接方式，在傳輸過程中，無法確定伺服器端是否已將用戶端暫存于緩沖存儲 器(buffer)中的封包數(shù)據(jù)取走，若伺服器端并未取走封包，而用戶端傳還繼續(xù) 向伺服端傳送封包的話，有可能將緩沖存儲器填滿。此時若用戶端還傳送封包，那么就會將緩沖存儲器中的數(shù)據(jù)覆蓋造成了封包的丟失。發(fā)明內(nèi)容本發(fā)明的目的在提供一種確認封包傳輸?shù)姆椒ǎ辽侔ㄒ挥脩舳?Client) 及一伺服器端(Server)，用戶端用以傳送多個封包至伺服器端，該方法包括下 列步驟執(zhí)行用戶端并連接伺服器端。用戶端發(fā)送一確認伺服器端是否下載這 些數(shù)據(jù)封包訊號，并等待伺服器端回應(yīng)是否接收，接著用戶端逐一傳送數(shù)據(jù)封 包于伺服器端。伺服器端接收這些數(shù)據(jù)封包結(jié)束后，并回傳一封包傳送完成訊 號于用戶端。最后，用戶端傳送一數(shù)據(jù)封包下載結(jié)束訊號于伺服器端。其中，藉由上述的確認封包傳輸?shù)姆椒纱_認該封包傳輸沒有遺失，使該 伺服器端確實收到了傳送的封包，而確定該封包傳輸?shù)耐暾?。流程的?shù)據(jù)記錄，且伺服器端可回傳封包的錯誤狀態(tài)至用戶端分析與判斷，而 伺服器端始終保持連線狀態(tài)以確定封包不會遺失。附困說明

圖1A和圖IB為本發(fā)明的確認封包傳輸?shù)姆椒ǖ牧鞒虉D。
具體實施方式
茲配合附圖詳述本發(fā)明確認封包傳輸?shù)姆椒?，并列舉較佳實施例說明如下 請參照圖1A和圖1B，確認封包傳輸?shù)姆椒ㄖ辽侔ㄒ挥脩舳?client)及 一伺服器端(server)，用以傳送多個封包至伺服器端，該封包格式包括聲音、 數(shù)據(jù)、序文、目的位址、來源位址等，且封包傳送指令是自數(shù)據(jù)連結(jié)層(data link layer)的控制器發(fā)出或以軟體方式發(fā)出。本實施例中，用戶端為一電腦，伺服 器端為一手機。封包傳輸方法至少包括下列步驟開啟伺服器端并建立通道，以等待用戶 端連接(SIOI)，其中通道可為一聲音或是一更新程序，且更新程序包括開始、 重起、繼續(xù)、或結(jié)束程序；用戶端執(zhí)行后選擇伺服器端做連線(S102);用戶端 通知伺服器端開始進行更新程序(start updating notification),且確認祠服 器端是否下栽這些數(shù)據(jù)封包的訊號(S103);接著伺服器端開始進行上述的更新 程式(下載數(shù)據(jù)封包)并回應(yīng)(ACK)用戶端(SI04);用戶端搜尋并讀取用戶端(電腦)內(nèi)欲傳送的檔案，再一次與伺服器端確認是否連線(S105);伺服器端回應(yīng)其 連線結(jié)果(S106);用戶端傳送一執(zhí)行訊號及其檔案封包，執(zhí)行訊號包括一檔名、 一檔案大小、或一執(zhí)行方式，如解檔、燒錄、刪除檔案或備份檔案等(S107)。 接著，伺服器端判斷是否接受傳來的封包檔案及大小，并與以回應(yīng)(S108);伺 服器確認接下來的執(zhí)行程序及其執(zhí)行訊號(S109);用戶端開始傳送封包(S 110); 且伺服器端予以回應(yīng)并開始接收檔案(S111);此時，伺服器端執(zhí)行用戶端的命 令并顯示出接收的進度訊號，若進度訊號超過一接收時間(timeout),伺服器端 會傳送一輪詢(polling)訊號至所有連接的用戶端，詢問是否有數(shù)據(jù)待傳輸 (S112);待全部封包傳送完成，用戶端伺服器端即發(fā)出一傳送封包完成訊號， 且伺月良器端回到等待連線狀態(tài)(S113);如此重復(fù)步驟S105至S113，直到用戶 端傳送的檔案完畢，伺服器端刪除連結(jié)于用戶端的通道，并傳送一結(jié)束程序(數(shù) 據(jù)封包下栽結(jié)束)訊號至伺服器端(S114);伺服器端遂執(zhí)行命令離開該更新程式 (下栽數(shù)據(jù)封包)，并予以回應(yīng)該用戶端(S115)。在步驟S112，若傳送封包速度過慢，導(dǎo)致用戶端與伺服器端斷線，且造成 傳送封包遺失。本發(fā)明是將封包傳送數(shù)據(jù)由用戶端紀錄，如此在斷線封包遺失 時，用戶端可自動再傳輸一次，以減少伺服器端的負擔(dān)。相對來說，伺服器端 在隨時保持連線狀態(tài)以供用戶端進行連線，其傳送的封包并不會因用戶端斷線 而遺失。另外，在網(wǎng)絡(luò)上封包(如數(shù)據(jù))的傳輸，由于已知技術(shù)中我們采用通道 (socket)的連接方式，在傳輸過程中，我們無法確定伺服器端是否以將用戶端 暫存于緩沖存儲器(buffer)中的封包數(shù)據(jù)取走，若伺服器端并未取走封包，而 用戶端傳還繼續(xù)向伺服端傳送封包的話，有可能將緩沖存儲器填滿。此時若用 戶端還傳送封包，那么就會將緩沖存儲器中的數(shù)據(jù)覆蓋造成了封包的丟失，所 以本發(fā)明采用上述的一種封包的確認機制來確保我們封包沒有丟失，伺服器端 確實收到了傳送的封包，而保證了通訊協(xié)定中網(wǎng)絡(luò)封包傳輸?shù)耐暾?。值得注意的是，由于已知每一用戶端傳送封包至伺服器端，伺服器端需?部接收并記錄其歷程與結(jié)果。本發(fā)明的確認封包傳輸?shù)姆椒?，其更新結(jié)果與歷 程、及維護更新流程(包括開始、重起、繼續(xù)、結(jié)束)皆由用戶端紀錄，以減少 伺服器端負擔(dān)。再由伺服器端回傳封包的錯誤狀態(tài)至用戶端分析與判斷，如此 一來，伺服器端僅需負責(zé)對傳送來的封包檢視錯誤，而不會產(chǎn)生過多的負擔(dān)。上列詳細說明是針對本發(fā)明較佳實施例的具體說明，但上述實施例并非用以限制本發(fā)明的專利范圍，凡未脫離本發(fā)明技術(shù)精神所為的等效實施或變更， 均應(yīng)包含于本案的專利范圍中。
權(quán)利要求
1. 一種確認封包傳輸?shù)姆椒?，至少包括一用戶端及一伺服器端，該用戶端用以傳送多個封包至該伺服器端，該方法至少包括下列步驟執(zhí)行該用戶端并連接該伺服器端；該用戶端發(fā)送一確認該伺服器端是否下載這些數(shù)據(jù)封包訊號，并等待該伺服器端回應(yīng)是否接收，接著該用戶端逐一傳送數(shù)據(jù)封包于該伺服器端；該伺服器端接收這些數(shù)據(jù)封包結(jié)束后，并回傳一封包傳送完成訊號于該用戶端；及該用戶端傳送一數(shù)據(jù)封包下載結(jié)束訊號于該伺服器端；其中，藉由上述的方法可確認這些數(shù)據(jù)封包傳輸沒有遺失，使該伺服器端確實收到了傳送的這些封包，且確定這些封包傳輸?shù)耐暾浴?br> 2. 如權(quán)利要求1所述的通訊系統(tǒng)，其特征在于，在執(zhí)行步驟a前，還包括 開啟該伺服器端以等待該用戶端連接。
3. 如權(quán)利要求1所述的通訊系統(tǒng)，其特征在于，該伺服器端為一手機。
4. 如4又利要求3所述的通訊系統(tǒng)，其特征在于，該執(zhí)行訊號包括一檔名、 一檔案大小或一執(zhí)行方式。
5. 如權(quán)利要求1所述的通訊系統(tǒng)，其特征在于，在傳送步驟c的該數(shù)據(jù)封 包時，該伺服器端會顯示出一進度訊號，若該進度訊號超過一接收時間，該伺 服器端會傳送一輪詢訊號至所有連接的該用戶端，詢問是否有數(shù)據(jù)待傳輸。
6. 如權(quán)利要求1所述的通訊系統(tǒng)，其特征在于，在步驟e后，該伺服器端 回到等待連線狀態(tài)。
全文摘要
本發(fā)明涉及一種確認封包傳輸?shù)姆椒ǎ辽侔ㄒ挥脩舳思耙凰欧鞫?，用戶端用以傳送多個封包至伺服器端，該方法至少包括下列步驟執(zhí)行用戶端并連接伺服器端。用戶端發(fā)送一確認伺服器端是否下載這些數(shù)據(jù)封包訊號，并等待伺服器端回應(yīng)是否接收，接著用戶端逐一傳送數(shù)據(jù)封包于伺服器端。伺服器端接收這些數(shù)據(jù)封包結(jié)束后，并回傳一封包傳送完成訊號于用戶端。最后，用戶端傳送一數(shù)據(jù)封包下載結(jié)束訊號于伺服器端。
文檔編號H04L12/56GK101262411SQ20071003792
公開日2008年9月10日 申請日期2007年3月8日 優(yōu)先權(quán)日2007年3月8日
發(fā)明者政 何 申請人:英華達(上海)科技有限公司