專利名稱：客戶端信息的同步方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及一種客戶端信息的同步方法和系統(tǒng)。
背景技術(shù)：
目前，開放移動聯(lián)盟設(shè)備管理(Open Mobile Alliance Data Synchronization，簡 稱為OMA DS)業(yè)務(wù)是基于OMA信息同步標準協(xié)議(Synchronization Mark up Language，簡 稱為SyncMDDS相關(guān)標準的移動數(shù)據(jù)增值業(yè)務(wù)，它應(yīng)用于移動設(shè)備和網(wǎng)絡(luò)服務(wù)之間的數(shù)據(jù) 同步。除此之外，DS還可用于對等的數(shù)據(jù)同步，如兩臺PC之間。經(jīng)過同步初始化階段的參 數(shù)協(xié)商以后，終端和服務(wù)器互相發(fā)送各自改變的數(shù)據(jù)，以保證雙方數(shù)據(jù)的同步。隨著通信技術(shù)的快速發(fā)展，對移動終端中的相關(guān)信息的管理顯得尤為重要，例如， 個人信息、日程信息、郵件信息等，已經(jīng)成為手機信息管理的一個重要組成部分。如何安全 有效的將數(shù)據(jù)備份到網(wǎng)絡(luò)服務(wù)器中，在更換手機或者手機數(shù)據(jù)發(fā)生變化的時候，可以方便 的將備份數(shù)據(jù)恢復(fù)到手機成為數(shù)據(jù)同步的主題，SyncML協(xié)議可以實現(xiàn)手機終端和網(wǎng)絡(luò)服務(wù) 器的數(shù)據(jù)同步。假設(shè)手機中的手機卡(SIM或者USIM卡等)某個網(wǎng)絡(luò)服務(wù)器上注冊了一個SyncML 帳號，則當手機的數(shù)據(jù)信息發(fā)生變化時，用戶可以直接利用手機中的SyncML應(yīng)用進行數(shù)據(jù) 同步，使得手機終端數(shù)據(jù)與服務(wù)器數(shù)據(jù)保持一致。下面結(jié)合圖1對現(xiàn)有技術(shù)中涉及的同步數(shù)據(jù)時協(xié)議過程進行描述，該流程為 SyncML協(xié)議的一種通用協(xié)議流程，已普遍應(yīng)用于常規(guī)的同步過程中，如圖1所示，包括以下 處理步驟S101，客戶端向服務(wù)器發(fā)送初始化包，該初始化包中攜帶有同步的數(shù)據(jù)庫、發(fā) 起的同步類型、鑒權(quán)信息、業(yè)務(wù)能力等信息。步驟S102，服務(wù)器接收到來自客戶端的初始化包后，會向客戶端發(fā)送該初始化包 的響應(yīng)消息。另外，為了完成初始化，服務(wù)器會向客戶端發(fā)送該服務(wù)器的鑒權(quán)信息，同步戳、 設(shè)備信息等參數(shù)，并且，服務(wù)器必須接受客戶端發(fā)送的同步類型。至此，客戶端與服務(wù)器的雙向鑒權(quán)過程結(jié)束，完成了初始化階段。步驟S103，客戶端向服務(wù)器發(fā)送用戶在客戶端側(cè)更新的更新數(shù)據(jù)。步驟S104，服務(wù)器接收來自客戶端的更新數(shù)據(jù)，并在服務(wù)器本地進行更新，得到同 步更新結(jié)果，將該同步更新結(jié)果發(fā)送給客戶端，其中，該同步更新結(jié)果包括以下之一服務(wù) 器在其本地對該更新數(shù)據(jù)進行更新后的更新成功結(jié)果、服務(wù)器在其本地對該更新數(shù)據(jù)進行 更新后的更新失敗結(jié)果。并且，如果用戶在服務(wù)器側(cè)對用戶數(shù)據(jù)進行了更新，則服務(wù)器將 用戶在服務(wù)器側(cè)進行更新的更新數(shù)據(jù)以及該更新數(shù)據(jù)的本地唯一標識符(Locally Unique Identifier,簡稱為LUID)均發(fā)送給客戶端，且服務(wù)器在其本地進行map操作建立LUID 與全局唯一標識符(Global Unique Identif ier，簡稱為⑶ID)的映射信息，其中，LUID用 于指示該更新數(shù)據(jù)在客戶端側(cè)對應(yīng)的標識，GUID用于指示該更新數(shù)據(jù)在服務(wù)器側(cè)對應(yīng)的標 識。
步驟S105，客戶端接收來自服務(wù)器更新數(shù)據(jù)，并在客戶端本地進行更新，得到同步 更新結(jié)果，將該同步更新結(jié)果發(fā)送給服務(wù)器，其中，該同步更新結(jié)果包括以下之一客戶端 在其本地對該更新數(shù)據(jù)進行更新后的更新成功結(jié)果、客戶端在其本地對該更新數(shù)據(jù)進行更 新后的更新失敗結(jié)果。發(fā)送數(shù)據(jù)更新狀態(tài)包通知服務(wù)器數(shù)據(jù)更新的結(jié)果。步驟S106，服務(wù)器向客戶端發(fā)送響應(yīng)于步驟S106中的更新數(shù)據(jù)和同步更新結(jié)果 的響應(yīng)消息?？梢钥闯觯谥八枋龅臄?shù)據(jù)同步過程中，不論是否有需要同步的數(shù)據(jù)，客戶端 均需要與服務(wù)器進行6次交互，導(dǎo)致數(shù)據(jù)同步占用大量的時間，并且會增加網(wǎng)絡(luò)出現(xiàn)故障 的概率，進而降低用戶的體驗。針對相關(guān)技術(shù)中數(shù)據(jù)同步過程冗余的問題，目前尚未提出有效的解決方案。

發(fā)明內(nèi)容
考慮到相關(guān)技術(shù)中存在的數(shù)據(jù)同步過程冗余的問題而提出本發(fā)明，為此，本發(fā)明 的主要目的在于提供一種客戶端信息的同步方法及系統(tǒng)，以解決上述問題。根據(jù)本發(fā)明的一個方面，提供一種客戶端信息的同步方法，該方法可以用于基于 同步標準協(xié)議實現(xiàn)服務(wù)器與客戶端之間的信息同步。根據(jù)本發(fā)明的客戶端信息的同步方法包括在服務(wù)器響應(yīng)于來自客戶端的第一同 步數(shù)據(jù)包在服務(wù)器本地更新了客戶端的信息之后，如果服務(wù)器確定無需對客戶端的信息進 行進一步更新，則服務(wù)器向客戶端發(fā)送狀態(tài)響應(yīng)消息；響應(yīng)于狀態(tài)響應(yīng)消息，客戶端停止與 服務(wù)器進行基于同步標準協(xié)議的通信。其中，第一同步數(shù)據(jù)包包括客戶端請求更新的數(shù)據(jù)以及相應(yīng)的LUID。其中，狀態(tài)響應(yīng)消息中包括服務(wù)器在其本地對客戶端的信息進行更新的結(jié)果。優(yōu)選地，如果服務(wù)器確定需要對客戶端的信息進行進一步更新，則服務(wù)器向客戶 端發(fā)送第二同步數(shù)據(jù)包和狀態(tài)響應(yīng)消息。進一步地，在發(fā)送第二同步數(shù)據(jù)包之前，上述方法還包括服務(wù)器在其本地查找服 務(wù)器請求更新的數(shù)據(jù)的GUID，并根據(jù)預(yù)先保存的對應(yīng)關(guān)系確定與該GUID對應(yīng)的LUID ；和/ 或，服務(wù)器為請求更新的數(shù)據(jù)配置新的GUID。其中，第二同步數(shù)據(jù)包包括以下至少之一服務(wù)器請求更新的數(shù)據(jù)以及確定的 LUID、服務(wù)器請求更新的數(shù)據(jù)以及新的⑶ID。根據(jù)本發(fā)明的另一個方面，提供一種客戶端信息的同步系統(tǒng)。根據(jù)本發(fā)明的客戶端信息的同步系統(tǒng)包括服務(wù)器與客戶端，其中，服務(wù)器包括更 新模塊，用于響應(yīng)于來自客戶端的第一同步數(shù)據(jù)包在服務(wù)器本地更新客戶端的信息；確定 模塊，用于在更新模塊進行更新之后確定服務(wù)器是否需要對客戶端的信息進行進一步更 新；發(fā)送模塊，用于在確定模塊確定服務(wù)器無需進行進一步更新的情況下，向客戶端發(fā)送狀 態(tài)響應(yīng)消息；客戶端包括通信控制模塊，用于響應(yīng)于狀態(tài)響應(yīng)消息，控制客戶端停止與服 務(wù)器進行基于同步標準協(xié)議的通信。其中，第一同步數(shù)據(jù)包包括客戶端請求更新的數(shù)據(jù)以及相應(yīng)的LUID。其中，狀態(tài)響應(yīng)消息中包括服務(wù)器在其本地對客戶端的信息進行更新的結(jié)果。其中，發(fā)送模塊還用于在確定模塊確定服務(wù)器需要進行進一步更新的情況下，則向客戶端發(fā)送第二同步數(shù)據(jù)包和狀態(tài)響應(yīng)消息。優(yōu)選地，上述服務(wù)器還包括查詢模塊，用于查找服務(wù)器請求更新的數(shù)據(jù)的⑶ID， 并根據(jù)預(yù)先保存的對應(yīng)關(guān)系確定與該GUID對應(yīng)的LUID ；配置模塊，用于為請求更新的數(shù)據(jù) 配置新的⑶ID。其中，第二同步數(shù)據(jù)包包括以下至少之一服務(wù)器請求更新的數(shù)據(jù)以及確定的 LUID、服務(wù)器請求更新的數(shù)據(jù)以及新的⑶ID。借助本發(fā)明的上述至少一個技術(shù)方案，通過在數(shù)據(jù)同步過程中由服務(wù)器發(fā)送相應(yīng) 消息通知客戶端無需更新，使客戶端能夠省去之后與服務(wù)器進行的不必要交互，能夠在保 證服務(wù)器與客戶端之間正常完成信息同步的同時有效減少服務(wù)器與客戶端之間的消息交 互處理，從而有效節(jié)省了系統(tǒng)開銷。


附圖用來提供對本發(fā)明的進一步理解，并且構(gòu)成說明書的一部分，與本發(fā)明的實 施例一起用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的限制。在附圖中圖1是根據(jù)相關(guān)技術(shù)的服務(wù)器有實際同步數(shù)據(jù)時協(xié)議流程圖；圖2是根據(jù)本發(fā)明實施例的客戶端信息的同步方法的流程圖；圖3是根據(jù)本發(fā)明實施例的服務(wù)器無實際同步數(shù)據(jù)時協(xié)議流程圖；圖4是根據(jù)本發(fā)明實施例的客戶端處理流程圖；圖5是根據(jù)本發(fā)明實施例的服務(wù)器端處理流程圖。圖6是根據(jù)本發(fā)明實施例的客戶端信息的同步系統(tǒng)的結(jié)構(gòu)框圖。
具體實施例方式功能概述為了便于理解，在對本發(fā)明實施例進行說明之前，首先對現(xiàn)有技術(shù)中的同步數(shù)據(jù) 時協(xié)議過程(例如，圖1所示的流程)進行簡要的描述在常規(guī)的SyncML協(xié)議處理流程中， 第一個包是客戶端向服務(wù)器發(fā)送的用于發(fā)起同步的初始化包；第二個包是服務(wù)器向客戶端 發(fā)送的初始化信息包；第三個包是客戶端向服務(wù)器發(fā)送的封裝了客戶端需要進行數(shù)據(jù)同步 的同步包；第四個包是服務(wù)器向客戶端發(fā)送的封裝了服務(wù)器需要進行數(shù)據(jù)同步的同步包 (包含處理客戶端發(fā)送數(shù)據(jù)的狀態(tài)響應(yīng)信息和需要同步的數(shù)據(jù))；第五個包是客戶端向服 務(wù)器發(fā)送的響應(yīng)消息，用于客戶端回應(yīng)map信息給服務(wù)器；第六個包是服務(wù)器向客戶端發(fā) 送的map信息確認包。目前的同步協(xié)議流程包括上述這六個包的發(fā)送和接收。考慮到數(shù)據(jù)同步業(yè)務(wù)是直接面向用戶的增值業(yè)務(wù)，需要以提高用戶體驗為目標對 協(xié)議進行優(yōu)化處理。本發(fā)明的基本思想是服務(wù)器在接收到第三個包之后，如果服務(wù)器在第 四個包中并無實際的同步數(shù)據(jù)需要發(fā)送到客戶端，服務(wù)器在向客戶端發(fā)送響應(yīng)于第三個包 的響應(yīng)消息(該響應(yīng)消息中只攜帶有圖1中步驟S104中的同步更新結(jié)果)后，服務(wù)器側(cè)的 同步協(xié)議流程結(jié)束，否則繼續(xù)執(zhí)行步驟S105至步驟S106。相應(yīng)地，客戶端接收第四個包之 后，如果客戶端發(fā)現(xiàn)該第四個包中并無需要同步更新的數(shù)據(jù)，只包含有同步更新結(jié)果，則客 戶端側(cè)的同步更新流程結(jié)束，否則，客戶端會構(gòu)建第五個包(包含map信息和客戶端數(shù)據(jù)更 新狀態(tài)信息)并將該第五個包發(fā)送給服務(wù)器。即，前四個包(第一個包至第四個包)的發(fā)送和接收是按照圖1所示的同步協(xié)議流程進行的，后續(xù)會根據(jù)服務(wù)器是否存在實際同步數(shù) 據(jù)動態(tài)地決定是否發(fā)送最后兩個包(第五個包和第六個包)，如果服務(wù)器需要發(fā)送同步數(shù) 據(jù)，則按照圖1所示的同步協(xié)議流程進行處理，否則不再發(fā)送最后兩個包。以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行說明，應(yīng)當理解，此處所描述的優(yōu)選實 施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。在以下的描述中，為了解釋的目的，描述了多個特定的細節(jié)，以提供對本發(fā)明的透 徹理解。然而，很顯然，在沒有這些特定細節(jié)的情況下，也可以實現(xiàn)本發(fā)明，此外，在不沖突 的情況下，即在不背離所附權(quán)利要求闡明的精神和范圍的情況下，下述實施例以及實施例 中得各個細節(jié)可以進行各種組合。方法實施例根據(jù)本發(fā)明實施例，提供了 一種客戶端信息的同步方法。圖2是根據(jù)本發(fā)明實施例的客戶端信息的同步方法的流程圖，該方法基于同步標 準協(xié)議實現(xiàn)服務(wù)器與客戶端之間的信息同步，如圖2所示，該方法包括以下步驟步驟S202，在服務(wù)器響應(yīng)于來自客戶端的第一同步數(shù)據(jù)包在服務(wù)器本地更新了客 戶端的信息之后，如果服務(wù)器確定無需對客戶端的信息進行進一步更新，則服務(wù)器向客戶 端發(fā)送狀態(tài)響應(yīng)消息，其中，上述第一同步數(shù)據(jù)包包括客戶端請求更新的數(shù)據(jù)以及相應(yīng)的 LUID (本地唯一標識符)，并且，上述狀態(tài)響應(yīng)消息中包括服務(wù)器在其本地對客戶端的信息 進行更新的結(jié)果。步驟S204，響應(yīng)于狀態(tài)響應(yīng)消息，客戶端停止與服務(wù)器進行基于同步標準協(xié)議的 通信；之后，如果服務(wù)器確定需要對客戶端的信息進行進一步更新，其中，該更新操作包括 增加新數(shù)據(jù)、刪除已有的數(shù)據(jù)、修改已有的數(shù)據(jù)。一方面，如果更新操作為刪除已有的數(shù)據(jù) 或修改已有的數(shù)據(jù)，則服務(wù)器會在其本地查找服務(wù)器請求刪除或修改的數(shù)據(jù)的GUID(全局 唯一標識符)，并根據(jù)預(yù)先保存的對應(yīng)關(guān)系確定與該GUID對應(yīng)的LUID，并向客戶端發(fā)送第 二同步數(shù)據(jù)包和狀態(tài)響應(yīng)消息，其中，該第二同步數(shù)據(jù)包包括服務(wù)器請求更新的數(shù)據(jù)以 及確定的LUID，客戶端接收到該第二同步數(shù)據(jù)包之后，會對相應(yīng)的數(shù)據(jù)執(zhí)行刪除或修改的 操作；另一方面，如果更新操作為增加新數(shù)據(jù)，則服務(wù)器會為請求增加的新數(shù)據(jù)配置新的 ⑶ID，并向客戶端發(fā)送第二同步數(shù)據(jù)包和狀態(tài)響應(yīng)消息，其中，該第二同步數(shù)據(jù)包包括服 務(wù)器請求增加的新數(shù)據(jù)以及該新數(shù)據(jù)對應(yīng)的GUID，客戶端接收到該第二同步數(shù)據(jù)包之后， 將該新數(shù)據(jù)保存到本地，并為該新數(shù)據(jù)配置新的LUID，并且，客戶端會建立新數(shù)據(jù)對應(yīng)的 GUID與LUID之間的對應(yīng)關(guān)系，并將該新的對應(yīng)關(guān)系發(fā)送給服務(wù)器，服務(wù)器將該新的對應(yīng)關(guān) 系保存在map信息中。通過本發(fā)明實施例提供的技術(shù)方案，能夠根據(jù)對服務(wù)器是否存在同步數(shù)據(jù)的分析 而動態(tài)進行同步包的構(gòu)建，對同步的流程進行了動態(tài)的優(yōu)化，在保證服務(wù)器與客戶端之間 正常完成信息同步的同時有效減少服務(wù)器與客戶端之間的消息交互處理，從而有效節(jié)省了 系統(tǒng)開銷。下面結(jié)合圖3對圖2所示的方法進行說明，圖3示出了根據(jù)本發(fā)明的服務(wù)器無實 際同步數(shù)據(jù)時的協(xié)議流程圖，如圖3所示，包括以下處理步驟S301，客戶端向服務(wù)器發(fā)送初始化包，該初始化包中攜帶有同步的數(shù)據(jù)庫、發(fā) 起的同步類型、鑒權(quán)信息、業(yè)務(wù)能力等信息。
步驟S302，服務(wù)器接收到來自客戶端的初始化包后，會向客戶端發(fā)送該初始化包 的響應(yīng)消息。另外，為了完成初始化，服務(wù)器會向客戶端發(fā)送該服務(wù)器的鑒權(quán)信息，同步戳、 設(shè)備信息等參數(shù)，并且，服務(wù)器必須接受客戶端發(fā)送的同步類型。至此，客戶端與服務(wù)器的雙向鑒權(quán)過程結(jié)束，完成了初始化階段。步驟S303，客戶端向服務(wù)器發(fā)送用戶在客戶端側(cè)更新的更新數(shù)據(jù)。步驟S304，服務(wù)器接收來自客戶端的更新數(shù)據(jù)，并在服務(wù)器本地進行更新，得到同 步更新結(jié)果，并且，如果用戶在服務(wù)器側(cè)沒有對用戶數(shù)據(jù)進行更新，則服務(wù)器僅將該同步更 新結(jié)果發(fā)送給客戶端，其中，該同步更新結(jié)果包括以下之一服務(wù)器在其本地對該更新數(shù)據(jù) 進行更新后的更新成功結(jié)果、服務(wù)器在其本地對該更新數(shù)據(jù)進行更新后的更新失敗結(jié)果。S卩，如果在步驟S104中，服務(wù)器側(cè)并無實際需要同步的數(shù)據(jù)，則服務(wù)器向客戶端 發(fā)送的第四個包中僅包含服務(wù)器側(cè)數(shù)據(jù)處理的狀態(tài)信息。在第五個包括中并無實際的數(shù)據(jù) 更新狀態(tài)和map信息，第六個包也無需進行map確認，在這種情況下最后兩個包不再有實際 的功能，可以不再進行最后兩個包的發(fā)送。下面結(jié)合圖4和圖5對本發(fā)明中客戶端側(cè)和服務(wù)器側(cè)的處理流程分別進行說明， 圖4是根據(jù)本發(fā)明的客戶端側(cè)的同步協(xié)議處理流程圖，圖4與圖1所示方法的不同點在于 客戶端可以通過對協(xié)議包信息的判斷動態(tài)地進行協(xié)議包的發(fā)送。步驟S401，客戶端構(gòu)建其發(fā)送給服務(wù)器的同步初始化包，該初始化包中攜帶有同 步的數(shù)據(jù)庫、發(fā)起的同步類型、鑒權(quán)信息、業(yè)務(wù)能力等信息。步驟S402，客戶端接收來自服務(wù)器端的初始化包，該初始化包中攜帶有服務(wù)器的 鑒權(quán)信息，同步戳、設(shè)備信息等參數(shù)，。步驟S403，客戶端構(gòu)建同步數(shù)據(jù)包，并將該同步數(shù)據(jù)包發(fā)送給服務(wù)器，同步數(shù)據(jù)包 中包括用戶在客戶端側(cè)更新的更新數(shù)據(jù)。步驟S404，客戶端接收并分析來自服務(wù)器端的同步數(shù)據(jù)包。步驟S405，客戶端判斷來自服務(wù)器的同步數(shù)據(jù)包中是否無實際的同步數(shù)據(jù)，僅包 含服務(wù)器的同步更新結(jié)果，如果判斷結(jié)果為是，則客戶端側(cè)的同步協(xié)議流程結(jié)束，否則進入 到步驟S406。步驟S406，客戶端構(gòu)建狀態(tài)和map信息包，并將該信息包發(fā)送給服務(wù)器，并執(zhí)行步 驟 S407。步驟S407，客戶端接收并處理來自服務(wù)器的map信息確認包。圖5是根據(jù)本發(fā)明的服務(wù)器側(cè)的同步協(xié)議處理流程圖，圖5與圖1所示方法的不 同點在于服務(wù)器可以通過對協(xié)議包信息的判斷動態(tài)地進行協(xié)議包的發(fā)送。步驟S501，服務(wù)器接收并處理來自客戶端的初始化包，該初始化包中攜帶有同步 的數(shù)據(jù)庫、發(fā)起的同步類型、鑒權(quán)信息、業(yè)務(wù)能力等信息。步驟S502，為了完成初始化，服務(wù)器會向客戶端發(fā)送該服務(wù)器的鑒權(quán)信息，同步 戳、設(shè)備信息等參數(shù)，并且，服務(wù)器必須接受客戶端發(fā)送的同步類型，以及向客戶端發(fā)送步 驟S501中的初始化包的響應(yīng)消息。步驟S503，服務(wù)器接收并處理來自客戶端的同步數(shù)據(jù)包，該同步數(shù)據(jù)包中包括用 戶在客戶端側(cè)更新的更新數(shù)據(jù)。步驟S504，服務(wù)器構(gòu)建其發(fā)送給客戶端的同步數(shù)據(jù)包。
步驟S505，服務(wù)器判斷該服務(wù)器側(cè)是否存在需要更新的同步數(shù)據(jù)，如果判斷結(jié)果 為是，則進入到步驟S506，否則，服務(wù)器向客戶端發(fā)送響應(yīng)于來自客戶端的同步數(shù)據(jù)包的同 步更新結(jié)果，至此，服務(wù)器側(cè)的同步協(xié)議流程結(jié)束。步驟S506，服務(wù)器接收并處理來自客戶端的狀態(tài)和map信息包。步驟S507，服務(wù)器構(gòu)建map信息確認包，并將該map信息確認包發(fā)送給客戶端。通過上述處理，能夠根據(jù)對服務(wù)器是否存在同步數(shù)據(jù)的分析而動態(tài)進行同步包的 構(gòu)建，對同步的流程進行了動態(tài)的優(yōu)化，使客戶端能夠省去與服務(wù)器進行的不必要交互，在 保證服務(wù)器與客戶端之間正常完成信息同步的同時有效減少服務(wù)器與客戶端之間的消息 交互處理，從而有效節(jié)省了系統(tǒng)開銷；并且，上述處理可以動態(tài)的進行包的構(gòu)建，當用戶需 要同步客戶端的更新、且服務(wù)器無數(shù)據(jù)更新時，能夠明顯減少冗余的交互流程。系統(tǒng)實施例在本實施例中，提供了一種客戶端信息的同步系統(tǒng)。圖6示出了根據(jù)本發(fā)明實施 例的客戶端信息的同步系統(tǒng)的結(jié)構(gòu)。如圖6所示，根據(jù)本實施例的客戶端信息的同步系統(tǒng)包括服務(wù)器1和客戶端2，其 中，服務(wù)器1與客戶端2能夠基于同步標準協(xié)議實現(xiàn)彼此之間的通信。具體地，如圖6所示， 服務(wù)器1可以包括更新模塊11、確定模塊12、發(fā)送模塊13、查詢模塊14和配置模塊15，客 戶端2可以包括通信控制模塊21。下面將詳細描述圖6中所示的各個模塊的功能。更新模塊11，用于響應(yīng)于來自客戶端的第一同步數(shù)據(jù)包在服務(wù)器本地更新客戶端 的信息；確定模塊12，連接至更新模塊11，用于在更新模塊11進行更新之后確定服務(wù)器是 否需要對客戶端的信息進行進一步更新；發(fā)送模塊13，連接至確定模塊12，用于在確定模塊12確定服務(wù)器無需進行進一步 更新的情況下，向客戶端發(fā)送狀態(tài)響應(yīng)消息；以及在確定模塊12確定服務(wù)器需要對客戶端 2的信息進行進一步更新的情況下向客戶端2發(fā)送第二同步數(shù)據(jù)包和狀態(tài)響應(yīng)消息；查詢模塊14，連接至發(fā)送模塊13和確定模塊12，用于在確定模塊12確定服務(wù)器 需要對客戶端2的信息進行進一步更新的情況下查找由服務(wù)器請求更新的數(shù)據(jù)的GUID，并 根據(jù)預(yù)先保存的對應(yīng)關(guān)系確定與該⑶ID對應(yīng)的LUID，以便構(gòu)造第二同步數(shù)據(jù)包；配置模塊15，用于為請求更新的數(shù)據(jù)配置新的⑶ID ；通信控制模塊21，用于響應(yīng)于來自發(fā)送模塊13的狀態(tài)響應(yīng)消息，控制客戶端停止 與服務(wù)器進行基于同步標準協(xié)議的通信。其中，上述第一同步數(shù)據(jù)包可以包括客戶端請求更新的數(shù)據(jù)以及相應(yīng)的LUID。優(yōu)選地，由發(fā)送模塊13發(fā)送的狀態(tài)響應(yīng)消息中可以包括服務(wù)器在其本地對客戶 端的信息進行更新的結(jié)果；由發(fā)送模塊13發(fā)送的第二同步數(shù)據(jù)包可以包括以下至少之一 服務(wù)器請求更新的數(shù)據(jù)以及確定的LUID、服務(wù)器請求更新的數(shù)據(jù)以及新的GUID。通過本發(fā)明實施例提供的客戶端信息的同步系統(tǒng)，能夠根據(jù)對服務(wù)器是否存在同 步數(shù)據(jù)的分析而動態(tài)進行同步包的構(gòu)建，對同步的流程進行了動態(tài)的優(yōu)化，在保證服務(wù)器 與客戶端之間正常完成信息同步的同時有效減少服務(wù)器與客戶端之間的消息交互處理，從 而有效節(jié)省了系統(tǒng)開銷。
如上所述，借助于本發(fā)明提供的客戶端信息的同步方法和/或系統(tǒng)，通過在數(shù)據(jù) 同步過程中由服務(wù)器發(fā)送相應(yīng)消息通知客戶端無需更新，使客戶端能夠省去之后與服務(wù)器 進行的不必要交互，能夠在保證服務(wù)器與客戶端之間正常完成信息同步的同時有效減少服 務(wù)器與客戶端之間的消息交互處理，從而有效節(jié)省了系統(tǒng)開銷。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技 術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修 改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
一種客戶端信息的同步方法，用于基于同步標準協(xié)議實現(xiàn)服務(wù)器與客戶端之間的信息同步，其特征在于，所述方法包括在所述服務(wù)器響應(yīng)于來自所述客戶端的第一同步數(shù)據(jù)包在所述服務(wù)器本地更新了所述客戶端的信息之后，如果所述服務(wù)器確定無需對所述客戶端的信息進行進一步更新，則所述服務(wù)器向所述客戶端發(fā)送狀態(tài)響應(yīng)消息；響應(yīng)于所述狀態(tài)響應(yīng)消息，所述客戶端停止與所述服務(wù)器進行基于同步標準協(xié)議的通信。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述第一同步數(shù)據(jù)包包括所述客戶端請 求更新的數(shù)據(jù)以及相應(yīng)的本地唯一標識符即LUID。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述狀態(tài)響應(yīng)消息中包括所述服務(wù)器在 其本地對所述客戶端的信息進行更新的結(jié)果。
4.根據(jù)權(quán)利要求1至3中任一項所述的方法，其特征在于，如果所述服務(wù)器確定需要對 所述客戶端的信息進行進一步更新，則所述服務(wù)器向所述客戶端發(fā)送第二同步數(shù)據(jù)包和所 述狀態(tài)響應(yīng)消息。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，在發(fā)送所述第二同步數(shù)據(jù)包之前，所述方 法還包括所述服務(wù)器在其本地查找所述服務(wù)器請求更新的數(shù)據(jù)的全局唯一標識符即GUID，并根 據(jù)預(yù)先保存的對應(yīng)關(guān)系確定與該GUID對應(yīng)的LUID ；和/或，所述服務(wù)器為所述請求更新的數(shù)據(jù)配置新的GUID。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述第二同步數(shù)據(jù)包包括以下至少之一 所述服務(wù)器請求更新的數(shù)據(jù)以及確定的所述LUID、所述服務(wù)器請求更新的數(shù)據(jù)以及所述新 的⑶ID。
7.一種客戶端信息的同步系統(tǒng)，其特征在于，包括服務(wù)器與客戶端，其中，所述服務(wù)器包括更新模塊，用于響應(yīng)于來自所述客戶端的第一同步數(shù)據(jù)包在所述服務(wù)器本地更新所述 客戶端的信息；確定模塊，用于在所述更新模塊進行更新之后確定所述服務(wù)器是否需要對所述客戶端 的信息進行進一步更新；發(fā)送模塊，用于在所述確定模塊確定所述服務(wù)器無需進行所述進一步更新的情況下， 向所述客戶端發(fā)送狀態(tài)響應(yīng)消息；所述客戶端包括通信控制模塊，用于響應(yīng)于所述狀態(tài)響應(yīng)消息，控制所述客戶端停止與所述服務(wù)器進 行基于同步標準協(xié)議的通信。
8.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述第一同步數(shù)據(jù)包包括所述客戶端請 求更新的數(shù)據(jù)以及相應(yīng)的LUID。
9.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述狀態(tài)響應(yīng)消息中包括所述服務(wù)器在 其本地對所述客戶端的信息進行更新的結(jié)果。
10.根據(jù)權(quán)利要求7至9中任一項所述的系統(tǒng)，其特征在于，所述發(fā)送模塊還用于在所述確定模塊確定所述服務(wù)器需要進行所述進一步更新的情況下，則向所述客戶端發(fā)送第二同步數(shù)據(jù)包和所述狀態(tài)響應(yīng)消息。
11.根據(jù)權(quán)利要求10所述的系統(tǒng)，其特征在于，所述服務(wù)器還包括查詢模塊，用于查找所述服務(wù)器請求更新的數(shù)據(jù)的GUID，并根據(jù)預(yù)先保存的對應(yīng)關(guān)系 確定與該⑶ID對應(yīng)的LUID ；配置模塊，用于為所述請求更新的數(shù)據(jù)配置新的⑶ID。
12.根據(jù)權(quán)利要求11所述的系統(tǒng)，其特征在于，所述第二同步數(shù)據(jù)包包括以下至少之 一所述服務(wù)器請求更新的數(shù)據(jù)以及確定的所述LUID、所述服務(wù)器請求更新的數(shù)據(jù)以及所 述新的⑶ID。
全文摘要
本發(fā)明公開了一種客戶端信息的同步方法和系統(tǒng)，其中，該方法包括在服務(wù)器響應(yīng)于來自客戶端的第一同步數(shù)據(jù)包在服務(wù)器本地更新了客戶端的信息之后，如果服務(wù)器確定無需對客戶端的信息進行進一步更新，則服務(wù)器向客戶端發(fā)送狀態(tài)響應(yīng)消息；響應(yīng)于狀態(tài)響應(yīng)消息，客戶端停止與服務(wù)器進行基于同步標準協(xié)議的通信。借助于本發(fā)明的技術(shù)方案，通過在數(shù)據(jù)同步過程中由服務(wù)器發(fā)送相應(yīng)消息通知客戶端無需更新，使客戶端能夠省去之后與服務(wù)器進行的不必要交互，能夠在保證服務(wù)器與客戶端之間正常完成信息同步的同時有效減少服務(wù)器與客戶端之間的消息交互處理，從而有效節(jié)省了系統(tǒng)開銷。
文檔編號H04L29/06GK101883419SQ20091014080
公開日2010年11月10日 申請日期2009年5月6日 優(yōu)先權(quán)日2009年5月6日
發(fā)明者付麗琴, 蒲競春, 袁磊, 謝鑫, 陳程, 鞠飛, 魏上凱 申請人:中興通訊股份有限公司