CN101552773A - 一种数据同步中处理数据项标识符映射的方法、设备和系统 - Google Patents
一种数据同步中处理数据项标识符映射的方法、设备和系统 Download PDFInfo
- Publication number
- CN101552773A CN101552773A CNA2008101033789A CN200810103378A CN101552773A CN 101552773 A CN101552773 A CN 101552773A CN A2008101033789 A CNA2008101033789 A CN A2008101033789A CN 200810103378 A CN200810103378 A CN 200810103378A CN 101552773 A CN101552773 A CN 101552773A
- Authority
- CN
- China
- Prior art keywords
- data item
- new added
- local identifier
- added data
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种数据同步中处理数据项标识符映射的方法、设备和系统，方法具体包括：在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息；接收增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包，该数据包是所述客户端在所述数据同步交互过程中发送的数据包；将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。本发明实施例能够减少建立数据项标识符映射关系时的交互次数，节约系统资源。
Description
技术领域
本发明涉及通信技术领域，尤其涉及通信系统数据同步过程中处理数据项标识符映射的方法、设备和系统。
背景技术
SyncML(同步标记语言，Synchronization Makeup Language)协议是为了实现使用任何终端设备均可随时随地的访问任何网络数据而制定的协议。在SyncML同步协议中定义了SyncML客户端和SyncML服务器之间的消息交互过程。具体的，一次SyncML同步过程可以分为三个阶段：同步初始化阶段、同步阶段、同步完成阶段。
当SyncML服务器增加数据项后，SyncML客户端和SyncML服务器之间实现新增数据项的同步时消息交互过程的示意图如图1所示，图中，新增数据项同步过程的三个阶段由六个数据包代表完成(图中一个数据包完成的功能在实际中可能需要多次消息交互才能实现)，即从PKG1到PKG6；其中，
1、同步初始化阶段由PKG1和PKG2完成，该阶段主要完成身份鉴权、需要同步的数据库的协商、同步能力的协商；客户端首先向服务器发送同步初始化包PKG1，PKG1中包括客户端鉴权信息、设备能力等信息；服务器收到PKG1后，会验证客户端帐号信息，同时把验证结果通过PKG2包返回给客户端；
2、同步阶段由PKG3和PKG4完成；客户端收到PKG2后，根据PKG2中指定的同步类型，可以将本地数据库中自上次同步成功完成之后更新的所有数据封装到PKG3中发送给服务器；服务器收到PKG3后，执行其中的各种操作指令将数据更新到对应的数据库中，并可以将自身数据库中自上次同步完成之后更新的所有数据封装到PKG4中返回给客户端；
3、同步完成阶段由PKG5和PKG6完成，该阶段主要包括客户端和服务器端相互确认同步完成；客户端接收到PKG4后，执行其中的各种操作指令将数据更新到本地数据库中；当PKG4中包含向本地数据库中增加数据条目的指令，则客户端在成功向本地添加新的数据后，还需要将生成的相应ID(即数据项标识符)映射信息通过PKG5通知服务器；上述相应ID映射信息是指：由于服务器的数据库容量很大，因而其中某条数据对应的唯一标识ID和客户端数据库中某条数据对应的唯一标识ID不同，为了将双方要操作的同一数据条目对应起来，服务器还会维护一个ID映射表，如图2所示，图中，客户端用LUID(本地标识符，Local Unique Identifier)作为数据标识，服务器使用GUID(全局标识符，Global Unique Identifier)作为数据标识；因此在客户端只需维护LUID与具体数据的对应关系，而服务器不但需要维护GUID与实际数据的对应关系，还需要维护GUID与LUID的对应关系；
服务器将PKG5中包含的新增数据项的ID映射信息写入映射表之后，会返回PKG6告知客户端指令的执行状态；客户端收到PKG6并确认其中的状态码全部正常后，此次新增数据项的同步成功结束。
在上述同步过程中，服务器增加数据库中的数据时，会引起ID映射关系的变更，即当服务器增加数据时，服务器在同步阶段通过PKG4将新增数据项及其对应的GUID发送给客户端，客户端完成数据项的增加处理后为其生成LUID并将生成的LUID通过PKG5返回给服务器，服务器保存新增数据项的LUID和GUID映射关系。
发明人在实现本发明的过程中，发现现有技术中至少存在如下问题：
在实现新增数据的同步过程中，在服务器上建立新增数据项的LUID与GUID的映射关系时，现有技术主要是通过在上述PKG5中使用建立LUID与GUID的对应关系的命令MAP来实现，而随后的PKG6仅用于通知客户端MAP命令执行结果，这样的流程增加了建立新增数据项的LUID与GUID映射关系时的交互次数，占用了传输资源，影响系统性能。
发明内容
本发明的实施例提供了一种数据同步中处理数据项标识符映射的方法、设备及系统，能够减少建立数据项标识符映射关系时的交互次数，节约系统资源。
一种数据同步中实现数据项标识符映射的方法，包括：
在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息；接收增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包，该数据包是所述客户端在所述数据同步交互过程中发送的数据包，将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。
一种数据同步中分配数据项标识符的方法，包括：
接收服务器在数据同步交互过程发送的增加了新增数据项的数量信息的数据包后，根据所述信息为所述新增数据项分配本地标识符，并在所述数据同步交互过程中将增加了服务器用于赋给所述新增数据项、并生成与全局标识符的映射关系的所述本地标识符的数据包发送给所述服务器。
一种服务器，包括：
发送单元，用于在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息，并发送该数据包；
接收单元，用于接收所述客户端在所述数据同步交互过程发送的增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包；
处理单元，用于将所述接收单元接收的所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。
一种客户端设备，包括：
接收单元，用于接收服务器在在数据同步交互过程发送的增加了新增数据项的数量信息的数据包；
处理单元，用于根据所述接收单元接收的所述数据包中的所述信息为所述新增数据项分配本地标识符；
发送单元，用于在所述数据同步交互过程发送的数据包中增加所述处理单元分配的本地标识符，并将该数据包发送给所述服务器。
一种数据同步中处理数据项标识符映射的系统，包括：
服务器，用于在数据同步交互过程将增加了新增数据项的数量信息的数据包发送给客户端设备，接收所述客户端设备在所述数据同步交互过程中发送的增加了所述客户端设备根据所述信息为所述新增数据项分配的本地标识符的数据包后，将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系；
客户端设备，用于根据所述服务器发送的所述新增数据项的数量信息为所述新增数据项分配本地标识符，并将增加了所述分配的本地标识符的所述数据包发送给所述服务器。
由上述本发明的实施例提供的技术方案可以看出，由于服务器在数据同步交互过程中将增加了新增数据项的数量信息的数据包发送给客户端，可以使客户端预先为服务器端的新增数据项分配标识符，服务器收到客户端发送的增加了分配的本地标识符的数据包后，获取该分配的本地标识符建立LUID与GUID映射关系，因此不必使用MAP命令来建立LUID与GUID映射关系，相应的也省去了对MAP命令执行结果的确认步骤，即省去了同步完成阶段的PKG6包，从而实现了在建立数据项标识符(例如LUID与GUID)映射关系的过程中减少交互次数，节约传输资源。
附图说明
图1为背景技术的数据同步时消息交互过程的示意图；
图2为背景技术的ID映射关系示意图；
图3为本发明实施例提供的方法流程示意图；
图4为本发明实施例提供的方案一的方法流程示意图；
图5为本发明实施例提供的方案二的方法流程示意图；
图6为本发明实施例提供的方案三的方法流程示意图；
图7为本发明实施例提供的服务器结构示意图；
图8为本发明实施例提供的客户端设备结构示意图；
图9为本发明实施例提供的系统结构示意图。
具体实施方式
在本发明实施例中，为了在数据同步过程中建立新增数据的标识符(即ID，例如LUID与GUID)映射关系时，减少交互次数、节约传输资源，提供一种数据同步中实现数据项标识符映射的方法，具体可以由服务器在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息；服务器接收增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包，该数据包是所述客户端在所述数据同步交互过程中发送给所述服务器的数据包，所述服务器将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。其中，服务器上的所述新增数据项与所述全局标识符对应。
具体的，服务器在数据同步交互过程发送给客户端的数据包中还可以包括：与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。
进一步的，所述客户端为所述新增数据项分配本地标识符时，所述客户端按照分配规则给出本地标识符；若服务器发送的所述数据包还包括所述新增数据项的父数据项的本地标识符，则所述客户端为具有父数据项的所述新增数据项分配本地标识符时，所述客户端按照分配规则和所述父数据项的本地标识符给出本地标识符。
相应的，本发明实施例还提供一种数据同步中分配标识符的方法，具体可以包括：客户端接收服务器在数据同步交互过程发送的增加了新增数据项的数量信息的数据包后，根据所述信息为所述新增数据项分配本地标识符，并在所述数据同步交互过程中将增加了服务器用于赋给所述新增数据项、并生成与全局标识符的映射关系的所述本地标识符的数据包发送给所述服务器。
其中，服务器在数据同步交互过程发送给所述客户端的数据包中还可以包括：与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。所述客户端根据所述数量信息为所述新增数据项分配本地标识符时，所述客户端按照分配规则给出本地标识符；若所述数据包还包括所述新增数据项的父数据项的本地标识符，则所述客户端为具有父数据项的所述新增数据项分配本地标识符时，所述客户端按照分配规则和所述父数据项的本地标识符给出本地标识符。
由于一次SyncML同步过程可以分为三个阶段：同步初始化阶段、同步阶段、同步完成阶段，若这三个阶段由六个数据包(PKG1～PKG6)代表完成，则现有技术是在同步完成阶段的PKG5中使用MAP命令来建立新增数据项的LUID与GUID映射关系，并通过PKG6来确认MAP命令的执行结果；而本发明实施例提供的方法流程示意图，如图3所示，具体实现时可以在数据同步初始化时由服务器将增加了新增数据项的数量信息的PKG2数据包发送给客户端，客户端收到该PKG2后为所述新增数据项分配本地标识符，并在PKG3中增加所述本地标识符信息，然后将PKG3发送给服务器，服务器接收客户端为所述新增数据项分配的所述本地标识符后，将所述本地数据标识符赋给所述新增数据项，(由于所述新增数据项与服务器上的全局标识符对应)即生成所述本地标识符与全局标识符的映射关系条目，并将该条目加入映射关系表中；服务器发送数据时，可以将新增数据项的LUID和对应的数据(或根据PKG3执行的结果)，以及需要更新的数据通过PKG4一起发送给客户端；客户端根据PKG4的信息更新本地数据后，将本地更新结果通过PKG5发送给服务器，若客户端本地更新的结果正确，则本次数据同步结束。
从上述描述可知，本发明实施例可以通过在数据同步交互过程中的现有数据包PKG2和PKG3中增加相应信息来建立新增数据项的LUID与GUID映射关系，因此不必使用MAP命令来建立新增数据项的LUID与GUID映射关系，相应的也就省去了确认MAP命令执行结果的步骤，即省去了PKG6，从而减少了交互次数，节约了传输资源。
进一步的，服务器在数据同步交互过程发送给客户端的数据包中除了增加新增数据项的数量信息，还可以增加下述信息：与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。当服务器发送给客户端的数据包分别包括上述不同的信息时，具体实现方案也不同。
为便于对本发明实施例的理解，下面将结合附图对本发明实施例的具体实现方案进行详细的描述。
实现方案一
该实现方案中，服务器在数据同步交互过程发送给客户端的数据包PKG2中增加新增数据项的数量信息。
该方案的方法流程示意图如图4所示，具体步骤可以包括：
步骤41：服务器在PKG2中仅增加客户端新增数据项的数量信息；具体实现时，服务器可以在PKG2中使用<GetLUID>命令来通知客户端新增数据项的数量，也就是需要的LUID数量，<GetLUID>的Schema(模式)可以如下所示：
<xs:element name＝″GetLUID″>
<xs:complexType>
<xs:attribute ref＝″CmdID″use＝″required″/>
<xs:attribute ref＝″NumberofNews″use＝″required″/>
<xs:complexType>
</xs:element>
<xs:attribute name＝″NumberOfNews″type＝″xs:positiveIntege″/>
上述程序中，NumberofNews即表示新增数据项的数量；
步骤42：当客户端接收增加了新增数据项的数量信息的PKG2数据包后，根据所述数量信息为上述新增数据项分配相应数量的本地标识符，并将增加了所述分配的本地标识符的PKG3数据包发送给服务器；客户端发给服务器的本地标识符可以用<LUID>标识，具体实现时的Schema可以如下所示：
<xs:element name＝″LUID″type＝″LocURIType″maxOccurs＝″unbounded/>
若需要的LUID数量很多，客户端还可以指定LUID的取值范围，即将该取值范围内的LUID都分配给上述新增数据项；具体实现时的Schema可以如下所示：
<xs:element name＝″LUIDScope″type＝″LUIDScopeType″/>
<xs:complexType name＝″LUIDScopeType″>
<xs:element ref＝″LUIDBegin″/>
<xs:element ref＝″LUIDEnd″/>
</xs:complexType>
<xs:element name＝″LUIDBegin″type＝″LocURIType″/>
<xs:element name＝″LUIDEnd″type＝″LocURIType″/>
上述程序中，″LUIDBegin″和″LUIDEnd″即限定了分配的LUID范围；
步骤43：服务器接收客户端为所述新增数据项分配的本地标识符后，将本地标识符赋给所述新增数据项，(由于所述新增数据项与服务器上的全局标识符对应)即生成所述本地标识符(LUID)与全局标识符(GUID)的映射关系条目，并将该条目加入映射关系表中；当服务器发送新增数据项给客户端时，即将新增数据项的LUID和具体数据一起发送给客户端。
上述内容描述了服务器通过PKG2通知客户端新增数据的数量，建立新增数据项的LUID与GUID映射关系的方法流程，下面将结合列表对本发明实施例的应用过程进行详细说明。
表1是客户端与服务器刚完成一次数据同步后的LUID与GUID映射关系表：
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Urgent |
| 995 | ABCD995 | Work |
| 1000 | ABCD1000 | Study |
| 1001 | ABCD1001 | Pictures |
| 1002 | ABCD1002 | Friends |
表1
表1中示出了相同的数据项在服务器和客户端上分别对应的标识符。
随后，服务器上又新增了两个数据项，新增的两个数据项如表2所示：
| Server′s GUID(服务器GUID) | Object name(数据项名称) |
| ABCD997 | ToBeDone |
| ABCD998 | ToDoList.doc |
表2
表2中示出了新增数据项与服务器上的全局标识符的对应关系。
具体的，在对上述新增数据进行同步时，服务器在PKG2中可以使用<GetLUID>命令将需要的LUID数量通知客户端，具体的程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝“2.0”
VerProto＝“SyncML/2.0“SessionID＝“4″MsgID＝“1”>
...
</SyncHdr>
<SyncBody>
...
<GetLUID CmdID＝″12345″NumberofNews＝″2″/><！-服务器新增了2个数据项-->
...
<Final/>
</SyncBody>
</SyncML>
可以看出上述程序中，NumberofNews＝“2”表示了服务器新增2个数据项的信息。
客户端接收PKG2后，经过解析获知服务器需要2个LUID，于是，客户端按照分配规则将997、998这两个LUID分配给上述2个新增的数据项，并通过PKG3通知服务器，具体实现程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”2”>
...
</SyncHdr>
<SyncBody>
...
<Results CmdID＝”2345”MsgRef＝”1”CmdRef＝”12345”>
...
<LUID>997</LUID><！-客户端为服务器新增数据项分配的2个LUID-->
<LUID>998</LUID>
</Results>
...
<Final/>
</SyncBody>
</SyncML>
上述程序中，997、998即为客户端分配的2个新增数据项LUID。
当然，客户端也可以通过PKG3将分配的LUID范围通知服务器(这种方法尤其适合新增数据项很多的情况)，具体实现程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”2”>
...
</SyncHdr>
<SyncBody>
...
<Results CmdID＝”2345”MsgRef＝”1”CmdRef＝”12345”>
...
<LUIDScope>
<LUIDBegin>997</LUIDBegin><！-客户端为服务器新增数据项分配LUID的范围-->
<LUIDEnd>998</LUIDEnd>
</LUIDScope>
</Results>
...
<Final/>
</SyncBody>
</SyncML>
可以看出，上述程序中客户端为服务器新增数据项分配的LUID范围的起始LUID为997，结束LUID为998。
服务器收到PKG3后，经过解析得到客户端为两个新增数据项分配的LUID，服务器将其分配给新增数据项，生成LUID与GUID映射关系表，如表3所示；
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Urgent |
| 995 | ABCD995 | Work |
| 997 | ABCD997 | ToBeDone |
| 998 | ABCD998 | ToDoList.doc |
| 1000 | ABCD1000 | Study |
| 1001 | ABCD1001 | Pictures |
| 1002 | ABCD1002 | Friends |
表3
当服务器向客户端发送新增数据项时，将新增数据项的LUID和对应的数据一起发送给客户端，具体程序可以如下所示：
<Add CmdID＝”23451”>
<Cred>
...
</Cred>
<Item>
<Target>
<LocURI>997</LocURI>
</Target>
<Data>
ToBeDone
<Data>
</Item>
<Item>
<Target>
<LocURI>998</LocURI>
</Target>
<Data>
ToDoList.doc
<Data>
</Item>
</Add>
可以看出，本地标识符997对应的数据是ToBeDone，本地标识符998对应的数据是ToDoList.doc。
上述方案一的具体实施例详细描述了服务器在PKG2数据包中增加客户端新增数据的数量信息的情况下，建立新增数据项的LUID与GUID映射关系的过程。由于本方案通过在PKG2和PKG3中增加相应信息来建立新增数据项的LUID与GUID映射关系，可以不必使用MAP命令来建立新增数据项的LUID与GUID映射关系，相应的也可以省去确认MAP命令执行结果的步骤，即省去PKG6，从而实现了减少交互次数，节约了传输资源。
实现方案二
该实现方案中，服务器在发送给客户端的PKG2数据包中增加了新增数据项的数量信息，以及与这些新增数据项对应的GUID，和这些新增数据项的父数据项的LUID。当客户端分配标识符时，客户端按照分配规则给出本地标识符；若所述数据包中包括所述新增数据项的父数据项的本地标识符，则客户端为具有父数据项的新增数据项分配本地标识符时，按照分配规则和所述父数据项的本地标识符给出本地标识符。
该方案的方法流程示意图如图5所示，具体步骤可以包括：
步骤51：服务器在PKG2数据包中增加新增数据项的数量信息、与新增数据项对应的GUID信息、新增数据项的父数据项的LUID信息，然后将PKG2发送给客户端；
具体实现时，服务器可以在PKG2中使用<GetLUID>命令将新增数据项的数量信息，以及与这些新增数据项对应的GUID信息，还有这些新增数据项的父数据项的LUID信息一并发送给客户端；具体的，<GetLUID>的Schema(模式)可以如下所示：
<xs:element name＝″GetLUID″>
<xs:complexType>
<xs:element ref＝″New_Item″minOccurs＝″0″/>
<xs:attribute ref＝″CmdID″use＝″required″/>
<xs:attribute ref＝″NumberofNews″use＝″required″/>
<xs:complexType>
</xs:element>
<xs:attribute name＝″NumberOfNews″type＝″xs:positiveIntege″/>
<xs:element name＝″New_Item″>
<xs:complexType>
<xs:element ref＝″ParentLUID″/>
<xs:element ref＝″GUID″/>
<xs:complexType>
</xs:element>
<xs:element name＝″ParentLUID″type＝″LocURIType″/>
<xs:element name＝″GUID″type＝″LocURIType″/>
上述程序中，NumberofNews表示新增数据项的数量；ParentLUID表示新增数据项的父数据项的LUID，GUID表示新增数据项对应的GUID；
步骤52：当客户端接收到新增数据项的数量信息，以及与这些新增数据项对应的GUID信息，还有这些新增数据项的父数据项的LUID信息后，即根据上述信息为上述新增数据项分配相应数量的本地标识符(例如分配本地标识符时还需要考虑新增数据项的父数据项的LUID)，并将分配的本地标识符加入PKG3数据包后将PKG3发送给服务器；
若需要的LUID数量很多，客户端还可以指定LUID的取值范围，即将该取值范围内的LUID都分配给上述新增数据项；具体的Schema可以如下所示：
<xs:element name＝″IDMAPPING″type＝″IDMAPPINGType″
maxOccurs＝″unbounded/>
<xs:complexType name＝″IDMAPPINGType″>
<xs:element ref＝″GUID″/>
<xs:element ref＝″LUID″/>
</xs:complexType>
<xs:element name＝″GUID″type＝″LocURIType″/>
<xs:element name＝″LUID″type＝″LocURIType″/>
上述程序中，客户端分配了LUID的信息返回给服务器时可以用″IDMAPPING″来标识；
步骤53：服务器收到客户端为所述新增数据项分配的本地标识符后，将本地标识符赋给所述新增数据项，(由于所述新增数据项与服务器上的全局标识符对应)即生成所述本地标识符(LUID)与全局标识符(GUID)的映射关系条目，并将该条目加入映射关系表中；当服务器发送新增数据项给客户端时，即将新增数据项的LUID和具体数据一起发送给客户端。
上述内容描述了服务器通过PKG2将新增数据项的数量信息、与新增数据项对应的GUID信息、新增数据项的父数据项的LUID信息一并发送给客户端，建立新增数据项的LUID与GUID映射关系的方法流程，下面将结合列表对本发明实施例的应用过程进行详细说明。
表4是一个客户端与服务器刚刚就一个文件系统(只包含一级目录和一级文件)数据同步后生成的数据项的LUID与GUID映射关系表。
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Pictures |
| 995 | ABCD995 | Work |
| 1000 | ABCD1000 | Image1.jpg |
| 1001 | ABCD1001 | Image2jpg |
| 1002 | ABCD1002 | Work1.doc |
表4
其中，客户端为数据项分配LUID时遵循如下规则：目录用3位数字标识，而目录下的文件用4位数字标识。
随后，服务器又新增了2个数据项，一个为新增的目录：Friends，另一个为“Work”目录下的新增文件：work2.doc，如表5所示：
| Server′s GUID(服务器GUID) | Object name(数据项名称) |
| ABCD997 | Friends |
| ABCD1007 | Work2.doc |
表5
具体的，在对上述新增数据进行同步时，服务器可以在PKG2中使用<GetLUID>命令来通知客户端需要的LUID数量，以及与新增数据项对应的GUID和新增数据项的父数据项LUID，具体程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”1”>
...
</SyncHdr>
<SyncBody>
...
<GetLUID CmdID＝″12345″NumberofNews＝″2″><！-服务器新增了2个数据项-->
<NewItem>
<GUID>ABCD997</GUID><！-一个新增数据项对应的GUID-->
<ParentLUID/>
</NewItem>
<NewItem>
<GUID>ABCD1007</GUID><！-另一个新增数据项对应的GUID-->
<ParentLUID>995</ParentLUID><！-一个新增数据项的父数据项的LUID-->
</NewItem>
</GetLUID>
...
<Final/>
</SyncBody>
</SyncML>
通过上述程序，服务器将新增数据项的数量，以及新增数据项对应的GUID，还有一个新增数据项的父数据项的LUID均发送给了客户端。
客户端接收PKG2后，经过解析，获知服务器新增2个数据项，即需要2个LUID，其中一个新增数据项无父数据项，另一个有父数据项，则按照客户端分配LUID的规则将本地标识符997分配给无父数据项的新增数据项，将本地标识符1007分配给有父数据项的新增数据项；然后通过PKG3通知服务器，其中明确给出了LUID和GUID的对应关系，具体程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”2”>
...
</SyncHdr>
<SyncBody>
...
<Results CmdID＝”2345”MsgRef＝”1”CmdRef＝”12345”>
...
<IDMAPPING><！-客户端为服务器新增数据项分配的2个LUID-->
<GUID>ABCD997</GUID>
<LUID>997</LUID>
</IDMAPPING>
<IDMAPPING>
<GUID>ABCD1007</GUID>
<LUID>1007</LUID>
</IDMAPPING>
</Results>
...
<Final/>
</SyncBody>
</SyncML>
上述程序中，客户端具体给出了分配的LUID与GUID的对应关系，即997与ABCD997对应，1007与ABCD1007对应。
服务器接收PKG3后，经过解析得到客户端为两个新增数据项分配的LUID后，生成最新的数据项的LUID与GUID映射关系表，如表6所示：
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Pictures |
| 995 | ABCD995 | Work |
| 997 | ABCD997 | Friends |
| 1000 | ABCD1000 | Image1.jpg |
| 1001 | ABCD1001 | Image2jpg |
| 1002 | ABCD1002 | Work1.doc |
| 1007 | ABCD1007 | Work2.doc |
表6
当服务器发送新增数据项给客户端时，将新增数据项的LUID和对应的数据一起发送给客户端，具体程序可以如下所示：
<Add CmdID＝”23451”>
<Cred>
...
</Cred>
<Item>
<Target>
<LocURI>997</LocURI>
</Target>
<Data>
Friends
<Data>
</Item>
<Item>
<Target>
<LocURI>1007</LocURI>
</Target>
<Data>
Work2.doc
<Data>
</Item>
</Add>
上述方案二的具体实施例详细描述了服务器通过PKG2将新增数据的数量信息、新增数据项对应的GUID信息、新增数据项的父数据项的LUID信息发送给客户端，建立新增数据项的LUID与GUID映射关系的具体过程。本方案可以通过在数据包PKG2和PKG3中增加相应信息来建立新增数据项的LUID与GUID映射关系，因此不必使用MAP命令来建立新增数据项的LUID与GUID映射关系，相应的也可以省去确认MAP命令执行结果的步骤，即省去了PKG6，从而实现了减少交互次数，节约了传输资源。
实现方案三
该实现方案中，服务器在发送给客户端的PKG2数据包中增加了新增数据项的数量信息、属于同一个父数据项的新增数据项的数量信息、以及该父数据项的本地标识符信息。具体实现时，客户端为新增数据项分配本地标识符时，客户端按照分配规则给出本地标识符；若所述数据包中包括新增数据项的父数据项的本地标识符信息，则客户端按照分配规则和所述父数据项的本地标识符给出本地标识符。
该方案的方法流程示意图如图6所示，具体步骤可以包括：
步骤61：服务器在PKG2中增加了新增数据项的数量信息、属于同一个父数据项的新增数据项的数量信息、该父数据项的LUID信息，然后将该PKG2数据包发送给客户端；
具体实现时，服务器可以在PKG2中使用<GetLUID>命令将新增数据项的数量信息，以及属于同一个父数据项的新增数据项的数量信息，还有该父数据项的LUID信息也一并发送给客户端；具体的，<GetLUID>的Schema(模式)可以如下所示：
<xs:element name＝″GetLUID″>
<xs:complexType>
<xs:element ref＝″New_Item″minOccurs＝″0″>
<xs:attribute ref＝″CmdID″use＝″required″/>
<xs:attribute ref＝″NumberofNews″use＝″require d″/><！-新增数据项的数量-->
<xs:complexType>
</xs:element>
<xs:attribute name＝″NumberOfNews″type＝″xs:positiveInteger″/>
<xs:element name＝″New_Item″>
<xs:complexType>
<xs:element ref＝″ParentLUID″/><！-新增数据项的父数据项LUID-->
<xs:attribute ref＝″NumberWithSameParent″/><！-同一父数据项下的新增数据项数量-->
<xs:complexType>
</xs:element>
<xs:element name＝″ParentLUID″type＝″LocURIType″/>
<xs:attribute name＝″NumberWithSameParent″type＝″xs:positiveIntege″/>
步骤62：当客户端接收到新增数据项的数量信息、以及属于同一个父数据项的新增数据项的数量信息，和该父数据项的LUID信息时，即根据上述信息为上述新增数据项分配相应数量的本地标识符(例如分配本地标识符时还需要考虑新增数据项的父数据项的LUID)，并将增加了分配的本地标识符的PKG3数据包发送给服务器；
若需要的LUID数量很多，客户端还可以指定LUID的取值范围，即将该取值范围内的LUID都分配给上述新增数据项；客户端返回给服务器的信息可以用<IDGroup>来标识，具体的Schema可以如下所示：
<xs:element name＝″IDGroup″type＝″IDGroupType″maxOccurs＝″unbounded″/>
<xs:complexType name＝″IDGroupType″>
<xs:element ret＝″ParentLUID″/>
<xs:element ref＝″LUID″maxOccurs＝″unbounded″/>
</xs:complexType>
<xs:element name＝″ParentLUID″type＝″LocURIType″/>
<xs:element name＝″LUID″type＝″LocURIType″/>
步骤63：服务器接收客户端为所述新增数据项分配的本地标识符后，将所述分配的本地标识符赋给所述新增数据项，(由于所述新增数据项与服务器上的全局标识符对应)即生成所述本地标识符(LUID)与全局标识符(GUID)的映射关系条目，并将该条目加入映射关系表中；当服务器发送新增数据项给客户端时，即将新增数据项的LUID和具体数据一起发送给客户端。
上述内容描述了服务器通过PKG2将新增数据项的数量信息、属于同一个父数据项的新增数据项的数量信息、以及该父数据项的本地标识符信息一并发送给客户端，建立新增数据项的LUID与GUID映射关系的方法流程，下面将结合列表对本发明实施例的应用过程进行详细说明。
表7是一个客户端与服务器刚刚就一个文件系统(只包含一级目录和一级文件)数据同步后生成的数据项的LUID与GUID映射关系表。
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Pictures |
| 995 | ABCD995 | Work |
| 1000 | ABCD1000 | Image1.jpg |
| 1001 | ABCD1001 | Image2.jpg |
| 1002 | ABCD1002 | Work1.doc |
表7
其中，客户端为数据项分配LUID时遵循如下规则：目录用3位数字标识，而目录下的文件用4位数字标识。
随后，服务器又新增了3个数据项，均为“Work”目录下新增的文件：
Work2.doc、work3.doc、work4.doc，新增数据项与GUID的对应关系如表8所示：
| Server′s GUID(服务器GUID) | Object name(数据项名称) |
| ABCD1007 | Work2.doc |
| ABCD1008 | Work3.doc |
| ABCD1009 | Work4.doc |
表8
具体的，在对上述新增数据项进行同步时，服务器可以在PKG2中使用<GetLUID>命令来通知客户端需要的LUID数量，以及属于同一个父数据项的新增数据项的数量，还有该父数据项的本地标识符；具体程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”1”>
...
</SyncHdr>
<SyncBody>
...
<GetLUID CmdID＝″12345″NumberofNews＝″3″><！-服务器新增3个数据项-->
<NewItem NumberWithSameParent＝3><！-同一父数据项下新增3个数据项-->
<ParentLUID>995</ParentLUID><！-新增数据项的父数据项LUID-->
</NewItem>
</GetLUID>
...
<Final/>
</SyncBody>
</SyncML>
上述程序中，服务器通知客户端新增了3个数据项，且这3个数据项都在同一个父数据项目录下，该父数据项的LUID为995。
客户端接收PKG2后，经过解析，发现服务器新增3个数据项，即需要分配3个LUID，且这3个新增数据项同在LUID为995的父数据项下。于是客户端按照分配LUID的规则和该父数据项的本地标识符为新增数据项分配LUID：1007、1008、1009，然后通过PKG3通知服务器；具体程序可以如下所示：
<SyncML>
<SyncHdr VerSchema＝”2.0”
VerProto＝“SyncML/2.0“SessionID＝“4“MsgID＝”2”>
...
</SyncHdr>
<SyncBody>
...
<Results CmdID＝”2345”MsgRef＝”1”CmdRef＝”12345”>
...
<IDGroup><！-客户端为服务器新增数据项分配的3个LUID-->
<ParentLUID>995</ParentLUID><！-新增数据项的父数据项LUID-->
<LUID>1007</LUID>
<LUID>1008</LUID>
<LUID>1009</LUID>
</IDGroup>
</Results>
...
<Final/>
</SyncBody>
</SyncML>
服务器接收PKG2后，经过解析，得到客户端为3个新增数据项分配的LUID，生成数据项的LUID与GUID映射表如表9所示；
| Client′s LUID(客户端LUID) | Server′s GUID(服务器GUID) | Object name(数据项名称) |
| 990 | ABCD990 | Pictures |
| 995 | ABCD995 | Work |
| 1000 | ABCD1000 | Image1.jpg |
| 1001 | ABCD1001 | Image2jpg |
| 1002 | ABCD1002 | Work1.doc |
| 1007 | ABCD1007 | Work2.doc |
| 1008 | ABCD1008 | Work3.doc |
| 1009 | ABCD1009 | Work4.doc |
表9
从表9中可以看出，1007(LUID)与ABCD1007(GUID)对应，1008(LUID)与ABCD1008(GUID)对应，1009(LUID)与ABCD1009(GUID)对应。
当服务器发送新增数据项给客户端时，将新增数据项的LUID和对应的数据一起发送给客户端，具体程序可以如下所示：
<Add CmdID＝”23451”>
<Cred>
...
</Cred>
<Item>
<Target>
<LocURI>1007</LocURI>
</Target>
<Data>
Work2.doc
<Data>
</Item>
<Item>
<Target>
<LocURI>1008</LocURI>
</Target>
<Data>
Work3.doc
<Data>
</Item>
<Target>
<LocURI>1009</LocURI>
</Target>
<Data>
Work4.doc
<Data>
</Add>
上述方案三的具体实施例详细描述了服务器通过数据包PKG2将新增数据项的数量信息、属于同一个父数据项的新增数据项的数量信息、该父数据项的本地标识符信息发送给客户端，建立新增数据项的LUID与GUID映射关系的具体过程。本方案可以通过在数据包PKG2和PKG3中增加相应信息来建立新增数据项的LUID与GUID映射关系，因此不必使用MAP命令来建立新增数据项的LUID与GUID映射关系，相应的可以省去确认MAP命令执行结果的步骤，即省去了PKG6，从而减少了交互次数，节约了传输资源。
本发明实施例还提供了数据同步中处理数据项标识符映射的设备，包括：服务器和客户端设备。
本发明实施例提供的一种服务器，如图7所示，具体实现结构可以包括：
发送单元71，用于在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息，并发送该数据包；例如，在数据同步初始化时，在数据包PKG2中增加新增数据项的数量信息，并将PKG2发送给客户端；进一步的，发送单元除了在所述数据包中增加新增数据项的数量信息，还可以在该数据包中增加：与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息；
接收单元72，用于接收所述客户端在所述数据同步交互过程发送的增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包；例如，接收增加了所述客户端根据新增数据项的数量信息为所述新增数据项分配的本地标识符的数据包PKG3；具体的，收到的本地标识符是所述客户端根据新增数据项的数量信息、按照分配规则给出的本地标识符，若PKG3中包括新增数据项的父数据项LUID，则收到的是所述客户端按照分配规则和所述父数据项的本地标识符给出的本地标识符；
处理单元73，用于将所述接收单元72接收的所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系；具体的，处理单元73可以根据存储单元74存储的所述新增数据项与所述全局标识符的对应信息，生成所述本地标识符与全局标识符的映射关系，当然若客户端已给出LUID和GUID的对应关系，则可以省去根据存储单元74存储的对应信息生成所述本地标识符与全局标识符的映射关系操作；
存储单元74，用于存储所述新增数据项与所述全局标识符的对应信息，以及处理单元73生成的所述本地标识符与所述全局标识符的映射关系信息。
本发明实施例提供的一种客户端设备，如图8所示，具体实现结构可以包括：
接收单元81，用于接收服务器在数据同步交互过程发送的增加了新增数据项的数量信息的数据包；例如，接收服务器在数据同步初始化时发送的增加了新增数据项的数量信息的PKG2数据包；进一步的，收到的该数据包中还可以包括增加的与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息；
处理单元82，用于根据接收单元81接收的所述数据包中的所述信息为所述新增数据项分配本地标识符；具体的，处理单元82为所述新增数据项分配本地标识符，是根据所述信息、按照分配规则给出本地标识符；若新增数据项有父数据项，则按照分配规则和存储单元84存储的该父数据项的本地标识符给出本地标识符；
发送单元83，用于在所述数据同步交互过程发送给服务器的数据包中增加所述处理单元分配的本地标识符，并将该数据包发送；例如，将增加了处理单元82分配的本地标识符的PKG3数据包发送给服务器；
存储单元84，用于存储已有数据项与本地标识符的对应信息，包括所述父数据项与本地标识符的对应信息。
本发明实施例还提供一种数据同步中处理数据项标识符映射的系统，如图9所示，具体可以包括：服务器和客户端设备；
服务器，用于在数据同步交互过程将增加了新增数据项的数量信息的数据包发送给客户端设备，接收所述客户端设备在所述数据同步交互过程中发送的增加了所述客户端设备根据所述信息为所述新增数据项分配的本地标识符的数据包后，将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系；例如，在数据同步初始化时，服务器将增加了新增数据项的数量信息的PKG2数据包发送给客户端设备，通过PKG3数据包接收客户端设备根据所述信息为所述新增数据项分配的本地标识符后，将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系；
客户端设备，用于根据所述服务器发送的所述新增数据项的数量信息为所述新增数据项分配本地标识符，并将增加了所述分配的本地标识符的数据包发送给所述服务器；例如，客户端设备根据PKG2数据包中的所述新增数据项的数量信息为所述新增数据项分配本地标识符，并在发送给服务器的PKG3数据包中增加所述分配的本地标识符后，将PKG3数据包发送。
本发明实施例中的设备可以设置于网络终端设备中，或者，也可以设置在网络节点设备中。
综上所述，本发明各实施例和现有技术中相比，由于在数据同步交互过程中，例如在数据同步初始化时服务器将增加了新增数据项的数量信息的数据包发送给客户端，可以使客户端预先为服务器端的新增数据项分配标识符，服务器通过增加了分配的本地标识符的PKG3数据包获取该分配的标识符后建立LUID与GUID映射关系，因此不必使用MAP命令来建立LUID与GUID映射关系，相应的也省去了对MAP命令执行结果的确认步骤，即省去了同步完成阶段的PKG6包，从而实现了在建立LUID与GUID映射关系的过程中减少交互次数，节约传输资源。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。
Claims (14)
1、一种数据同步中实现数据项标识符映射的方法，其特征在于，包括：
在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息；
接收增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包，该数据包是所述客户端在所述数据同步交互过程中发送的数据包；
将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。
2、根据权利要求1所述的方法，其特征在于，所述在数据同步交互过程发送给客户端的数据包中还包括：
与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；
或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。
3、根据权利要求1或2所述的方法，其特征在于，所述接收的所述客户端为所述新增数据项分配的本地标识符，是所述客户端按照分配规则给出的本地标识符；若所述数据包还包括所述新增数据项的父数据项的本地标识符信息，则所述接收的所述客户端为具有父数据项的所述新增数据项分配的本地标识符，是所述客户端按照分配规则和所述父数据项的本地标识符给出的本地标识符。
4、一种服务器，其特征在于，包括：
发送单元，用于在数据同步交互过程发送给客户端的数据包中增加新增数据项的数量信息，并发送该数据包；
接收单元，用于接收所述客户端在所述数据同步交互过程发送的增加了所述客户端根据所述信息为所述新增数据项分配的本地标识符的数据包；
处理单元，用于将所述接收单元接收的所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系。
5、根据权利要求4所述的服务器，其特征在于，所述发送单元还用于在所述数据同步交互过程发送给客户端的数据包中增加：与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；
或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。
6、根据权利要求4所述的服务器，其特征在于，所述服务器还包括：
存储单元，用于存储所述新增数据项与所述全局标识符的对应信息，以及所述处理单元生成的所述本地标识符与所述全局标识符的映射关系信息。
7、根据权利要求6所述的服务器，其特征在于，所述处理单元是根据所述存储单元存储的所述新增数据项与所述全局标识符的对应信息，生成所述本地标识符与全局标识符的映射关系。
8、一种数据同步中分配数据项标识符的方法，其特征在于，包括：
接收服务器在数据同步交互过程发送的增加了新增数据项的数量信息的数据包后，根据所述信息为所述新增数据项分配本地标识符，并在所述数据同步交互过程中将增加了服务器用于赋给所述新增数据项、并生成与全局标识符的映射关系的所述本地标识符的数据包发送给所述服务器。
9、根据权利要求8所述的方法，其特征在于，所述服务器在数据同步交互过程发送的增加了新增数据项的数量信息的数据包中还包括：
与所述新增数据项对应的所述全局标识符信息，以及所述新增数据项的父数据项的本地标识符信息；
或者，属于同一个父数据项的新增数据项的数量信息，以及该父数据项的本地标识符信息。
10、根据权利要求9所述的方法，其特征在于，所述根据所述信息为所述新增数据项分配本地标识符时，按照分配规则给出本地标识符；若所述数据包中还包括所述新增数据项的父数据项的本地标识符信息，则为具有父数据项的所述新增数据项分配本地标识符时，按照分配规则和所述父数据项的本地标识符给出本地标识符。
11、一种客户端设备，其特征在于，包括：
接收单元，用于接收服务器在在数据同步交互过程发送的增加了新增数据项的数量信息的数据包；
处理单元，用于根据所述接收单元接收的所述数据包中的所述信息为所述新增数据项分配本地标识符；
发送单元，用于在数据同步交互过程发送的数据包中增加所述处理单元分配的本地标识符，并将该数据包发送给所述服务器。
12、根据权利要求11所述的设备，其特征在于，所述设备还包括：
存储单元，用于存储已有数据项与本地标识符的对应信息。
13、根据权利要求12所述的设备，其特征在于，所述处理单元为所述新增数据项分配本地标识符时，按照分配规则给出本地标识符；若新增数据项有父数据项，则按照分配规则和所述存储单元存储的该父数据项的本地标识符给出本地标识符；
14、一种数据同步中处理数据项标识符映射的系统，其特征在于，所述系统包括：
服务器，用于在数据同步交互过程将增加了新增数据项的数量信息的数据包发送给客户端设备，接收所述客户端设备在所述数据同步交互过程中发送的增加了所述客户端设备根据所述信息为所述新增数据项分配的本地标识符的数据包后，将所述本地标识符赋给所述新增数据项，生成所述本地标识符与全局标识符的映射关系；
客户端设备，用于根据所述服务器发送的所述新增数据项的数量信息为所述新增数据项分配本地标识符，并将增加了所述分配的本地标识符数据包发送给所述服务器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101033789A CN101552773B (zh) | 2008-04-03 | 2008-04-03 | 一种数据同步中处理数据项标识符映射的方法、设备和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101033789A CN101552773B (zh) | 2008-04-03 | 2008-04-03 | 一种数据同步中处理数据项标识符映射的方法、设备和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101552773A true CN101552773A (zh) | 2009-10-07 |
| CN101552773B CN101552773B (zh) | 2012-08-22 |
Family
ID=41156765
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008101033789A Active CN101552773B (zh) | 2008-04-03 | 2008-04-03 | 一种数据同步中处理数据项标识符映射的方法、设备和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101552773B (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102238223A (zh) * | 2010-05-06 | 2011-11-09 | 清华大学 | 一种面向移动设备的网络化个人数据管理方法 |
| CN103347005A (zh) * | 2013-06-19 | 2013-10-09 | 北京奇虎科技有限公司 | 一种控制数据上报的方法以及客户端设备和服务器设备 |
| CN104717620A (zh) * | 2013-12-13 | 2015-06-17 | 中国电信股份有限公司 | 手机终端中短信信息的同步处理方法和系统 |
| CN105100158A (zh) * | 2014-05-15 | 2015-11-25 | 中兴通讯股份有限公司 | 消息推送、获取方法及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6516327B1 (en) * | 1998-12-24 | 2003-02-04 | International Business Machines Corporation | System and method for synchronizing data in multiple databases |
| GB2420882A (en) * | 2004-12-02 | 2006-06-07 | Nec Technologies | Database synchronisation system |
| CN1794724A (zh) * | 2005-10-27 | 2006-06-28 | 华为技术有限公司 | 在SyncML层实现数据同步的方法 |
| KR20070064893A (ko) * | 2005-12-19 | 2007-06-22 | 주식회사 팬택앤큐리텔 | 서버와 클라이언트 사이의 데이터 동기화 방법 |
| CN101009516B (zh) * | 2006-01-26 | 2011-05-04 | 华为技术有限公司 | 一种进行数据同步的方法、系统及装置 |
-
2008
- 2008-04-03 CN CN2008101033789A patent/CN101552773B/zh active Active
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102238223A (zh) * | 2010-05-06 | 2011-11-09 | 清华大学 | 一种面向移动设备的网络化个人数据管理方法 |
| CN102238223B (zh) * | 2010-05-06 | 2012-10-10 | 清华大学 | 一种面向移动设备的网络化个人数据管理方法 |
| CN103347005A (zh) * | 2013-06-19 | 2013-10-09 | 北京奇虎科技有限公司 | 一种控制数据上报的方法以及客户端设备和服务器设备 |
| CN103347005B (zh) * | 2013-06-19 | 2016-08-10 | 北京奇虎科技有限公司 | 一种控制数据上报的方法以及客户端设备和服务器设备 |
| CN104717620A (zh) * | 2013-12-13 | 2015-06-17 | 中国电信股份有限公司 | 手机终端中短信信息的同步处理方法和系统 |
| CN105100158A (zh) * | 2014-05-15 | 2015-11-25 | 中兴通讯股份有限公司 | 消息推送、获取方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101552773B (zh) | 2012-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101127915B (zh) | 一种基于增量式的电子节目导航数据同步方法及系统 | |
| CN101505550B (zh) | 设备管理的方法和终端、装置、系统 | |
| US20120047244A1 (en) | Distributed Network Management System, Network Element Management Server, and Data Configuration Management Method | |
| CN105184540A (zh) | 一种智能快递柜系统控制方法 | |
| EP2214372B1 (en) | Method and apparatus for tracking device management data changes | |
| CN102291416A (zh) | 一种客户端与服务器端双向同步的方法及系统 | |
| CN102394948B (zh) | Dhcp地址分配方法及dhcp服务器 | |
| CN103685385A (zh) | 一种文件同步的方法、系统和装置 | |
| CN101552773B (zh) | 一种数据同步中处理数据项标识符映射的方法、设备和系统 | |
| CN104902444A (zh) | 一种集群系统的动态重组方法及系统 | |
| CN105959420A (zh) | 多客户端元数据同步更新方法及系统 | |
| CN101132416A (zh) | 一种日程发布、预约方法及日程管理系统以及相关设备 | |
| CN102024040A (zh) | 数据库同步方法、装置和系统 | |
| CN101980504B (zh) | 数据共享方法、移动终端及服务器 | |
| CN101730085B (zh) | 通信录数据同步方法和系统 | |
| CN104994502A (zh) | 基于xmpp协议的商业wifi管理系统及其使用方法 | |
| CN102694824A (zh) | 一种用户数据存储系统及其数据访问方法 | |
| CN102624932A (zh) | 基于索引的异地云数据同步方法 | |
| CN101834914B (zh) | 一种身份与位置映射关系的实现方法 | |
| CN102006156B (zh) | 配置数据的板间同步方法及系统 | |
| CN102594874A (zh) | 一种同步处理方法和装置 | |
| CN101150545B (zh) | 一种媒体网关多模块数据配置下的数据分发方法 | |
| US8271434B2 (en) | Central data store process configuration | |
| CN103200593A (zh) | 基站自启动和自启动辅助方法及设备 | |
| CN101087263B (zh) | 一种通过搜索引擎获取用户状态信息的方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |