CN101562516A - 数据同步方法、客户端、服务器及系统 - Google Patents

Abstract

本发明实施例公开一种数据同步方法、客户端、服务器及系统。所述数据同步方法，包括：在同步阶段中，将报文进行压缩；将所述压缩后的报文发送到对端设备。相应的，本发明实施例提供一种客户端，包括：压缩单元，用于将报文进行压缩处理；发送单元，用于将所述压缩单元在同步阶段压缩后的报文向服务器发送。本发明实施例还提供一种服务器及系统。本发明实施例提供的技术方案能够提高数据同步的传输效率。

Description

数据同步方法、客户端、服务器及系统

技术领域

本发明涉及通信技术领域，具体涉及一种数据同步方法、客户端、服务器及系统。

背景技术

目前的数据同步技术中，OMA(Open Mobile Alliance，开放移动联盟)定义了SyncML(Synchronization Markup Language，同步标记语言)规范。SyncML的典型应用是实现客户端(例如移动设备)与服务器之间的数据同步。

请参阅图1，是现有技术的数据同步方法流程图，包括：

101、客户端向服务器发起同步初始化请求报文，请求服务器进行认证等相关处理；

该同步初始化请求报文中可以包括认证信息(其中包含用户名和密码)、客户端的设备能力信息、同步的指定路径、客户端支持的最大消息字节数MaxMsgSize和最大数据字节数MaxObjSize、同步类型(如客户端刷新同步、双向同步等)。

同步初始化请求报文一般采用XML(The Extensible Markup Language，可扩展标识语言)或WBXML(WAP Binary XML，无线应用协议二进制可扩展标识语言)格式，WBXML格式只是对XML报文中的SyncML标签进行压缩。

102、服务器接收到同步初始化请求报文后，执行初始化操作，并返回初始化请求响应报文，包括认证结果、服务器端的能力信息等，由客户端根据服务器的能力信息执行初始化操作；

该步骤中同步初始化请求响应报文也是采用XML或WBXML格式。

概括而言，上述步骤101-102为数据同步方法流程中的初始化阶段，其主要完成客户端与服务器间的相互认证、双方设备能力的协商(例如支持的同步类型、数据库等)，还可以完成待同步数据的协商。

103、客户端发送同步请求报文到服务器，该同步请求报文中包含待同步数据；

所包含的待同步数据采用明文发送，并且待同步数据一般采用XML或WBXML格式，WBXML格式只是对XML报文中的SyncML标签进行压缩。

104、服务器接收到同步请求报文后，进行数据同步处理，然后向客户端发送同步请求响应报文，该同步请求响应报文中包含服务器的待同步数据；

同步请求响应报文也是采用XML或WBXML格式。客户端接收到同步请求响应报文后，进行同步处理。之后，如果还有未处理的待同步数据，则重复执行步骤103和步骤104，直到所有待同步数据都处理完毕。

概括而言，上述步骤103-104为数据同步方法流程中的同步阶段，其主要完成客户端和服务器的之间的数据交换以实现数据同步。

需要说明的是，上述是以同步类型为双向同步举例说明(即客户端和服务器都将本端的待同步数据发送到对端进行同步处理)。如果是单向同步，则可以只存在步骤103或104。如果单向同步的类型为“客户端刷新同步”，则同步过程具体为：客户端向服务器传输待同步数据，服务器首先删除原有数据，并将从客户端接收的待同步数据添加到数据库中，实现客户端和服务器的数据同步。

105、客户端向服务器发送确认同步完成请求报文，所述确认同步完成请求报文也是采用XML或WBXML格式；

106、服务器确认完成后，向客户端返回确认同步完成请求响应报文，所述确认同步完成请求响应报文也是采用XML或WBXML格式。

概括而言，上述步骤105-106为流程中的同步完成阶段，其主要用于客户端和服务器的之间相互确认完成信息。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

现有技术数据同步方法中，客户端与服务器在数据同步过程中，都是采用XML或WBXML格式传送同步数据，并且WBXML格式只能对XML报文中的SyncML标签进行压缩，却不能对同步数据本身进行压缩，因此传输数据量很大、传输效率不高。

发明内容

本发明实施例要解决的技术问题是提供一种数据同步方法、客户端、服务器及系统，能够提高数据同步的传输效率。

为解决上述技术问题，本发明所提供的实施例是通过以下技术方案实现：

本发明实施例提供一种数据同步方法，包括：在同步阶段中，将报文进行压缩；将所述压缩后的报文发送到对端设备。

本发明实施例提供一种客户端，包括：压缩单元，用于将报文进行压缩处理；发送单元，用于将所述压缩单元在同步阶段压缩后的报文发送到服务器。

本发明实施例提供一种服务器，包括：压缩单元，用于将报文进行压缩处理；发送单元，用于将所述压缩单元在同步阶段压缩后的报文发送到客户端。

本发明实施例提供一种数据同步系统，包括：第一设备，用于在同步阶段中将报文进行压缩，将所述压缩后的报文向第二设备发送；第二设备，用于对所述第一设备发送的报文解压后进行数据同步处理。

上述技术方案可以看出，本发明实施例技术方案中，客户端与服务器在数据同步过程中，待同步数据是采用压缩方式进行发送，因此与现有技术采用XML或WBXML格式进行发送相比，传输数据量可以很大，传输效率更高。

附图说明

图1是现有技术的数据同步方法流程图；

图2是本发明实施例一提供的一种数据同步方法流程图；

图3是本发明实施例二提供的一种数据同步方法流程图；

图4是本发明实施例三中提供的一种数据元素的路径示意图；

图5是本发明实施例提供的一种客户端的结构示意图；

图6是本发明实施例提供的一种服务器结构示意图；

图7是本发明实施例提供的一种数据同步系统结构示意图。

具体实施方式

本发明实施例提供了一种数据同步方法，用于提高数据同步的传输效率。

请参阅图2，是本发明实施例一数据同步方法流程图，包括：

201、在同步阶段中，将报文进行压缩；

202、将所述压缩后的报文发送到对端设备。

将所述压缩后的报文发送到对端设备，以供对端设备根据解压后进行数据同步处理。

所述将报文进行压缩可以是对整个报文进行压缩，也可以是对报文中的待同步数据进行压缩。进行压缩的算法，可以为任何算法，如GZIP或ZIP等或其它简单高效的压缩算法。

进一步的，还包括接收压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文；报文解压后进行数据同步处理。

进一步的，在同步初始化阶段和/或同步完成阶段，将报文进行压缩后传输到对端设备，接收对端设备发送的压缩后的报文并解压后进行处理。

可以发现，实施例一技术方案在数据同步方法中采用压缩方式进行报文传输，因此提高了传输效率。

以下进一步介绍本发明实施例技术方案。

请参阅图3，是本发明实施例二数据同步方法流程图。

实施例二中，服务器要求来自客户端的报文是加密的，且客户端已预装或从网络侧下载服务器的证书，该证书为非对称密钥，其中的公钥用于客户端加密，其中的私钥用于服务器解密，而服务器认为请求接入的客户端是可信的，不要求客户端的证书。

图3中包括：

301、客户端生成会话密钥，并进行加密；

客户端确认自身已安装服务器的证书，且该证书处于有效期内后，则生成用于对报文进行加密的会话密钥，使用服务器证书的公钥加密已生成的会话密钥，使用该会话密钥加密待传送的初始化请求报文，然后再使用请求消息中的指定格式对加密后的请求报文进行压缩。上述客户端自身生成用于加密用户数据的会话密钥为对称密钥，其算法可为任何算法，例如AES(Advanced Encryption Standard，高级加密标准)加密算法、基于RC4的加密算法或者其他对称加密算法等，其能够被大部分终端(包括但不限于手机、PDA(Personal Digital Assistant，个人数字助理)、智能手机、PC客户端等)支持。而且，由于加密算法实现的简单性，能够很好地在仅有有限的内存和处理能力的终端上运行。同时，加密算法的类型可扩展，密钥的长度可以设置，可针对不同的应用场景提供不同的安全级别。

而用于对加密后的报文进行压缩的算法，可以为任何算法，如GZIP或ZIP等或其它简单高效的压缩算法，其能够被大部分终端(包括但不限于手机、PDA、智能手机、PC客户端等)支持。而且，由于压缩算法实现的简单性，能够很好地在仅有有限的内存和处理能力的终端上运行。

需说明的是，也可以不对会话密钥进行加密，而直接将会话密钥发送给服务器。

本发明实施例中，客户端可使用服务器证书中的公钥将会话密钥加密后再发送给服务器，而服务器则使用自身的私钥解密后，才能获取客户端生成的会话密钥。因此通过使用证书机制，保证了客户端与服务器间是可信任的，解决了信任问题，同时，利用非对称加密技术很好地解决了密钥的安全传输问题，使得每次同步操作均可以使用不同的会话密钥，极大地提高了密钥的安全性，同时也极大保证了用户数据的安全性。

302、客户端向服务器发送同步初始化请求报文，该报文为压缩格式的加密后的报文；

客户端生成同步初始化请求报文，对报文进行加密，并采用上述提到的压缩算法进行压缩。客户端在原有同步协议要求的基础上，还在同步初始化请求报文中设置了请求加密标识。上述请求加密标识以参数的形式承载在传输协议的报文中，且该标识中表明会话公钥所需的算法类型及密钥长度以及加密后的会话私钥。

303、服务器对接收的报文进行解压缩和解密，生成初始化请求响应报文，对该报文进行加密和压缩；

服务器接收到来自客户端的报文，判断出报文中有加密请求标识后，使用自身的私钥对会话标识进行解密，并根据自身的配置判断自身是否支持该会话密钥，即是否支持该会话密钥所要求的算法类型以及密钥长度等。

如果服务器判断出支持会话密钥解密，则进一步执行如下操作：

1)对报文解压缩；

2)对解压报文使用会话密钥解密；

服务器使用接收到的会话密钥对来自客户端的报文解密，获得用于初始化的用户数据，并应用解密后的用户数据进行初始化操作及后续处理。

3)生成初始化请求响应报文；

生成表示成功的初始化请求响应报文，该报文中包含服务器成功接收会话密钥的信息及自身的设备能力信息等。

4)对初始化请求响应报文使用会话密钥加密；

5)对加密后的初始化请求响应报文进行压缩。

如果服务器判断出不支持会话密钥解密，向客户端返回包含失败原因的初始化请求响应报文，结束本流程。该失败原因中指明服务器不支持该会话密钥，即不支持该会话密钥所要求的算法类型和/或密钥长度，同时，还可进一步指明自身所要求的算法类型和/或密钥长度，则客户端可以根据初始化请求响应报文内容，重新采用服务器支持的会话密钥进行加密处理。

需说明的是，在本步骤中，如果服务器判断出来自客户端的初始化请求报文中没有加密请求标识时，直接向客户端返回包含失败原因的初始化请求响应报文，该失败原因为服务器要求加密而客户端没有发送加密请求标识，该初始化请求响应报文中还可进一步包含服务器支持的算法类型和密钥长度等信息。

如果客户端接收到来自服务器的初始化请求响应报文为表示失败时，则判断自身是否具有克服失败原因所需的条件，如果是，则重新向服务器发送压缩格式的加密后的同步初始化请求报文，否则，终止向服务器发送同步初始化请求报文，结束流程。

304、服务器向客户端返回初始化请求响应报文，该报文为压缩格式的加密后的报文；

305、客户端对接收的报文进行解压缩和解密，执行初始化操作；

客户端接收到上述所述初始化请求响应报文后，进行以下操作：

1)对报文解压缩；

2)对解压报文使用会话密钥解密；

使用自身生成的会话密钥进行解密，获得服务器的设备能力信息，然后根据服务器的设备能力信息继续执行初始化操作。

至此，数据的同步初始化阶段结束。

306、客户端向服务器发送含有客户端的待同步数据的同步请求报文，该报文为压缩格式的加密后的报文；

客户端生成同步请求报文，该同步请求报文中包含客户端的待同步数据，然后客户端使用自身生成的会话密钥对该报文进行加密，然后将报文采用上述提到的压缩算法进行压缩，再将压缩格式的加密后的报文发送给服务器。

307、服务器对接收的报文进行解压缩和解密，进行数据同步处理，生成同步请求响应报文，对该报文进行加密和压缩；

服务器接收到来自客户端的报文，执行如下操作：

1)对报文解压缩；

2)对解压报文使用会话密钥解密；

服务器使用会话密钥对来自客户端的报文进行解密，获得待同步数据，然后进行数据同步处理。

3)生成同步请求响应报文；

如果数据同步类型为双向同步类型，则服务器会将本端的待同步数据发送给客户端进行同步。此时，服务器生成同步请求响应报文，同步请求响应报文中包含服务器的待同步数据。

4)对同步请求响应报文使用会话密钥加密；

5)对加密后的同步请求响应报文进行压缩。

308、服务器向客户端返回含有服务器的待同步数据的同步请求响应报文，该报文为压缩格式的加密后的报文；

309、客户端对接收的报文进行解压缩和解密，进行数据同步处理；

客户端接收到来自服务器的报文，执行如下操作：

1)对报文解压缩；

2)对解压报文使用会话密钥解密；

客户端使用会话密钥对来自服务器的报文进行解密，获得待同步数据，然后进行数据同步处理。

如果还有待同步数据，则重复执行步骤306-309，直到所有待同步数据全部处理完毕为止，同步阶段结束。

310、客户端向服务器发送确认同步完成请求报文，该报文为压缩格式的加密后的报文；

311、服务器对接收的报文进行解压缩和解密，生成确认同步完成请求响应报文，对该报文进行加密和压缩；

服务器接收到来自客户端的报文，执行如下操作：

1)对报文解压缩；

2)对解压报文使用会话密钥解密；

服务器使用会话密钥对来自客户端的报文进行解密，获得客户端的确认同步完成请求报文的内容。

3)生成确认同步完成请求响应报文；

4)对确认同步完成请求响应报文使用会话密钥加密；

5)对加密后的确认同步完成请求响应报文进行压缩。

312、服务器向客户端返回确认同步完成请求响应报文，该报文为压缩格式的加密后的报文。

服务器确认同步完成后，向客户端返回确认同步完成请求响应报文，并由客户端接收后进行解压缩和解密。

至此，同步数据传输完成。

需要说明的是，本实施例二中，客户端也可以不通过预装或下载而获取服务器端的证书，而是在发送同步初始化请求报文之前，直接向服务器请求发送服务器证书信息。当然，服务器也可以认为客户端是不可信的，而要求客户端的证书，此时，会话密钥也可以是非对称密钥。

还需要说明的是，服务器给客户端返回的响应中的状态信息以状态码的方式进行标识，具体某一状态码代表哪个信息可在实际应用中根据需要指定，在此不做限制。以上实施例中的密钥所采用的算法类型，可为现有的任一种对称算法类型。

以下进一步对本发明实施中的请求报文和响应报文的格式进行举例说明。

客户端的请求报文举例：

POST./servlet/syncit HTTP/1.1

Host：sync.huawei.com

Content-Type：application/vnd.syncml+xml；charset＝″utf-8″；表示采用的类型格式

x-session-encrypt-key：c2FmYXM0MzIz

x-session-encrypt-method：Algorithm＝″rsa-1_5″；KeyAlgorithm＝″aes″；KeyLength＝″128″；这部分表示加密的内容

Content-Encoding：gzip；表示采用gzip压缩算法

Content-Length：1023

Accept：application/vnd.syncml+xml

--HTTP body，包含使用会话密钥加密并使用gzip压缩后的SyncML报文信息--

服务器的响应报文举例：

HTTP/1.1 200 OK

Content-Type：application/vnd.syncml+xml；charset＝″utf-8″；表示采用的类型格式

Content-Encoding：gzip；表示采用gzip压缩算法

Content-Length：2106

--HTTP body，包含使用会话密钥加密并使用gzip压缩后的SyncML报文信息--

其中，上述报文中HTTP头字段说明请参见以下表1：

HTTP头	取值	说明
			Content-Type	application/vnd.syncml+xml；charset＝″utf-8″	HTTP1.1标准参数，表示SyncML报文格式。
x-session-encrypt-key	Base64(非对称可逆加密(待加密的客户端同步会话密钥，服务器公钥)	扩展参数，表示客户端生成的本次同步会话密钥(使用服务器的公钥进行了非对称可逆加密)。
			x-session-encrypt-method	非对称加密算法：Algorithm＝″rsa-1_5″；对称加密算法：KeyAlgorithm＝″aes″；KeyLength＝″128″	扩展参数，表示会话私钥加密所使用非对称可逆加密算法和会话私钥本身对应的对称可逆加密算法及密钥长度。
Content-Encoding	gzip，zip，或其它加密格式	HTTP1.1标准参数，表示SyncML加密报文压缩格式。

表1

实施例二技术方案具有以下效果：

1)现有技术方案由于采用明文传送报文，包括初始化阶段、同步阶段、同步完成阶段的数据都是明文发送，因此容易被窃取、存在安全隐患；而本发明实施例技术方案在整个过程中都是采用加密方法进行传输，因此提高了安全性；

2)现有技术方案由于采用XML或WBXML格式传送同步数据，并且WBXML格式只能对XML报文中的SyncML标签进行压缩，却不能对同步数据本身进行压缩，因此传输数据量很大、传输效率不高，另外客户端程序一般运行在手机终端设备上，采用WBXML编解码往往不能获取到较多的CPU和内存资源，因此客户端程序在处理WBXML编解码时效率不高；本发明实施例技术方案是省略了客户端进行WBXML编解码的处理步骤，将所有传输报文都进行压缩处理(而不仅仅是压缩SyncML标签)，因此提高了传输效率，并且不需要处理WBXML编解码，也提高了客户端的处理性能。以GZIP压缩为例，其传输内容比采用WBXML编解码可以减少70％以上的传输流量。

以下介绍本发明实施例三数据同步方法。

实施例三通过定义客户端与服务器之间的路径分隔符协商方法，避免当客户端支持的路径分隔(如“/”)与服务器端发送的路径分隔符(如“\”)不同时所造成客户端与服务器之间数据同步异常或失败的问题。

实施例三与实施例二的步骤基本相同，只是在初始化阶段处理过程有些变化。

实施例三在客户端向服务器发送的初始化请求报文中，在其中的设备能力信息DevInfo中增加一个元素<！ELEMENT PathSeparatorType(#PCDATA)>，用于表示客户端能够处理的路径分隔符(如unix操作系统路径分隔符“/”或windows操作系统路径分隔符“\”等)，即要求服务器返回的响应消息中所有的路径分隔符都要符合PathSeparatorType定义的值。

另外，也可以在服务器发送给客户端的初始化请求响应报文中，在其中的设备能力信息DevInfo中增加一个元素<！ELEMENT PathSeparatorType(#PCDATA)>，用于表示服务器能够处理的路径分隔符(如unix操作系统路径分隔符“/”或windows操作系统路径分隔符“\”等)，即要求客户端返回的响应消息中所有的路径分隔符都要符合PathSeparatorType定义的值。

如果客户端和服务器双方都支持多个路径分隔符，则依照其顺序来表征其优先级。比如“/”“\”，则表明优先使用“/”作为其路径分隔符。

另外，还可以在DevInfo中增加一个元素<！ELEMENT PathNameType(#PCDATA)>，用于表明双方的路径中使用的是数据元素的名称或是数据元素的标识ID。数据元素的ID可以是LUID(Local Unique identifier)或GUID(GlobalUnique Identifier)，或是两者的结合。如图4，为本发明实施例三中路径的示意图。

如图4所示，对于数据元素M1，如果分隔符是“/”，路径中使用数据元素的UID(Unique Identifier)，则M1的路径为：./Macy/02/08；而如果分隔符是“\”，路径中使用数据元素的名称，则M1的路径为：.\Macy\MP3\M1.这样在Device Info里的信息就有利于双方理解对方的数据元素的路径。

以下为本发明实施例修订后的DevInf举例说明：

<DevInf xmlns＝′syncml:devinf′>

  <VerDTD>1.1</VerDTD>

  <Man>huawei</Man>

  <Mod>636</Mod>

  <OEM>huawei</OEM>

  <FwV>2.0</FwV>

  <SwV>2.0</SwV>

  <HwV>1.22</HwV>

  <DevID>542345234</DevID>

  <DevTyp>phone</DevTyp>

  <PathNameType>LUID</PathNameType>；表示使用LUID

  <PathSeparatorType>”/”</PathType>；表示路径分隔符协商

  <UTC/>

  <SupportLargeObjs/>

  <SupportNumberOfChanges/>

</DevInf>

可以发现，本发明实施例通过在现有同步协议中，增加一个DevInf的子元素(如PathTyp)来描述客户端或服务器能够处理的路径分隔符(如unix操作系统路径分隔符“/”或windows操作系统路径分隔符“\”等)，使得对端设备根据该信息构造响应消息，避免对端设备返回的响应消息中包含的路径分隔符与本端支持的不同而导致的同步异常或失败问题。

以下介绍本发明实施例四数据同步方法。

实施例四主要通过设置客户端支持的一个消息中包含命令的最大个数信息并告知服务器，避免服务器下发的一个消息中包含的命令个数超过客户端处理能力而导致的失败问题。

实施例四与实施例二的步骤基本相同，只是在初始化阶段处理过程有些变化。

实施例四在客户端向服务器发送的初始化请求报文中，在其中的设备能力信息DevInfo中增加一个元素<！ELEMENT MaxCmdCnt(#PCDATA)>，用于表示客户端能够处理的一个消息中命令的最大个数，即要求服务器返回的响应消息中所包含的命令个数不能超过MaxCmdCnt定义的值。

以下为本发明实施例修订后的DevInf举例说明：

<DevInf xmlns＝′syncml:devinf′>

  <VerDTD>1.1</VerDTD>

  <Man>huawei</Man>

  <Mod>636</Mod>

  <OEM>huawei</OEM>

  <FwV>2.0</FwV>

  <SwV>2.0</SwV>

  <HwV>1.22</HwV>

  <DevID>542345234</DevID>

  <DevTyp>phone</DevTyp>

  <MaxCmdCnt>100</MaxCmdCnt>；客户端能够处理的一个消息中命令的最大个数

  <UTC/>

  <SupportLargeObjs/>

  <SupportNumberOfChanges/>

</DevInf>

可以发现，本发明实施例通过增加一个DevInf的子元素(如MaxCmdCnt)来描述客户端支持的一个消息中包含命令的最大个数信息。服务器根据该信息构造响应消息，避免一个消息中包含的命令个数超过该元素指定值而导致的客户端同步失败问题。

以下介绍本发明实施例五数据同步方法。

实施例五通过改进现有的客户端刷新同步处理流程，使得同步失败时，客户端和服务器回退到同步前的状态，避免数据丢失。

实施例四与实施例二的步骤基本相同，只是在数据同步阶段，如果同步类型为客户端刷新同步时，处理流程有些变化。

实施例四中，如果同步初始化过程中协商的同步类型为客户端刷新同步，则客户端向服务器传输包含待同步数据的报文，服务器首先将原有数据标记为软删除状态但并不直接删除(在一次处理流程中只触发一次)，并将接收后进行解压缩和解密得到的客户端的待同步数据添加到服务器数据库中。服务器重复上述过程，直到客户端所有数据传输完毕。此时，服务器增加对同步结果的检查，如果同步成功则删除标记为软删除状态的数据，结束流程；否则还原本次同步过程中标记为软删除状态的数据，并删除本次同步过程中添加的客户端传输的数据。

可以发现，本发明实施例通过改进现有的客户端刷新同步处理流程，在同步结束时增加一个服务器的处理流程来保证数据安全性，即服务器检查本次同步结果，如果失败则还原本次同步时标记为软删除状态的原有数据，并删除本次同步添加的客户端传输数据，使得客户端和服务器回退到同步前的状态，避免数据丢失。

需要说明的是，上述实施例三、四、五方案是从不同角度对现有技术方案进行改进，还可以将实施例三、四、五方案的内容综合，得到另外一个方案。

还需要说明的是，上述实施例都是以加密处理后进行压缩举例说明，也可以是先压缩再加密，其原理是一样的。另外，所述压缩可以是在承载层或协议层对报文进行压缩。

上述内容详细的介绍了本发明实施例数据同步方法，相应的，本发明实施例提供一种客户端、服务器和系统。

请参阅图5，是本发明实施例客户端结构示意图。

如图5所示，客户端50包括：压缩单元502、发送单元503。

压缩单元502，用于将报文进行压缩处理。

发送单元503，用于将所述压缩单元502在同步阶段压缩后的报文向服务器发送，以供服务器根据解压后进行数据同步处理。所述压缩单元502采用ZIP/GZIP算法将报文进行压缩。所述压缩单元502是将报文中的待同步数据进行压缩。

客户端50进一步包括：接收单元504、解压缩单元505、同步单元506。

接收单元504，用于接收服务器发送的接收压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文。

解压缩单元505，用于将所述接收单元504接收的压缩后的报文进行解压。

同步单元506，用于将所述解压缩单元505解压后得到的待同步数据进行数据同步处理。

客户端50的所述压缩单元502在同步初始化阶段和/或同步完成阶段，将报文进行压缩后，由所述发送单元503发送到服务器；所述接收单元504接收服务器在同步初始化阶段和/或同步完成阶段发送的压缩后的报文，由所述解压缩单元505解压后进行处理。

客户端50进一步包括：加密单元507、解密单元508。

加密单元507，用于在将报文压缩前或压缩后，根据会话密钥对报文进行加密。

解密单元508，用于当所述接收单元504接收到压缩格式的加密后的报文并且由所述解压缩单元505将所述报文进行解压缩前或解压缩后，将报文解密。

客户端50进一步包括：第一设置单元5011、第一生成处理单元5012。

第一设置单元5011，用于设置客户端处理的路径分隔符，指示服务器采用所述路径分隔符发送数据。

第一生成处理单元5012，用于在同步初始化阶段将所述第一设置单元5011设置的路径分隔符添加到向服务器发送的报文中。

客户端50进一步包括：第二设置单元5013、第二生成处理单元5014。

第二设置单元5013，用于设置客户端处理的消息中的命令个数最大值，指示服务器按所述命令个数最大值在消息中设置命令个数。

第二生成处理单元5014，用于在同步初始化阶段将所述第二设置单元5013设置的客户端处理的消息中的命令个数最大值添加到向服务器发送的报文中。

请参阅图6，是本发明实施例服务器结构示意图。

如图6所示，服务器60包括：压缩单元602、发送单元603。

压缩单元602，用于根据将报文进行压缩处理。

发送单元603，用于将所述压缩单元602在同步阶段压缩后的报文向客户端发送，以供客户端解压后进行数据同步处理。所述压缩单元602采用ZIP/GZIP算法将报文进行压缩。所述压缩单元602是将报文中的待同步数据进行压缩。

服务器60进一步包括：接收单元604、解压缩单元605、同步单元606。

接收单元604，用于接收客户端发送的接收压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文。

解压缩单元605，用于将所述接收单元604接收的压缩后的报文进行解压。

同步单元606，用于将所述解压缩单元606解压后得到的待同步数据进行数据同步处理。

服务器60的所述压缩单元602在同步初始化阶段和/或同步完成阶段将报文进行压缩后，由所述发送单元603发送到客户端；所述接收单元604接收客户端在同步初始化阶段和/或同步完成阶段发送的压缩后的报文，由所述解压缩单元606解压后进行处理。

服务器60进一步包括：加密单元607、解密单元608。

加密单元607，用于在将报文压缩前或压缩后，根据会话密钥对报文进行加密。

解密单元608，用于当所述接收单元604接收到压缩格式的加密后的报文后并且由所述解压缩单元605将所述报文进行解压缩前或解压缩后，将报文解密。

服务器60进一步包括：第一设置单元6011、第一生成处理单元6012。

第一设置单元6011，用于设置服务器处理的路径分隔符，指示客户端采用所述路径分隔符发送数据。

第一生成处理单元6012，用于在同步初始化阶段将所述第一设置单元6011设置的路径分隔符添加到向客户端发送的报文中。

服务器60进一步包括：删除处理单元6013。

删除处理单元6013，用于当服务器与客户端在同步初始化阶段协商的数据同步类型为“客户端刷新同步”后，在同步阶段中将服务器的数据标记为删除状态；

在所述接收单元604接收所有包含待同步数据的报文，并且由所述同步单元606确认数据同步成功后，将标记为删除状态的数据删除，否则进行还原。

请参阅图7，是本发明实施例数据同步系统结构示意图。

如图7所示，数据同步系统包括：第一设备701、第二设备702。

第一设备701，用于在同步阶段中，将报文进行压缩，将所述压缩后的报文向第二设备702发送。

第二设备702，用于对所述第一设备701发送的报文解压后进行数据同步处理。

所述第一设备701进一步包括在将报文压缩前或压缩后，根据会话密钥对生成的报文进行加密处理；所述第二设备702接收到压缩格式的加密后的报文后，进行解压缩并根据会话密钥解密。

所述第一设备701为客户端，所述第二设备702为服务器；或者，所述第一设备701为服务器，所述第二设备702为客户端。客户端具有图5所示的结构，服务器具有图6所示的结构，此处不再详细介绍。

综上所述，本发明实施例技术方案中，客户端与服务器在数据同步过程中，待同步数据是采用压缩方式进行发送，因此与现有技术采用XML或WBXML格式进行发送相比，传输数据量可以很大，传输效率更高。

进一步的，本发明实施例技术方案中客户端与服务器在数据同步过程中，待同步数据是采用加密方式进行发送，因此与现有技术采用明文方式进行发送相比，待同步数据不容易被窃取，从而提高了提高数据同步的安全性。

进一步的，本发明实施例技术方案在初始化阶段、同步阶段、同步完成阶段都是采用加密方法进行传输，并且都采用压缩处理，进一步提高了传输效率，也提高了客户端的处理性能。

进一步的，本发明实施例通过设置路径分隔符，避免对端设备返回的响应消息中包含的路径分隔符与本端支持的不同而导致的同步异常或失败问题，通过设置一个消息中包含命令的最大值，避免一个消息中包含的命令个数超过该元素指定值而导致的客户端同步失败问题。

进一步的，本发明实施例通过改进现有的客户端刷新同步处理流程，在同步结束时增加一个服务器的处理流程来保证数据安全性，即服务器检查本次同步结果，如果失败则还原本次同步时标记为软删除状态的原有数据，并删除本次同步添加的客户端传输数据，使得客户端和服务器回退到同步前的状态，避免数据丢失。

另外，实现本发明实施例的软件可以存储于一计算机可读存储介质中，该软件在执行时，包括以下步骤：在同步阶段中，将报文进行压缩；将所述压缩后的报文发送到对端设备。所述的存储介质可以为Rom/Ram，磁盘，光盘等。

以上对本发明实施例所提供的一种数据同步方法、客户端、服务器及系统进行了详细介绍，对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (27)

1、一种数据同步方法，其特征在于，包括：

在同步阶段中，将报文进行压缩；

将所述压缩后的报文发送到对端设备。

2、根据权利要求1所述的数据同步方法，其特征在于，所述将报文进行压缩具体为：

对报文中的待同步数据进行压缩。

3、根据权利要求1所述的数据同步方法，其特征在于，所述将报文进行压缩具体为：

采用ZIP/GZIP算法将报文进行压缩。

4、根据权利要求1所述的数据同步方法，其特征在于，还包括：

接收压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文；

对报文解压后进行数据同步处理。

5、根据权利要求1至4任一项所述的数据同步方法，其特征在于，还包括：

在同步初始化阶段和/或同步完成阶段，将报文进行压缩后传输到对端设备，接收对端设备发送的压缩后的报文并解压后进行处理。

6、根据权利要求5所述的数据同步方法，其特征在于，还包括：

在将报文压缩前或压缩后，根据会话密钥对报文进行加密处理，当接收到压缩格式的加密后的报文后，进行解压缩并根据会话密钥解密。

7、根据权利要求5所述的数据同步方法，其特征在于，还包括：

当处于所述同步初始化阶段，在所述报文中设置本端处理的路径分隔符，指示对端设备采用所述路径分隔符发送数据。

8、根据权利要求7所述的数据同步方法，其特征在于：

对路径采用数据元素的名称或数据元素的标识表示。

9、根据权利要求5所述的数据同步方法，其特征在于，还包括：

当处于所述同步初始化阶段，客户端在所述报文中设置本端处理的消息中的命令个数最大值，指示服务器根据所述命令个数最大值在消息中设置命令个数。

10、根据权利要求5所述的数据同步方法，其特征在于，还包括：

若在所述同步初始化阶段协商的数据同步类型为“客户端刷新同步”，

则在同步阶段中，服务器接收客户端发送的含待同步数据的报文前，将本端数据标记为删除状态；

在接收所有含待同步数据的报文并确认数据同步成功后，将标记为删除状态的本端数据删除，否则进行还原。

11、一种客户端，其特征在于，包括：

压缩单元，用于将报文进行压缩处理；

发送单元，用于将所述压缩单元在同步阶段压缩后的报文向服务器发送。

12、根据权利要求11所述的客户端，其特征在于：

所述压缩单元是将报文中的待同步数据进行压缩。

13、根据权利要求11所述的客户端，其特征在于，还包括：

接收单元，用于接收服务器发送的压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文；

解压缩单元，用于将所述接收单元接收的压缩后的报文进行解压；

同步单元，用于将所述解压缩单元解压后得到的待同步数据进行数据同步处理。

14、根据权利要求13所述的客户端，其特征在于：

所述压缩单元在同步初始化阶段和/或同步完成阶段将报文进行压缩后，由所述发送单元发送到服务器；

所述接收单元接收服务器在同步初始化阶段和/或同步完成阶段发送的压缩后的报文，由所述解压缩单元解压后进行处理。

15、根据权利要求13或14所述的客户端，其特征在于，进一步包括：

加密单元，用于在将报文压缩前或压缩后，根据会话密钥对报文进行加密；

解密单元，用于当所述接收单元接收到压缩格式的加密后的报文并且由所述解压缩单元将所述报文进行解压缩前或解压缩后，将报文解密。

16、根据权利要求13或14所述的客户端，其特征在于，进一步包括：

第一设置单元，用于设置客户端处理的路径分隔符，指示服务器采用所述路径分隔符发送数据；

第一生成处理单元，用于在同步初始化阶段将所述第一设置单元设置的路径分隔符添加到向服务器发送的报文中。

17、根据权利要求13或14所述的客户端，其特征在于，进一步包括：

第二设置单元，用于设置客户端处理的消息中的命令个数最大值，指示服务器按所述命令个数最大值在消息中设置命令个数；

第二生成处理单元，用于在同步初始化阶段将所述第二设置单元设置的客户端处理的消息中的命令个数最大值添加到向服务器发送的报文中。

18、一种服务器，其特征在于，包括：

压缩单元，用于将报文进行压缩处理；

发送单元，用于将所述压缩单元在同步阶段压缩后的报文向客户端发送。

19、根据权利要求18所述的服务器，其特征在于：

所述压缩单元是将报文中的待同步数据进行压缩。

20、根据权利要求18所述的服务器，其特征在于，进一步包括：

接收单元，用于接收客户端发送的压缩后的报文，所述报文为整个报文被压缩或报文中的待同步数据被压缩后的报文；

解压缩单元，用于将所述接收单元接收的压缩后的报文进行解压；

同步单元，用于将所述解压缩单元解压后得到的待同步数据进行数据同步处理。

21、根据权利要求20所述的服务器，其特征在于：

所述压缩单元在同步初始化阶段和/或同步完成阶段，将报文进行压缩后，由所述发送单元发送到客户端；

所述接收单元接收客户端在同步初始化阶段和/或同步完成阶段发送的压缩后的报文，由所述解压缩单元解压后进行处理。

22、根据权利要求20或21所述的服务器，其特征在于，进一步包括：

加密单元，用于在将报文压缩前或压缩后，根据会话密钥对报文进行加密；

解密单元，用于当所述接收单元接收到压缩格式的加密后的报文后并且由所述解压缩单元将所述报文进行解压缩前或解压缩后，将报文解密。

23、根据权利要求20或21所述的服务器，其特征在于，进一步包括：

第一设置单元，用于设置服务器处理的路径分隔符，指示客户端采用所述路径分隔符发送数据；

第一生成处理单元，用于在同步初始化阶段将所述第一设置单元设置的路径分隔符添加到向客户端发送的报文中。

24、根据权利要求20或21所述的服务器，其特征在于，进一步包括：

删除处理单元，用于当服务器与客户端在同步初始化阶段协商的数据同步类型为“客户端刷新同步”后，在同步阶段中将服务器的数据标记为删除状态；

在所述接收单元接收所有包含待同步数据的报文，并且由所述同步单元确认数据同步成功后，将标记为删除状态的数据删除，否则进行还原。

25、一种数据同步系统，其特征在于，包括：

第一设备，用于在同步阶段中将报文进行压缩，将所述压缩后的报文向第二设备发送；

第二设备，用于对所述第一设备发送的报文解压后进行数据同步处理。

26、根据权利要求25所述的数据同步系统，其特征在于：

所述第一设备进一步包括在将报文压缩前或压缩后，根据会话密钥对生成的报文进行加密处理；

所述第二设备接收到压缩格式的加密后的报文后，进行解压缩并根据会话密钥解密。

27、根据权利要求25或26所述的数据同步系统，其特征在于：

所述第一设备为客户端，所述第二设备为服务器；或者，

所述第一设备为服务器，所述第二设备为客户端。

Images