專利名稱：一種數據同步的方法、系統(tǒng)及設備的制作方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及一種數據同步的方法、系統(tǒng)及設備。
背景技術：
目前的移動數據同步化大多建立在互不兼容的私有協(xié)議上，每種協(xié)議只能支持有限種類的設備、系統(tǒng)及數據類型，這些不兼容的協(xié)議增加了各方面(用戶、生產商、服務提供商、開發(fā)商)工作的復雜度，且這些不兼容的協(xié)議還會限制移動設備的使用、數據的訪問和發(fā)行。為了解決上述移動數據同步化的問題，業(yè)界提出了一種信息同步標準協(xié)議(Synchronization Markup Language, SyncML), SyncML 協(xié)議是一種與平臺無關的、開放的標準協(xié)議，可以在兼容的設備、程序及網絡之間進行數據同步。 例如,基于SyncML協(xié)議的客戶端(SyncML Client)和基于SyncML協(xié)議的服務器(SyncML Server)之間進行數據(如通訊簿、日歷等數據)同步時的過程如圖I所示，包括以下步驟步驟101 SyncML Client 向 SyncML Server 發(fā)送數據初始化(InitializationPackage)請求,在數據初始化請求中攜帶了 MaxMsgSize參數,用于表示SyncML Client能夠識別SyncML Server返回消息的最大消息長度。步驟102 :SyncML Server 存儲所述 SyncML Client 發(fā)送的 MaxMsgSize 參數,在完成初始化操作后，向SyncML Client返回初始化響應。上述步驟101和步驟102是SyncML Client和SyncML Server進行數據同步之前的初始化操作過程，SyncML Client將自身的相關信息發(fā)送給SyncMLServer。步驟103 SyncML Client向SyncML Server發(fā)送攜帶操作信息的數據同步(SyncPackage)請求,所述數據同步請求的消息長度不大于MaxMsgSize參數所表示的最大消息長度。所述操作信息是SyncML Client請求SyncML Server執(zhí)行的同步操作，如將SyncML Client的通訊簿內的信息同步至SyncML Server的操作信息、將SyncML Client內更新后的日歷信息同步至SyncML Server的操作信息等。步驟104 SyncML Server執(zhí)行所述操作信息對應的操作，生成所述操作的執(zhí)行狀態(tài)消息(Status package),并將所述執(zhí)行狀態(tài)信息返回給SyncMLClient,完成本次SyncMLClient和SyncML Server之間的數據同步過程。在一般情況下，SyncML Server生成的執(zhí)行狀態(tài)消息的消息長度小于接收到的數據同步請求的消息長度，且由于數據同步請求的消息長度不大于MaxMsgSize參數所表示的最大消息長度，則SyncML Server向SyncML Client返回的執(zhí)行狀態(tài)消息的消息長度也不大于MaxMsgSize參數所表示的最大消息長度，因此，SyncML Client能夠正確識別接收到的執(zhí)行狀態(tài)消息。但是，在所述操作信息是刪除操作信息時，SyncML Server將指定的信息刪除后生成的執(zhí)行狀態(tài)消息的消息長度將大于數據同步請求的消息長度，特別是在數據同步請求中攜帶多條刪除操作信息的情況下，由于SyncML Server將為每條刪除操作信息生成相應的狀態(tài)消息，則SyncML Server返回給SyncMLClient的執(zhí)行狀態(tài)消息的消息長度可能會大于MaxMsgSize參數所表示的最大消息長度,導致SyncML Client無法正確識別接收到的執(zhí)行狀態(tài)消息，進而使數據同步操作失敗。以SyncML Client請求SyncML Server同步刪除數據庫中第I條至第8條記錄為例，來說明SyncML Server返回的執(zhí)行狀態(tài)消息的消息長度可能會大于MaxMsgSize參數所表示的最大消息長度的情況。SyncML Client向SyncML Server發(fā)送的數據同步請求的內容為
〈Delete〉 //SyncML Client發(fā)送的數據同步請求中的操作信息是刪除操作信息； <CmdID>12345</CmdID>
<Archive /><Cred>
<Meta>
<Type xmlns='syncml:metinf>syncml:auth-md5</Type>
<Format xmlns='syncml:metinf>b64</Format>
</Meta>
<Data>Zd5awBsesfOcsa=</Data> //確認數據同步請求冗整傳輸的校驗信息； </Cred>
<Item> <Target><LocUEJ>./l</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第I條記錄；
</Item>
<Item>
<Target><LocUEJ>./2</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第2條記錄；
</Item>
<Item>
<Target><LocURI>./3</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第3條記錄；
</Item>
<Ttem>
<Target><LocURI>./4</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第4條記錄；
</Item>
<Item>
<Target><LocURI>./5</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第5條記錄；
</Item>
<Item>
<Target><LocUEJ>./6</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第6條記錄；
</Item>
<Item>
<Target><LocUEJ>./7</LocURI></Target> //請求 SyncML Server 同步刪除數據

庫中第7條記錄；
</Item>
<Item>
<Target><LocURI>./8</LocURI></Target> //請求 SyncML Server 同步刪除數據庫中第8條記錄；
</Item>
〈/Delete〉SyncML Server接收到SyncML Client發(fā)送的數據同步請求時，執(zhí)行相應的刪除操
作，將數據庫中第5條至第12條記錄刪除，生成的執(zhí)行狀態(tài)消息如下
〈Status〉
<CmdID>3</CmdID>
<MsgRef>2</MsgRef^<CmdRef^5</CmdRef^<Cmd>Delete</Cmd>
<SourceRef> 1012</SourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第5條記錄后的生成的狀態(tài)消息；〈Status〉
<CmdID>4</CmdID>
<MsgRef>2</MsgRef^<CmdRef^6</CmdRef^<Cmd>Delete</Cmd>
<S ourceRef> 1013 </ S ourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第6條記錄后的生成的狀態(tài)消息；〈Status〉
<CmdID>5</CmdID>
<MsgRef>2</MsgRef^<CmdRef^7</CmdRef^<Cmd>Delete</Cmd>
<SourceRef> 1014</SourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第7條記錄后的生成的狀態(tài)消息；〈Status〉
<CmdID>6</CmdID>
<MsgRef>2</MsgRef^<CmdRef^8</CmdRef^<Cmd>Delete</Cmd>
<S ourceRef> 1015 </ S ourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第8條記錄后的生成的狀態(tài)消息；、
〈Status〉
<CmdID>7</CmdID>
<MsgRef>2</MsgRef^<CmdRef^9</CmdRef^<Cmd>Delete</Cmd><SourceRef>1016</SourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第9條記錄后的生成的狀態(tài)消息； 〈Status〉
<CmdID>8</CmdID>
<MsgRef>2</MsgRef^<CmdRef^lO</CmdRef^<Cmd>Delete</Cmd>
<S ourceRef> 1017 </ S ourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第10條記錄后的生成的狀態(tài)消息；〈Status〉
<CmdID>9</CmdID>
<MsgRef>2</MsgRef^<CmdRef^ll</CmdRef><Cmd>Delete</Cmd>
<S ourceRef> 1018 </ S ourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第11條記錄后的生成的狀態(tài)消息；〈Status〉
<CmdID>10</CmdID>
<MsgRef>2</MsgRef^<CmdRef^l2</CmdRef^<Cmd>Delete</Cmd><SourceRef>1019</SourceRef>
<Data>200</Data>
</Status> //SyncML Server刪除數據庫中第12條記錄后的生成的狀態(tài)消息；需要說明的是，在SyncML Client和SyncML Server中記錄的同一數據在數據庫中的位置信息可能是不同的，例如在SyncML Client中記錄的位置信息為I的記錄，在SyncML Server中記錄的位置信息為5，在SyncML Client中記錄的位置信息為2的記錄，在SyncML Server中記錄的位置信息為6，以此類推，SyncML Server生成的刪除數據庫中第5條至第12條記錄的執(zhí)行狀態(tài)消息，也就是刪除SyncML Client請求的數據庫中第I條至第8條記錄的執(zhí)行狀態(tài)消息。從上例中可以看出，SyncML Client發(fā)送的數據同步請求的消息長度為592字節(jié)，而SyncML Server返回的執(zhí)行狀態(tài)消息的消息長度為1036字節(jié)，若SyncML Client能夠識別的最大消息長度介于592字節(jié)和1036字節(jié)之間時，SyncML Client可以向SyncML Server正常發(fā)送數據同步請求，但卻不能正確識別SyncML Server返回的執(zhí)行狀態(tài)消息，使數據同步操作失敗。

發(fā)明內容
本發(fā)明實施例提供一種數據同步的方法、系統(tǒng)及設備，用以解決現有技術中存在的當服務器生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，導致數據同步操作失敗的問題。一種數據同步的方法，所述方法包括服務器在接收到客戶端發(fā)送的數據同步請求時，確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度；服務器在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，向客戶端返回狀態(tài)碼，指示客戶端減少所述數據同步請求的消息長度后，向服務器發(fā)送減少消息長度的數據同步請求并重新進行數據同步。 —種服務器，所述服務器包括請求接收模塊，用于接收數據同步請求；判斷模塊，用于判斷響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度是否大于客戶端能夠識別的最大消息長度；返回模塊，用于在判斷結果為生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，向客戶端返回狀態(tài)碼，指示客戶端減少所述數據同步請求的消息長度后，向服務器發(fā)送減少消息長度的數據同步請求并重新進行數據同步。一種客戶端，所述客戶端包括請求發(fā)送模塊，用于發(fā)送數據同步請求；狀態(tài)碼接收模塊，用于接收狀態(tài)碼；調整模塊，用于減少當前發(fā)送的所述數據同步請求的消息長度，并利用減少消息長度的數據同步請求觸發(fā)請求發(fā)送模塊，請求與服務器重新進行數據同步。一種數據同步的系統(tǒng)，所述系統(tǒng)包括客戶端，用于發(fā)送數據同步請求，并在接收到狀態(tài)碼時，減少所述數據同步請求的消息長度后，再次發(fā)送減少消息長度的數據同步請求并重新進行數據同步；服務器，用于在接收到數據同步請求時，確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度，在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，返回狀態(tài)碼。本發(fā)明實施例的方案中，服務器對返回給客戶端的執(zhí)行狀態(tài)消息的消息長度進行檢測，當確定執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，放棄本次客戶端的同步請求(即不向客戶端返回本次產生的執(zhí)行狀態(tài)消息)，而是通過向客戶端返回狀態(tài)碼，要求客戶端重新發(fā)送消息長度減少的數據同步請求來重新進行同步操作，通過循環(huán)執(zhí)行本發(fā)明實施例的方案，使服務器生成的執(zhí)行狀態(tài)消息的消息長度逐步接近并小于客戶端能夠識別的最大消息長度，直至客戶端與服務器之間數據同步過程完成，避免由于客戶端無法正確識別執(zhí)行狀態(tài)消息而導致同步過程中斷的問題。


圖I為背景技術中SyncML Client和SyncML Server之間進行數據同步的步驟示意圖；圖2為本發(fā)明實施例一中數據同步的方法步驟示意圖；圖3為本發(fā)明實施例二中數據同步的方法步驟示意圖；圖4為本發(fā)明實施例三中數據同步的系統(tǒng)結構示意圖；圖5為本發(fā)明實施例四中服務器的結構示意圖；圖6為本發(fā)明實施例伍中客戶端的結構示意圖。
具體實施例方式為了實現本發(fā)明目的，在本發(fā)明實施例的方案中，服務器主動對返回給客戶端的 執(zhí)行狀態(tài)消息的消息長度進行檢測，當確定執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，放棄本次客戶端的同步請求(即不向客戶端返回本次產生的執(zhí)行狀態(tài)消息)，而是通過向客戶端返回狀態(tài)碼，要求客戶端重新發(fā)送消息長度減少的數據同步請求，由于服務器重新接收到的數據同步請求的消息長度減少，因此重新生成的執(zhí)行狀態(tài)消息的消息長度也會減少，在重新生成的執(zhí)行狀態(tài)消息的消息長度不大于客戶端能夠識別的最大消息長度時，完成本次數據同步操作；否則，重復要求客戶端發(fā)送消息長度不斷減少的數據同步請求，直至最終生成的執(zhí)行狀態(tài)消息的消息長度不大于客戶端能夠識別的最大消息長度。通過本發(fā)明方案，服務器在執(zhí)行狀態(tài)消息不能被客戶端正確識別時，要求客戶端重新調整數據同步請求，直至完成通過過程，克服了現有技術中服務器盲目地向客戶端發(fā)送執(zhí)行狀態(tài)消息，導致客戶端與服務器之間的同步過程可能出現中斷。本發(fā)明各實施例中的方案可以應用于SyncML協(xié)議中，所涉及的服務器可以是SyncML Server,所涉及的客戶端可以是SyncML Client。下面結合說明書附圖對本發(fā)明實施例進行詳細描述。實施例一如圖2所示，為本發(fā)明實施例一中數據同步的方法步驟示意圖，所述方法包括以下步驟步驟201 :服務器接收客戶端發(fā)送的數據初始化請求，所述數據初始化請求中攜帶了 MaxMsgSize 參數。步驟202 :服務器存儲所述MaxMsgSize參數,并返回初始化響應。上述步驟201和步驟202是服務器和客戶端之間進行初始化的過程，是本實施例的優(yōu)選步驟。在本實施例的方案中，服務器和客戶端可以在首次進行數據同步之前進行上述初始化操作，無需在每次數據同步過程中執(zhí)行上述初始化操作。服務器可以通過在上述步驟201和步驟202的初始化過程中確定并記錄所述MaxMsgSize參數,進而確定客戶端能夠識別的最大消息長度，也可以通過其他方式確定客戶端能夠識別的最大消息長度，如客戶端通過其他指令將自身能夠識別的最大消息長度發(fā)送給服務器。步驟203 :服務器接收客戶端發(fā)送的數據同步請求。在本步驟中，服務器接收到的數據同步請求可以是客戶端首次向服務器發(fā)送的數據同步請求，也可以是由于相鄰的前一次數據同步被服務器放棄后，客戶端調整重新調整數據同步請求的消息長度后再次發(fā)送的數據同步請求。所述數據同步請求中包括至少一條操作信息，在本實施例中，可以包括要求刪除數據庫中第I條至第8條記錄的8條刪除操作信息。步驟204 :服務器確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度。假設在步驟203中客戶端發(fā)送的數據同步請求包含8條操作信息，要求刪除除數據庫中第I條至第8條記錄，則在本步驟中，服務器確定生成的執(zhí)行狀態(tài)消息的消息長度為1036字節(jié)。步驟205 :服務器判斷生成的執(zhí)行狀態(tài)消息的消息長度是否大于客戶端能夠識別的最大消息長度，若是，則執(zhí)行步驟206 ;否則，將生成的執(zhí)行狀態(tài)消息返回給客戶端，完成 本次數據同步過程。在本實施例的方案中，服務器在生成執(zhí)行狀態(tài)消息后并不立即向客戶端返回，而是判斷所述執(zhí)行狀態(tài)消息的消息長度是否大于客戶端能夠識別的最大消息長度，也就是判斷客戶端能夠正確識別生成的執(zhí)行狀態(tài)消息。在確定客戶端不能正確識別所述執(zhí)行狀態(tài)消息時，放棄本次數據同步過程，即不向客戶端返回本次生成的執(zhí)行狀態(tài)消息，避免由于客戶端無法正確識別執(zhí)行狀態(tài)消息而導致同步過程中斷的問題。步驟206 :服務器判斷之前連續(xù)返回狀態(tài)碼的次數是否達到設定門限值，若達到，則結束本次數據同步過程；否則，執(zhí)行步驟207。其中，連續(xù)返回狀態(tài)碼中的最后一次返回狀態(tài)碼至本次向客戶端返回狀態(tài)碼之間，服務器沒有向客戶端返回過執(zhí)行狀態(tài)消息。例如，若本次是服務器第15次接收到所述客戶端發(fā)送的數據同步請求，而在第14次至第10次的連續(xù)5次接收到同一客戶端發(fā)送的數據同步請求時都返回了狀態(tài)碼，但在第9次返回的是執(zhí)行狀態(tài)消息，則表示之前連續(xù)返回狀態(tài)碼的次數為5次，第9次的數據同步過程成功完成。若之前連續(xù)返回狀態(tài)碼的次數是否達到設定門限值，則服務器將通知客戶端結束本次數據同步過程，要求客戶端不再針對本次需要同步的事件發(fā)送數據同步請求。若客戶端希望針對其他事件發(fā)起的新的數據同步請求，則客戶端可以針對其他事件再次向服務器發(fā)送新的數據同步請求。步驟206是本發(fā)明實施例的優(yōu)選步驟，通過設定重傳次數的門限值，避免同步過程出現死循環(huán)而無法停止的問題，同時，也避免重傳次數過多導致通信資源的過度浪費的問題。需要說明的是，步驟206中的重傳過程可能是由于服務器生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度而發(fā)生的，也可能是由于網絡環(huán)境較差而發(fā)生的，在本實施例中，可以設定不論何種原因導致服務器判斷之前連續(xù)返回狀態(tài)碼的次數已達到設定門限值時，都要求結束本次數據同步過程；也可以設定以“服務器生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度”這一原因導致服務器判斷之前連續(xù)返回狀態(tài)碼的次數已達到設定門限值時，才要求結束本次數據同步過程。步驟207 :服務器向客戶端返回狀態(tài)碼(Alert Code)，并跳轉至步驟203，等待重新接收客戶端發(fā)送的消息長度減少了的數據同步請求。
所述狀態(tài)碼表示由于服務器生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度，服務器放棄本次客戶端的數據同步請求，服務器將等待客戶端重傳的消息長度減少了的數據同步請求，循環(huán)執(zhí)行上述步驟203 步驟207的操作，直至在步驟205中能夠完成與客戶端之間的數據同步過程，或是在步驟206中確定連續(xù)返回狀態(tài)碼的次數已達到設定門限值而退出數據同步過程。在本步驟中，服務器向客戶端返回狀態(tài)碼后，服務器將在步驟206中涉及的連續(xù)返回狀態(tài)碼的次數基礎上，再增加連續(xù)返回狀態(tài)碼的次數，并利用再次增加的連續(xù)返回狀態(tài)碼的次數作為下一次執(zhí)行步驟206的判斷條件。通過本發(fā)明實施例一的方案，描述了服務器側進行數據同步的過程，由于服務器在生成了執(zhí)行狀態(tài)消息后并不立即向客戶端返回，而是在確定所述執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，放棄本次數據同步過程，要求客戶端調整數據同步請求的消息長度，直至生成的執(zhí)行狀態(tài)消息的消息長度不大于客戶端能夠識別的最大消息長度時才與客戶端完成數據同步過程，避免由于客戶端無法正確識別執(zhí)行狀態(tài)消息而導致同步過程中斷的問題。實施例二本發(fā)明實施例二是從客戶端側來描述本發(fā)明實施例的數據同步方法，本發(fā)明實施例二的方案與實施例一的方案相對應，下面以圖3為例，對本發(fā)明實施例二的方案進行說明。本發(fā)明實施例二的方案包括以下步驟步驟301 :客戶端向服務器發(fā)送數據初始化請求，所述數據初始化請求中攜帶了MaxMsgSize 參數。本步驟與實施例一中的步驟201和步驟202對應，是客戶端和服務器之間的初始化過程，本步驟也是本實施例的優(yōu)選步驟。步驟302 :客戶端向服務器發(fā)送數據同步請求。本步驟與實施例一中的步驟203相對應，客戶端可以在首次與服務器之間進行數據同步時向服務器發(fā)送數據同步請求，也可以是在接收到服務器返回的狀態(tài)碼后，調整相鄰的上一次發(fā)送的數據同步請求的消息長度后，向服務器發(fā)送消息長度減少后的數據同步請求。步驟303 :客戶端判斷服務器返回的是狀態(tài)碼還是執(zhí)行狀態(tài)消息，若返回的是狀態(tài)碼，則執(zhí)行步驟304 ;否則，完成本次數據同步過程。本步驟與實施例一的步驟204 步驟207對應，在服務器確定執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度，即確定客戶端不能正確識別所述執(zhí)行狀態(tài)消息時，向客戶端返回狀態(tài)碼。在本步驟中，若客戶端接收到服務器返回的狀態(tài)碼，表示服務器放棄本次數據同步請求，則客戶端需要重傳數據同步請求；若客戶端接收到服務器返回的執(zhí)行狀態(tài)消息，表 示服務器側已完成本次數據同步過程，客戶端識別接收到的執(zhí)行狀態(tài)消息后，完成本次數據同步過程。步驟304:客戶端減少相鄰的上一次發(fā)送的數據同步請求的消息長度，并跳轉至步驟302，向服務器發(fā)送減少消息長度的數據同步請求。
客戶端去除了 M條刪除操作信息后，在步驟205中發(fā)送的數據同步請求中將攜帶(L-M)條刪除操作信息，請求與服務器重新進行數據同步。由于數據同步請求的消息長度減少了，服務器需要執(zhí)行的刪除操作內容也減少了，因此，生成的執(zhí)行狀態(tài)消息的消息長度相對于上一次也將減少，提高服務器和客戶端之間數據同步成功實現的可能性?？蛻舳巳コ腗條刪除操作信息可以在本次數據同步過程成功執(zhí)行后，再通過攜帶所述M條刪除操作信息的數據同步請求來要求服務器響應相應的操作。假設客戶端發(fā)送給服務器的數據同步請求中可以攜帶L(L為大于I的正整數)條刪除操作信息，本步驟的具體實現方式包括但不先以下兩種方式
方式一客戶端確定每條刪除操作信息的消息長度，并去除消息長度最長的N條刪除操作信息，所述N為大于0且小于L的正整數方式二客戶端去除所述數據同步請求中的M條刪除操作信息，所述M為大于0且小于L的正整數。具體地，客戶端可以按照數據同步請求中攜帶的刪除操作信息的數量來去除其中M條刪除操作信息，也可以按照數據同步請求的消息長度來去除其中M條刪除操作信息，下面分別加以說明I、按照數據同步請求中攜帶的刪除操作信息的數量來去除其中M條刪除操作信
肩、O首先，客戶端預先設定的第一比值范圍，如每次削減8% 12%數目的刪除操作信息。然后，客戶端確定需要去除的M條刪除操作信息，所述M與L的比值在所述第一比值范圍內。例如，在L = 10時，客戶端確定當M = I時，削減的數目為10%，M與L的比值在第一比值范圍內，因此，客戶端去除10條刪除操作信息中的I條刪除操作信息。2、按照數據同步請求的消息長度來去除其中M條刪除操作信息。首先，客戶端預先設定的第二比值范圍，如每次數據同步請求的消息長度削減8% 12%。然后，客戶端確定L條刪除操作信息中，每條刪除操作信息的消息長度。接著，客戶端根據設定的第二比值范圍，確定需要去除的M條刪除操作信息，所述去除的M條刪除操作信息的消息長度與消息長度減少前的數據同步請求的消息長度的比值在所述第二比值范圍內。例如，在攜帶的刪除操作信息為L條時，數據同步請求的消息長度為a，則按照每條刪除操作信息的消息長度，從L條刪除操作信息中選擇M條刪除操作信息，要求M條刪除操作信息的消息長度為b，且b與a的比值在第二比值范圍內。需要說明的是，無論通過上述何種方式去除數據同步請求中的刪除操作信息后，若去除刪除操作信息的數據同步請求發(fā)送到服務器，且客戶端接收到服務器返回的執(zhí)行狀態(tài)消息(表示客戶端和服務器完成針對去除刪除操作信息的數據同步請求的數據同步操作)后，客戶端去除的刪除操作信息對應的刪除操作仍需要與服務器進行同步，因此，客戶端向服務器發(fā)送包含去除的刪除操作信息的數據同步請求，針對包含去除的刪除操作信息的數據同步請求，可以重新執(zhí)行本實施例二的方案，進行同步操作。通過本發(fā)明實施例二的方案，描述了客戶端側進行數據同步的過程，由于客戶端在接收到服務器返回的狀態(tài)碼時確定服務器由于執(zhí)行狀態(tài)消息的消息長度過長而放棄本次數據同步過程，因此，客戶端將減少數據同步請求的消息長度后重新發(fā)送給服務器，要求服務器按照再次接收到的數據同步請求進行數據同步過程，如此循環(huán)，直至客戶端與服務器之間數據同步過程完成，避免由于客戶端無法正確識別執(zhí)行狀態(tài)消息而導致同步過程中斷的問題。進一步地，本發(fā)明實施例二還提供了多種客戶端減少數據同步請求的消息長度的方式，使服務器生成的執(zhí)行狀態(tài)消息的消息長度逐步接近并小于客戶端能夠識別的最大消息長度，在確保同步過程正確執(zhí)行的情況下，使服務器能夠同時響應的操作達到最大化，減少客戶端和服務器之間的同步過程，提高數據同步效率。實施例三
本發(fā)明實施例三還提供一種數據同步的系統(tǒng)，所述系統(tǒng)包括客戶端11和服務器12，其中客戶端11用于發(fā)送數據同步請求，并在接收到狀態(tài)碼時，減少所述數據同步請求的消息長度后，再次發(fā)送減少消息長度的數據同步請求并重新進行數據同步；服務器12用于在接收到數據同步請求時，確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度，在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，返回狀態(tài)碼。服務器12還用于判斷之前連續(xù)返回狀態(tài)碼的次數是否達到設定門限值，在沒有達到門限值時，向客戶端返回狀態(tài)碼，并增加連續(xù)返回狀態(tài)碼的次數。其中，連續(xù)返回狀態(tài)碼中的最后一次返回狀態(tài)碼至本次向客戶端返回狀態(tài)碼之間，服務器沒有向客戶端返回過執(zhí)行狀態(tài)消息；服務器12還用于與客戶端11進行初始化操作，存儲客戶端11發(fā)送的數據初始化請求中攜帶的客戶端能夠識別的最大消息長度。本實施例中的客戶端12可以按照實施例二中的多種方式來減少數據同步請求的消息長度。具體的，本實施例三中數據同步的系統(tǒng)的客戶端11和服務器12的交互過程如圖4所示第一步，客戶端11和服務器12之間進行初始化操作，客戶端11向服務器12發(fā)送數據初始化(Initialization Package)請求,在 Initialization Package 請求中攜帶MaxMsgSize參數，用于表示客戶端11能夠識別服務器12返回消息的最大消息長度；服務器12存儲所述MaxMsgSize參數，并在完成初始化操作后，向客戶端11返回初始化響應。第二步，在需要進行數據同步時，客戶端11向服務器12發(fā)送數據同步(SyncPackage)請求,所述數據同步請求的消息長度不大于MaxMsgSize參數所表示的最大消息長度。第三步，由服務器12執(zhí)行客戶端11請求的操作，并生成執(zhí)行狀態(tài)消息(Statuspackage)。若生成的執(zhí)行狀態(tài)消息的消息長度大于MaxMsgSize參數所表不的最大消息長度，則服務器12向客戶端11返回狀態(tài)碼(Alert Code)，通知客戶端11當前生成的執(zhí)行狀態(tài)消息的消息長度大于MaxMsgSize參數所表不的最大消息長度；若生成的執(zhí)行狀態(tài)消息的消息長度不大于MaxMsgSize參數所表示的最大消息長度，則服務器12將生成的執(zhí)行狀態(tài)信息返回給客戶端11，完成本次數據同步過程。第四步，客戶端11在接收到狀態(tài)碼時，減少數據同步請求的消息長度后，再次發(fā)送減少消息長度的數據同步請求并重新進行數據同步，并跳轉至第三步。
實施例四本發(fā)明實施例四還提供一種服務器，如圖5所示，包括請求接收模塊21、判斷模塊22和返回模塊23，其中請求接收模塊21用于接收數據同步請求；判斷模塊22用于判斷響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度是否大于客戶端能夠識別的最大消息長度；返回模塊23用于在判斷結果為生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，向客戶端返回狀態(tài)碼，指示客戶端減少所述數據同步請求的消息長度后，向服務器發(fā)送減少消息長度的數據同步請求并重新進行數據同步。所述服務器還包括計數模塊24，用于記錄之前連續(xù)返回狀態(tài)碼的次數，其中，連續(xù)返回狀態(tài)碼中的最后一次返回狀態(tài)碼至本次向客戶端返回狀態(tài)碼之間，服務器沒有向客戶端返回過執(zhí)行狀態(tài)消息。所述判斷模塊22還用于判斷之前連續(xù)返回狀態(tài)碼的次數是否達到設定門限值，在判斷結果為沒有達到設定門限值時，觸發(fā)返回模塊23。返回模塊23在向客戶端返回狀態(tài)碼后，觸發(fā)計數模塊24增加連續(xù)返回狀態(tài)碼的次數。所述服務器還包括初始化模塊25和存儲模塊26，其中，初始化模塊25用于接收客戶端發(fā)送的數據初始化請求，所述數據初始化請求中攜帶了客戶端能夠識別的最大消息長度，并返回初始化響應；存儲模塊26存儲所述客戶端能夠識別的最大消息長度。本發(fā)明實施四中還包括能夠實現實施例一各步驟的功能模塊，此處不再贅述。實施例五本發(fā)明實施例五還提供一種客戶端，如圖6所示，包括請求發(fā)送模塊31、狀態(tài)碼接收模塊32和調整模塊33，其中請求發(fā)送模塊31用于發(fā)送數據同步請求；狀態(tài)碼接收模塊32用于在發(fā)送數據同步請求后，接收返回的狀態(tài)碼；調整模塊33用于減少當前發(fā)送的所述數據同步請求的消息長度，并利用減少消息長度的數據同步請求觸發(fā)請求發(fā)送模塊，請求與服務器重新進行數據同步。所述調整模塊33可以按照實施例二中的多種方式來減少數據同步請求的消息長度。本發(fā)明實施五中還包括能夠實現實施例二各步驟的功能模塊，此處不再贅述。本領域內的技術人員應明白，本申請的實施例可提供為方法、系統(tǒng)、或計算機程序產品。因此，本申請可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產品的形式。本申請是參照根據本申請實施例的方法、設備(系統(tǒng))、和計算機程序產品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理設備的處理器執(zhí)行的指令產生用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。這些計算機程序指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的制造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。這些計算機程序指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執(zhí)行一系列操作步驟以產生計算機實現的處理，從而在計算機或 其他可編程設備上執(zhí)行的指令提供用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。盡管已描述了本申請的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例做出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本申請范圍的所有變更和修改。顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1.一種數據同步的方法，其特征在于，所述方法包括 服務器在接收到客戶端發(fā)送的數據同步請求時，確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度； 服務器在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，向客戶端返回狀態(tài)碼，指示客戶端減少所述數據同步請求的消息長度后，向服務器發(fā)送減少消息長度的數據同步請求并重新進行數據同步。
2.如權利要求I所述的方法，其特征在于，服務器在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度之后，且向客戶端返回狀態(tài)碼之前，所述方法還包括 服務器確定之前連續(xù)返回狀態(tài)碼的次數未達到設定門限值； 服務器本次在向客戶端返回狀態(tài)碼之后，所述方法還包括 服務器增加連續(xù)返回狀態(tài)碼的次數。
3.如權利要求I或2所述的方法，其特征在于，服務器接收數據同步請求之前，所述方法還包括 服務器接收客戶端發(fā)送的數據初始化請求，所述數據初始化請求中攜帶了客戶端能夠識別的最大消息長度； 服務器存儲所述客戶端能夠識別的最大消息長度，并返回初始化響應。
4.一種數據同步的方法，其特征在于，所述方法包括 客戶端向服務器發(fā)送數據同步請求； 客戶端在接收到服務器返回的狀態(tài)碼時，減少所述數據同步請求的消息長度，并向服務器發(fā)送減少消息長度的數據同步請求，請求與服務器重新進行數據同步。
5.如權利要求4所述的方法，其特征在于，所述數據同步請求中攜帶L條刪除操作信息； 客戶端減少所述數據同步請求的消息長度，具體包括 客戶端去除數據同步請求中的M條刪除操作信息； 所述L為大于I的正整數，所述M為大于O且小于L的正整數。
6.如權利要求5所述的方法，其特征在于，客戶端確定需要去除的M條刪除操作信息，具體包括 客戶端根據設定的第一比值范圍，確定需要去除的M條刪除操作信息，所述M與L的比值在所述第一比值范圍內；或者 客戶端確定每條刪除操作信息的消息長度，根據設定的第二比值范圍，確定需要去除的M條刪除操作信息，所述去除的M條刪除操作信息的消息長度與消息長度減少前的數據同步請求的消息長度的比值在所述第二比值范圍內。
7.如權利要求4所述的方法，其特征在于，所述數據同步請求中攜帶L條刪除操作信息； 客戶端減少所述數據同步請求的消息長度，具體包括 客戶端確定每條刪除操作信息的消息長度，并去除消息長度最長的N條刪除操作信息，所述N為大于O且小于L的正整數。
8.如權利要求5或7所述的方法，其特征在于，客戶端向服務器發(fā)送減少消息長度的數據同步請求之后，所述方法還包括 客戶端在接收到服務器返回的執(zhí)行狀態(tài)消息時，向服務器發(fā)送包含去除的刪除操作信息的數據同步請求。
9.一種服務器，其特征在于，所述服務器包括 請求接收模塊，用于接收數據同步請求； 判斷模塊，用于判斷響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度是否大于客戶端能夠識別的最大消息長度； 返回模塊，用于在判斷結果為生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，向客戶端返回狀態(tài)碼，指示客戶端減少所述數據同步請求的消息長度后，向服務器發(fā)送減少消息長度的數據同步請求并重新進行數據同步。
10.一種客戶端，其特征在于，所述客戶端包括 請求發(fā)送模塊，用于發(fā)送數據同步請求； 狀態(tài)碼接收模塊，用于接收狀態(tài)碼； 調整模塊，用于減少當前發(fā)送的所述數據同步請求的消息長度，并利用減少消息長度的數據同步請求觸發(fā)請求發(fā)送模塊，請求與服務器重新進行數據同步。
11.一種數據同步的系統(tǒng)，其特征在于，所述系統(tǒng)包括 客戶端，用于發(fā)送數據同步請求，并在接收到狀態(tài)碼時，減少所述數據同步請求的消息長度后，再次發(fā)送減少消息長度的數據同步請求并重新進行數據同步； 服務器，用于在接收到數據同步請求時，確定在響應所述數據同步請求中的操作信息后生成的執(zhí)行狀態(tài)消息的消息長度，在確定生成的執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，返回狀態(tài)碼。
全文摘要
本發(fā)明公開了一種數據同步的方法、系統(tǒng)及設備，主要內容包括服務器對返回給客戶端的執(zhí)行狀態(tài)消息的消息長度進行檢測，當確定執(zhí)行狀態(tài)消息的消息長度大于客戶端能夠識別的最大消息長度時，放棄本次客戶端的同步請求(即不向客戶端返回本次產生的執(zhí)行狀態(tài)消息)，而是通過向客戶端返回狀態(tài)碼，要求客戶端重新發(fā)送消息長度減少的數據同步請求來重新進行同步操作，通過循環(huán)執(zhí)行本發(fā)明實施例的方案，使服務器生成的執(zhí)行狀態(tài)消息的消息長度逐步接近并小于客戶端能夠識別的最大消息長度，直至客戶端與服務器之間數據同步過程完成，避免由于客戶端無法正確識別執(zhí)行狀態(tài)消息而導致同步過程中斷的問題。
文檔編號H04L29/06GK102684865SQ201110053760
公開日2012年9月19日 申請日期2011年3月7日 優(yōu)先權日2011年3月7日
發(fā)明者俞小良, 劉霖 申請人:中國移動通信有限公司