CN103327073A - 数据同步协议 - Google Patents

Abstract

本发明公开了用于同步客户端设备与服务器之间的数据的技术和系统，以及其它。同步数据包括通过针对一个或多个数据类中的每一个在客户端设备与服务器之间协商同步模式来发起同步会话。基于协商的结果生成状况码。基于所生成的状况码，客户端设备和服务器使用针对各个数据类所协商的同步模式、针对该一个或多个数据类来交换要更新的一个或多个数据项。在客户端设备处或者在服务器处对所交换的一个或多个数据项进行更新。在客户端处或者服务器处交付经更新的一个或多个数据项。

Description

数据同步协议

本申请是优先权日为2008年3月4日、申请日为2010年11月4日、发明名称为“数据同步协议”的中国专利申请“200980116069.8”的分案申请。

技术领域

本申请涉及用于数据同步的协议。

背景技术

可以使用诸如开放移动联盟——数据同步协议OMA DS/SyncML（以前称为SyncML协议）之类的同步协议来执行客户端与服务器之间的数据同步。OMS DA/SyncML是使数据类（dataclass）能够串行同步并且针对每个数据类可能需要5个或者更多个往返行程（roundtrip）的同步协议。

发明内容

公开了用于同步客户端设备与服务器之间的数据的技术和系统等。

在一个方面，同步数据包括接收用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。一个或多个状况码被生成，以指示出针对各个数据类的所提议同步模式是否被接受。基于所生成的状况码，针对各个数据类使用所接受的同步模式来选择性地更新与对所述一个或多个数据类的一个或多个改变相关联的一个或多个数据项。经更新的一个或多个数据项在服务器处被选择性地交付（commit）。

实现方式可以可选地包括如下特征中的一项或多项。生成所述一个或多个状况码可以包括访问从先前的同步会话保存的信息以判断是否使用所述所提议同步模式来同步所述一个或多个数据项。接收所述请求可以包括并行地接收针对两个或更多个数据类的所提议同步模式。此外，接收所述请求可以包括接收包含快速同步模式、慢速同步模式或复位同步模式的所提议同步模式。此外，接收所述请求可以包括接收快速同步模式，所述快速同步模式允许仅交换要更新的数据项。同步会话可在包含两个消息的一个往返行程中完成。当所述同步会话中断时，所述快速同步模式可被再次接受。可在来自客户端设备的单个消息中接收所述所提议同步模式和对所述一个或多个数据类的所述一个或多个改变。当客户端设备发送用以交付经更新的一个或多个数据项的命令时，可在所述服务器处选择性地交付所述经更新的一个或多个数据项。另外，可拒绝所述所提议同步模式；并且可利用不同的同步模式对所接收的请求作出响应。

在另一个方面，一种包含在计算机可读介质上的计算机程序产品可操作来致使数据处理装置执行各种操作。该计算机程序产品可操主来致使数据处理装置接收用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。计算机程序产品可操作来致使数据处理装置生成状况码，所述状况码指示出针对各个数据类的所提议同步模式是否被接受。计算机程序产品可操作来致使数据处理装置基于所生成的状况码，使用针对各个数据类的所接受同步模式来选择性地更新与对所述一个或多个数据类的一个或多个改变相关联的一个或多个数据项。另外，计算机程序产品可操作来致使数据处理装置在服务器处选择性地交付经更新的一个或多个数据项。

实现方式可以可选地包括如下特征中的一项或多项。该计算机程序产品可致使数据处理装置基于从先前的同步会话保存的信息来生成所述一个或多个状况码。该计算机程序产品可致使数据处理装置并行地接收针对两个或更多个数据类的所提议同步模式。该计算机程序产品可致使数据处理装置接收包含快速同步模式、慢速同步模式或复位同步模式的所提议同步模式。该计算机程序产品可致使数据处理装置接收快速同步模式，所述快速同步模式允许仅交换要更新的数据项。对数据项的更新操作可以（1）创建新项（添加），（2）修改现有项的特性（修改）或者（3）删除现有项（删除）。该计算机程序产品可致使数据处理装置在包含两个消息的一个往返行程中完成所述同步会话。该计算机程序产品可致使数据处理装置在所述同步会话中断时再次接受快速同步模式。该计算机程序产品可致使数据处理装置在单个消息中接收所述所提议同步模式和对所述一个或多个数据类的所述一个或多个改变。该计算机程序产品可致使数据处理装置当客户端设备发送用以交付经更新的一个或多个数据项的命令时，在服务器处选择性地交付所述经更新的一个或多个数据项。另外，该计算机程序产品可致使数据处理装置拒绝所述所提议同步模式并利用不同的同步模式对所接收的请求作出响应。

在另一个方面，一种用于同步数据的服务器包括：处理器，被配置来操作传送协议，该传送协议使得能够开放到一个或多个客户端设备的一个或多个连接。处理器还被配置来操作同步协议，该同步协议使得能够经由所开放的一个或多个连接而在所述服务器和所述一个或多个客户端设备之间进行数据同步。同步协议使得服务器能够接收用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。同步服务器还使得服务器能够生成一个或多个状况码，所述状况码指示出针对各个数据类的所提议同步模式是否被接受。同步协议还使得服务器能够基于所生成的状况码，使用针对各个数据类的所接受同步模式来选择性地更新与对所述一个或多个数据类的一个或多个改变相关联的一个或多个数据项。同步协议还使得能够在服务器处选择性地交付经更新的一个或多个数据项。

实现方式可以可选地包括如下特征中的一项或多项。处理器可被配置来访问数据仓库以基于所接收的一个或多个改变来更新一个或多个数据项。处理器可被配置来操作所述同步协议以基于从先前的同步会话保存的信息来接受或拒绝针对各个数据类的所提议同步模式。处理器可被配置来操作所述同步协议以并行地接收针对两个或更多个数据类的所提议同步模式。此外，处理器可被配置来操作所述同步协议以接收包含快速同步模式、慢速同步模式或复位同步模式的所提议同步模式。处理器可被配置来操作所述同步协议以接收包含快速同步模式的所提议同步模式，所述快速同步模式允许所述一个或多个客户端设备仅发送要更新的数据项。处理器可被配置来操作所述同步协议以在所述同步会话中断时接收用于再次发起快速同步的请求。处理器可被配置来操作所述同步协议以在包含两个消息的一个往返行程中完成所述同步会话。处理器可被配置来操作所述同步协议以在来自所述一个或多个客户端设备中的至少一个客户端设备的单个消息中接收所述所提议同步模式和对所述一个或多个数据类的所述一个或多个改变。处理器可被配置来操作所述同步协议以在所述一个或多个客户端设备中的一个客户端设备发送用以交付经更新的一个或多个数据项的命令时，在所述服务器处选择性地交付所述经更新的一个或多个数据项。此外，处理器可被配置来操作所述同步协议以拒绝所述所提议同步模式并利用不同的同步模式对所述请求作出响应。

在另一个方面，同步数据包括向服务器发送用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。一个或多个状况码被接收用以指示出针对各个数据类的所提议同步模式是否已被所述服务器接受。基于所接收的状况码，针对各个数据类的所接受同步模式被用来从所述服务器接收对所述一个或多个数据类的附加改变。此外，在客户端设备处交付从所述服务器接收的所述附加改变。

实现方式可以可选地包括如下特征中的一项或多项。一个或多个状况码可以指示出针对所述一个或多个数据类中的至少一个数据类的所提议同步模式已被所述服务器拒绝。包含与被拒绝的同步模式不同的同步模式的另一请求可被发送到服务器。此外，可在单个消息中向所述服务器发送所述所提议同步模式和所述一个或多个改变。可并行地发送针对两个或更多个数据类的所提议同步模式。另外，可针对所述两个或更多个数据类中的每一个数据类并行地发送不同的所提议同步模式。例如，可针对这些数据类中的一个数据类发送所提议快速同步模式，并且针对这些数据类中的另一数据类发送所提议慢速同步模式。在所述同步会话中断之后，可使用被接受的同步协议来再次发起同步会话。

在另一方面，包含在计算机可读介质中的一种计算机程序产品可操作来致使数据处理装置执行一个或多个操作。该计算机程序产品可操作来致使数据处理装置向服务器发送用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。该计算机程序产品可操作来致使数据处理装置接收一个或多个状况码，所述状况码指示出针对各个数据类的所提议同步模式是否已被所述服务器接受。基于所接收的状况码，该计算机程序产品可操作来使用所接受的同步模式来从所述服务器接收对所述一个或多个数据类的附加改变，并在客户端设备处交付从所述服务器接收的所述附加改变。

实现方式可以可选地包括如下特征中的一项或多项。该计算机程序产品可操作来致使数据处理装置执行包括如下处理的操作：接收指示出针对所述一个或多个数据类中的至少一个数据类的所提议同步模式已被所述服务器拒绝的一个或多个状况码；以及发送另一请求，该另一请求包含与被拒绝的同步模式不同的同步模式。该计算机程序产品可操作来致使数据处理装置在单个消息中向所述服务器发送所述所提议同步模式和所述一个或多个改变。该计算机程序产品可操作来致使数据处理装置并行地发送针对两个或更多个数据类的所提议同步模式。该计算机程序产品可操作来致使所述数据处理装置针对所述两个或更多个数据类中的每一个数据类并行地发送不同的所提议同步模式。该计算机程序产品可操作来致使所述数据处理装置针对所述数据类中的一个数据类发送所提议的快速同步模式，并针对所述数据类中的另一数据类发送所提议的慢速同步模式。该计算机程序产品可操作来致使所述数据处理装置在所述同步会话中断之后使用所接受的同步协议来再次发起同步会话。

在另一方面，一种客户端设备包括：处理器，该处理器被配置来操作传送协议和同步协议，传送协议使得能够开放到服务器的一个或多个连接，同步协议使得能够经由所开放的一个或多个连接而在所述客户端设备和所述服务器之间进行数据同步。同步协议使得所述客户端设备能够向服务器发送用于发起同步会话的请求。该请求包括针对一个或多个数据类中的每一者的所提议同步模式，和对所述一个或多个数据类的一个或多个改变。同步协议还使得客户端设备能够接收一个或多个状况码，所述状况码指示出针对各个数据类的所提议同步模式是否已被所述服务器接受。基于所接收的状况码，同步协议使得客户端设备能够使用所接受的同步模式来从所述服务器接收对所述一个或多个数据类的附加改变。此外，同步协议使得客户端设备能够在客户端设备处交付从所述服务器接收的所述附加改变。

实现方式可以可选地包括如下特征中的一项或多项。处理器可被配置来操作所述同步协议以接收指示出针对所述一个或多个数据类中的至少一个数据类的所提议同步模式已被所述服务器拒绝的一个或多个状况码；以及发送另一请求，该另一请求包含与被拒绝的同步模式不同的同步模式。处理器可被配置来操作所述同步协议以在单个消息中向所述服务器发送所述所提议同步模式和所述一个或多个改变。处理器可被配置来操作所述同步协议以并行地发送针对两个或更多个数据类的所提议同步模式。处理器可被配置来操作所述同步协议以并行地发送针对两个或更多个数据类的所提议同步模式包括针对所述两个或更多个数据类中的每一个数据类并行地发送不同的所提议同步模式。处理器可被配置来操作所述同步协议以针对所述数据类中的一个数据类发送所提议的快速同步模式，并针对所述数据类中的另一数据类发送所提议的慢速同步模式。处理器可被配置来操作所述同步协议以在所述同步会话中断之后使用所接受的同步协议来再次发起同步会话。

根据本说明书的技术和系统可被实现来潜在地提供各种优点。如本说明书中所述的同步协议可以减少完成同步会话的往返行程的数目（来回交换消息的次数）。如本说明书所述的同步协议可以在例如一个往返行程中完成同步会话。如本说明书所述的同步协议使得可以并行地针对多个数据类中的每一个进行同步模式协商。因此，可在一个消息中针对多个数据类发送对同步模式协商的请求。此外，本说明书中所述的同步协议使能了额字段级差异化和记录级差异化。

本说明书中所述的同步协议比诸如SyncML之类的传统协议简单。可用于该同步协议的命令集简单而且还可扩展。与SyncML不同，本说明书所述的同步协议将每一个消息表示为文本或二进制特性列表文件（plist）。另外，本说明书所述的同步协议高效且鲁棒。例如，在服务器上提供了复杂的锚逻辑。此外，该同步协议能够容忍不可靠的网络。即使在网络连接中断时，锚逻辑也确保一旦再次连接就进行高效同步。此外，该同步协议可维持相对较小的消息大小。

本说明书所述的同步协议是富产的（rich）。例如，该同步协议使能了客户端设备与服务器之间的设备信息交换。此外，该同步协议提供了便利且丰富的数据表示。

附图说明

图1A是示出用于使能客户端设备与服务器之间的数据同步的系统的框图。

图1B示出了服务器的示例组件。

图1C示出了客户端设备的示例组件。

图2是示出消息的头部元素的示例元素的表格。

图3示出了示例特性列表文件（plist）。

图4是示出命令请求元素的示例元素的表格。

图5是示出命令响应元素的示例元素的表格。

图6是示出get命令的示例参数的表格。

图7是示出get命令响应的示例参数的表格。

图8是示出put命令的示例参数的表格。

图9是示出put命令响应的示例参数的表格。

图10是示出delete命令的示例参数的表格。

图11是示出delete命令响应的示例参数的表格。

图12是示出sync-start命令的示例参数的表格。

图13是示出sync-start命令响应的示例参数的表格。

图14是示出sync-changes命令的示例参数的表格。

图15是示出sync-changes命令响应的示例参数的表格。

图16是示出sync-commit命令的示例参数的表格。

图17是示出sync-commit命令响应的示例参数的表格。

图18是示出sync-cancel命令的示例参数的表格。

图19是示出sync-cancel命令响应的示例参数的表格。

图20是示出示例状况元素的表格。

图21是示出可包括在消息头部、命令和命令响应中的状况的示例状况码的表格。

图22是描述接收到命令的给定状况对会话或者消息中的其它命令的效果的表格。

图23是示出anchors元素的示例键的表格。

图24示出了同步会话的示例。

图25示出了客户端设备与服务器之间的最佳快速或复位同步的示例。

图26示出了快速或复位数据同步的替代示例。

图27示出了另一示例数据同步会话，其中，idmap被从会话1推迟到会话2的开始。

图28图示了慢速同步的示例。

图29示出了并行地同步多个数据类的示例。

图30示出了使用检查点锚的示例同步会话。

图31是示出示例检查点锚的表格。

图32示出了对DeviceInfo元素的示例键-值对进行定义的表格。

图33是示出过滤器设定的示例键-值对的表格。

图34是协议句法的增广型巴科斯诺尔范式（ABNF）描述。

图35示出了示例同步会话。

图36示出了用于复位同步会话的四种示例消息的概要。

图37a和37b示出了从客户端设备发送到服务器的示例消息。

图38a、38b、38c和38d示出了从服务器发送到客户端设备的示例消息。

图39a、39b和39c示出了从客户端设备发送的示例消息。

图40a和40b示出了从服务器发送的示例消息。

图41示出了用于快速同步的两种示例消息的概要。

图42a和42b示出了从客户端设备发送的用于快速同步的示例消息。

图43a、43b和43c示出了响应于客户端设备所发送的消息而从服务器发送的示例消息。

图44a和44b示出了用于同步客户端设备和服务器的示例处理。

各幅图中的相似参考符号和指定指示相似元素。

具体实施方式

公开了用于使客户端设备能够与服务器之间的空中（OTA，over-the-air）同步的技术和系统。特别地，无线结构的数据同步协议可以使得客户端设备能够与服务器进行接口连接（interface）以对各种数据进行同步。这种协议可用来例如同步诸如

之类的手持设备和诸如

服务器之类的服务器之间的

操作系统X（OS X）SyncServices数据。

此说明书中描述的OTA同步协议依赖于底层网络传送、例如使用传送层安全措施（TLS）来执行认证和/或授权以及消息安全/加密。同步协议可以使用超文本传送协议（HTTP）传送协议或者其它类似的能够在设备和服务器之间交换同步协议消息的传送协议来使能（enable）这些数据传送。

同步协议可以经由诸如HTTP传送之类的传送来使能协议消息的交换。经由传送交换的各个消息包括头部元素和主体元素。主体元素可以包括一系列的命令和/或命令响应元素。同步协议向各个消息、命令和命令响应指派唯一标签（label）以确保适当排序和丢失检测。例如，标签可以包括用于对消息、命令和命令响应进行排序的一系列数字。通过使用标签，由同步协议而不是传送（例如HTTP）确保了适当排序和丢失检测，即使在网络协议不强制实施消息排序的情况下也是如此。

该同步协议比诸如同步标记语言（SyncML）之类的传统协议更简单。可用于该同步协议的命令集简单且可扩展。例如，三种灵活的基原（primitive）命令可用于操纵资源。另外，四种“sync”族命令（familycommand）可用于数据同步。此外，可以跨消息边界对命令进行分割。与SyncML不同，在此说明书中描述的同步协议将每个消息表示为文本或二进制特性列表文件（plist）。在Mac OS X Cocoa、NeXTSTEP和GNUstep编程架构中，plist是存储序列化对象的文件。Plist通常被用来存储用户设定，这类似于

上的Windows注册表的功能。特性列表文件还被用来存储有关软件包（bundle）和应用的信息。很容易使用诸如NSPropertyListSerialization类之类的标准操作系统（OS）特征来生成和解析Plist。此外，此说明书中描述的同步协议使用简单的同步状态机。

此说明书中描述的同步协议是高效且鲁棒的。例如，在服务器上提供了复杂的锚逻辑（anchor logic）。锚是用来跟踪同步状态的标记符（tag）或标签。此外，该同步协议可并行地对多个数据类进行同步。该同步协议能够容忍不可靠的网络。即使在网络连接被中断时，锚逻辑也确保一旦再次连接就利用最少的数据重传来进行高效同步。此外，该同步协议能够维持相对较小的消息大小。

此说明书中描述的同步协议是丰富的。例如，该同步协议使能了客户端设备与服务器之间的设备信息交换。此外，该同步协议提供了便利且丰富的数据表示。

图1a是用于使能客户端设备与服务器之间的数据同步的系统100的框图。系统100包括经由网络150而与一个或多个服务器120接口连接的一个或多个客户端设备110。客户端设备110可以包括移动设备，例如移动电话112、个人数字助理（PDA）114、手持数据处理设备116等。移动电话112包括诸如

之类的智能电话和集成移动设备。手持数据处理设备可以包括诸如MP3播放器和

设备之类的音频播放设备。

客户端设备110使用诸如HTTP传送协议之类的传送协议来与服务器120进行接口连接以完成安全数据连接。通过传送协议，同步协议140使能了经连接的客户端设备110与服务器之间的数据同步。所同步的数据包括诸如联系人（contact）（例如，地址和电话号码）、日历（calendar）等的各种数据类。可经由网络150执行数据同步，网络150包括诸如局域网（LAN）、广域网（WAN）、以太网、因特网等的有线和无线网络。

图1b示出了服务器120的示例组件。服务器120可以包括处理器160和存储器170，以及除此之外的其它组件。处理器160可以包括中央处理单元（CPU）或者能够执行计算机程序的其它类别的逻辑机器。存储器可以包括非易失性存储设备，例如固定硬盘驱动器或者可移除存储设备。可移除存储设备可以包括致密闪存单元、USB存储棒等。存储器170还可包括易失性存储器，例如各种形式的随机存取存储器。

处理器160可以操作传送协议130以开放到一个或多个客户端设备110的传送连接。处理器160可以经由所开放的传送连接来操作同步协议140以使能服务器120与客户端设备110之间的数据同步。传送协议130和同步协议140可被加载并在存储器170上运行以由处理器160来执行或操作。例如，如下面参考图2-44b所述，处理器160可以操作同步协议140来接收来自客户端设备110的请求以发起同步会话。

图1c示出了客户端设备110的示例组件。客户端设备110也可包括处理器180和存储器190，以及除此之外的其它组件。处理器180可以包括中央处理单元（CPU）或者能够执行计算机程序的其它类别的逻辑机器。存储器可以包括非易失性存储设备，例如固定硬盘驱动器或者可移除存储设备。可移除存储设备可以包括致密闪存单元、USB存储棒等。存储器190还可包括易失性存储器，例如各种形式的随机存取存储器。

处理器180可操作传送协议130以开放到一个或多个服务器120的传送连接。处理器180可以经由所开放的传送连接来操作同步协议140以使能客户端设备110与服务器120之间的数据同步。传送协议130和同步协议140可被加载并在存储器190上运行以由处理器180执行或操作。例如，如下面参考图2-44b所述，处理器180可以操作同步协议140来向服务器120发送请求以发起同步会话。

同步是通过周期性地比较从上次知道两个不同数据存储库相一致起各个数据存储库所发生的改变来维持这两个数据存储库之间的一致性的处理。数据存储库可以包括在一侧的客户端设备110和在另一侧的服务器120。为了彼此同步，数据存储库配置有各种能力。例如，每个数据存储库被配置为在被请求时供应所有数据。另外，每个数据存储库被配置为识别并供应从上次同步起的改变。每个数据存储库被配置为对要保持同步的格局（schema）达成一致。每个数据存储库被配置为对所支持的数据表示达成一致。每个数据存储库被配置为对同步基原（即，添加、更新、删除）的语义（semantic）达成一致。此外，每个数据存储库被配置为如果在同步期间发生问题就回滚（rollback）到前一状态，以避免破坏这些数据存储库。

所同步的数据遵循关系模型（E-R），并被划分成“格局”或“数据类”，这些“格局”或“数据类”对结构化数据类型（“实体”）的定义进行了分组。给定数据类中的实体可以通过“关系”来相互引用。分立数据类中的实体之间的关系被禁用，因此每个数据类完全独立于其他数据类。从用户的角度来看，数据类可以看起来由分开的专门应用来管理。例如，“联系人”数据类可以主要由地址簿应用来管理，而“日历”数据类可以由日历应用来管理。

同步服务器140使能各种同步模式，包括慢速、复位和快速。客户端设备和服务器首次同步时，针对一数据类的全部数据被交换，以使被认为相同的现有数据项“匹配”。为了针对随后的同步操作优化同步和网络带宽利用率，客户端设备和服务器应当仅交换自从二者上次同步以来改变过的数据。这样，每一实体（即客户端设备或服务器）应当能够确定哪些本地改变应当被发送到另一实体。另外，每一实体应当能够检测是否发生了下述情形：所述情形要求在“快速”同步能够恢复之前交换更多数据。

当客户端设备110和服务器120首次同步以建立共同基准线用于随后的仅差异数据交换时，可以要求慢速同步模式。在慢速同步期间，客户端设备110把针对一数据类的全部数据发送到服务器120。服务器试图将这些数据项与服务器120已知的那些项匹配。未能执行正确的“身份匹配”可能产生复制的数据。服务器120于是用客户端设备110处缺失的数据项来作出响应。

复位同步模式被用来用服务器的数据把客户端设备上的数据类的全部数据复位。当数据结构已被推送到设备110时，或者在服务器120或设备110确定该设备的本地数据受到破坏的情况下，可能发生这种情况。设备110不发送数据，并且服务器用该数据类的完整数据结构来作出响应。

快速同步模式是最高效的模式，尤其是在使用有限带宽的连接的时候。客户端设备110仅发送自从与服务器120上次同步以来改变过的那些数据。服务器120仅用客户端设备110外部的已改变的那些数据来作出响应。

同步会话可以遵循独特的一组阶段，包括协商、拉取、混合（mingle）、推送和交付。术语“拉取”和“推送”可以相对于服务器处理进行定义。客户端设备110在拉取阶段将其本地改变发送到服务器120，并在服务器的推送阶段接收更新。

在协商阶段，双方（客户端设备110和服务器120）可以交换来自前一同步会话的信息以确定它们针对当前会话同意使用哪种同步模式。为了帮助识别并组织同步会话，向每一同步会话指派“同步锚”。如果客户端设备110此前已与服务器120同步，则客户端设备110很可能期待特定的同步模式。客户端设备110可能相信其能够与服务器120快速同步，但是服务器120可能希望复位该设备。当所请求的同步模式被双方接受时，同步可继续进行到拉取阶段。

在拉取阶段，客户端设备110将其经改变的记录（或者在同步模式为“慢速”同步模式的情况下，所有记录）发送给服务器120。服务器120可以拒绝无效的改变。

一旦已经接收到所有改变，服务器120就进入混合阶段并将其数据库中的任何待决更新与来自客户端设备110的改变合并。混合的结果是应当被推送给客户端设备110的一组冲突改变和一组更新。服务器120可使用启发式算法来自动解决所有冲突。在一些实现方式中，可能希望客户端设备110解决某些冲突。同步协议140可被设计为允许对冲突进行表示并将这些冲突从服务器120发送到客户端设备110。同步协议140可被设计为使得要由用户在客户端设备上解决的冲突能够被发送到同步服务器120。

在推送阶段，来自服务器120的更新被发送到客户端设备110。当客户端设备110已接收到所有更新时，进入交付阶段。双方（客户端设备110和服务器120）可以一致认定同步是成功的，坚持它们当前的同步锚，并将所交换的数据交付给它们各自的数据存储库。

在同步期间的任何时间点，任一方可以决定取消同步并将任何改变回滚到本地数据存储库。可以响应于如下事件中的一个或多个事件而明确地发生取消：当预期以外的或者无效的数据被发送时；当同步状态机中的预期跳转未被跟随时；当客户端设备110与服务器120之间的通信被中断时；或者当发生某些其它问题时。

可在各种粒度（granularity）下对数据差异进行同步。在交换同步数据时，对于记录级的差异化（RLD），客户端设备110和服务器120可以针对每个经改变的记录发送完整数据。可替代地，对于字段级差异（FLD），可以仅发送每一经改变的记录的改变字段。FLD相对于RLD更加优选，特别是当数据记录包括许多字段或者包含大量数据（例如，联系人数据类中的图像）时。

服务器120可动态地支持从客户端设备110接收的数据的RLD和FLD两种表示。改变的数据表示指示出客户端设备110对于给定数据类使用的是RLD还是FLD。这在用以支持FLD的元信息的维持复杂度不合理时，向客户端设备的数据存储库实现方式提供了最大限度的灵活性。

当接收到RLD改变时，为了处理、存储和通信效率，服务器120内部地将改变转换为FLD。服务器120期待RLD客户端设备110发送完整记录。受客户端设备110支持并且从客户端设备的数据记录缺失的数据字段被假设为已由客户端设备110清除/删除。但是，可以提供机制来使得客户端设备110在没有发送数据字段值的情况下指示出某些数据字段异常值未经改变。

标识（ID）映射是另一基本同步概念。每一经同步的数据具有通用唯一记录ID即UUID。为了效率，服务器120可以使用Mac OS X上的SyncService的UUID。可替代地，客户端设备110上的应用可以使用其用于数据的本地唯一ID（LUID）以例如提升本地数据存储库效率。

服务器120使得客户端设备110数据存储库能够按需使用它们自身的LUID来参考数据项。在此情况中，服务器120维护LUID到UUID的映射以使得客户端设备110能够通过使用其自身的本地ID来透明地参考全局记录。当针对数据类接受了“慢速”或“复位”同步模式时，服务器120重新建立新映射。

同步协议140包括使用诸如HTTP之类的传送协议130在服务器120和设备110之间交换的一系列消息。同步协议140包括在传送协议130上交换的消息。客户端设备110和服务器120在同步协议中的角色与它们在通信/传送协议中的角色不同。例如，对于HTTP传送130，设备110对于传送130总是为客户端，因而设备110仅作出请求。但是，在同步协议140的消息协议中，客户端设备110和服务器120两者都可以向彼此发出消息命令。

传送

传送协议130对服务器120与客户端设备110之间的消息交换进行管理。传送协议130可以包括HTTP传送或其它合适的传送，例如，可扩展消息传递和存在协议（XMPP）。传送协议130层对认证进行处置（handle），因而同步协议140无需处置安全/认证处理。这使得同步协议140能够更高效地工作并要求少量的往返行程。例如，如果需要，可以使用传送层安全（TLS）来确保所发送数据的安全性。此外，传送协议130还可执行消息成块化（message chunking）。传送协议130无需保证递送或消息排序，因为同步协议140具有用于进行递送或消息排序以及检测消息丢失的必要信息。

HTTP定义了八种方法或“verb（动词）”，这些方法或“verb”指示出要对资源执行的动作。HTTP方法包括HEAD、GET、POST、PUT、DELETE、TRACE、OPTIONS和CONNECT。当使用HTTP作为传送协议130时，将使用POST方法。POST方法将待处理的数据（例如，来自HTML表格的数据）提交给所识别的资源。数据包括在请求的主体中。POST方法的结果可能导致新资源的创建或者现有资源的更新，或者两者都有。

例如，服务器120可以提供在诸如“http://sync.mac.com/ota”之类的URL上的OTA同步服务。当使用文本plist表示时，“Content-Type（内容-类型）”头部应当是“text/xml”。当使用二进制plist表示时，“Content-Type”头部必须存在并且必须是“application/octet-stream”。“Content-Length（内容-长度）”头部必须指示出消息的大小。User-Agent（用户-代理）字符串被用来标识客户端协议实现方式。User-Agent字符串应当具有如下形式：“Mobile/1A543”。可替代地，可使用DeviceInfo方法来确定设备实现方式版本。

OTA协议结构

会话由客户端设备110与服务器120之间的多个协议消息的交换组成。HTTP传送实现方式可以使用cookies来维持与服务器120的会话。客户端设备110与服务器120中的任一者可以通过在消息头部中设定标志（flag）来指示出会话完成。每一消息包含可由接收者处理的一系列命令。客户端设备110可被指定为发起到服务器120的连接的那方。

使用同步协议140交换的消息被表示为经UTF-8编码的OS X特性列表（即，字典，dictionary）。这种表示辅助在客户端设备110和服务器120两者上的创建、序列化和解析。同步协议140可以支持plist的可扩展标记语言（XML）和二进制两种表示。二进制plist可以比XML plist更紧凑60％到80％。当使用XML plist表示时，所发送的任何二进制数据都被序列化为64基（base-64）编码的NSData对象，并且文本数据根据RFC3076而被XML转义（XML-escaped）。每一协议消息包括两个根元素：头部和主体。

图2是图示出示例头部元素210的表格。消息头部元素210可以包括service、deviceid、version、userid、sequence、msisdn、final、result等。与每一头部元素210相对应地，还示出了头部元素的类型220。图2还示出了各个头部元素210是否必需（230）。此外，在图2中提供了每一头部元素的简短描述240。

头部元素210可以标识发送消息的实体（例如，客户端设备110或服务器120），并且可以包含某些会话控制信息。头部元素210是消息的必需元素，并且头部元素的值是字典。头部中的元素210例如可以指示出源实体（“deviceid”）和目标服务（“service”）、目标账户（“userid”）和消息序列号（“sequence”）。此外，“version”元素可以指示出正在使用的同步协议版本。例如，图2在描述240栏中示出当前版本是“1.0”。这些元素210应当全部出现在消息中。

图2还示出头部元素210中的service、deviceid、version、userid、sequence和msisdn的值被设定为字符串。例如，sequence元素的值对于给定会话是从“1”起单调增加的整数值。Sequence元素被用来指示出会话的消息排序。

Service元素的值是标识诸如同步服务器之类的目标服务的名称的字符串。Userid元素的值是指示出消息的目标账户的字符串。Userid元素可以标识在传送协议130上向服务器120认证了的主要用户（principal）。客户端设备110的deviceid是唯一地标识设备硬件的字符串。对于

和

触摸设备，deviceid元素可以是集成电路卡（ICCID）值。具有GSM无线电的客户端设备110也可发送msisdn元素以指示出当前安装的/活动的安全信息管理（SIM）卡的电话号码。Msisdn值可以随会话改变（例如，当用户替换SIM卡时）而改变，而不会影响同步行为。

Final元素在发送者（例如客户端设备110）认为它那侧的会话将完成时出现在头部中。final元素是具有TRUE值的布尔类型（Boolean）。当final元素标志存在时，认为会话完成。发送者随后可以释放任何与会话相关的资源，并且不需要接收者发送另一消息。接收者可以发送另一消息来返回未完成的命令响应。但是，接收者不应发送任何进一步的命令请求。Userid和service元素的值对于给定会话中的所有消息应当恒定。Deviceid元素的值对于发送实体而言应当保持恒定。换言之，虽然服务器120和客户端设备110可以具有不同的值，但是这些值可以不变。

Result元素可以存在于消息头部中用以指示消息的总体状况。为了协议简短起见，对于没有头部状况的任何消息暗示S_OK状况。当检测到消息不被接受时，result元素出现在头部中。当数据残缺时或者当接收者遭遇会话致命状况时，消息可不被接受。Non-OK状况值指示出在前的消息主体未被处理，该消息的所有命令都未被执行，并且会话应当被终止。例如，E_BadRequest（703）的头部状况值指示出前一消息是残缺的。E_LimitExceeded（611）的头部状况值指示出前一消息的大小超过了接收者的能力。此外，E_ServiceBusy（700）、E_ServiceUnavailable（701）和E_RetryLater（704）的头部状况值指示出服务器120在处理请求方面正在经历困难。

图3示出了示例plist300。示例plist300包括头部310和主体320。头部310包括各种示例头部元素312、314、316、318和319。例如，示出了具有字符串值“f1234567a0745a890a86b5556d9e020202bRX8”的示例deviceid元素312。此外，示出了具有字符串值“14155338207”的示例msisdn元素。另外，还示出了具有值“1”的示例sequence元素。Plist300还包括具有sync字符串值的示例service元素。Plist300还包括具有字符串值“1.0”的示例version元素。

消息的主体包括要由接收者处理的一系列命令请求和/或命令响应。主体元素是消息的必需元素，并且主体的值被表示为一系列的命令或命令响应字典。当发送者没有命令要发送时，主体元素可以为空。按命令序列顺序来处理主体中的命令。

设备110和服务器120两者都可以在同一消息中发送命令请求和响应。这可以取决于当前会话的状态。

同步协议中的命令可以分成两个一般种类：（1）影响发送者、接收者和对消息或会话中的其它命令的处理的状态的命令；和（2）不影响前述状态的命令。给定的无状态命令是否成功执行可能不会隐式地影响消息中的其它命令。有状态命令以“命令族”前缀（例如，用于所有的数据同步命令的“sync-”）开始。命令族前缀还提供一种有用的命令名称空间机制，该机制允许服务器120支持针对不同客户端设备110的任意一组服务。在给定消息中，连续地对给定“命令族”中的命令进行处理，并且如果任意命令返回不成功状况，则可能根本不对该族中的后续命令进行处理。例如，在此情况中可以返回具有如下状况码的命令响应：该状况码指示出命令尚未被处理（例如，E_CommandNotProcessed）。

非最后消息的接收者在会话的下一个消息中包括针对每个命令的一个或多个命令响应。最后消息的接收者在最后消息是在传送层请求上发送的（即，传送响应是可预期的）情况下，包括针对每个命令的一个或多个命令响应。最后消息的接收者在最后消息是在传送层响应上发送的情况下，包括针对每个命令的一个或多个命令响应。

三个无状态基原命令可被定义为：“get”、“put”和“delete”。这些无状态命令可用于在同步协议140内实现任意对象交换或代表性状态转递（RESTful）语义。这例如可用于执行管理动作、转递设备设定或能力、或者参考二进制大对象或其它元数据，而无需服务器120执行数据同步操作。

当先验地检测到给定命令或命令响应的数据太大时，发送者可以将它们分割成在连续消息中发送的多个片段。给定命令可由于各种原因和/或约束（包括存储器约束、传送约束等）而被分割。

图4是示出包括在命令请求中的示例命令元素的表格。每个命令请求或命令响应由字典表示。对于命令请求，可以提供各种命令元素410。示例命令元素可以包括“name”元素、“sequence”元素和“params”元素。这些命令元素410对于所有命令都应当存在。“name”和“sequence”元素的值420是字符串。“params”元素的值应当是字典。字典是键（key）/值配对的映射表。键是字符串，值是取决于特定命令的其它类型。另外，对于每个命令元素，值的类型420被示出在表格的第二栏。第三栏430指示该命令元素是否是必需的。此外，在最后一栏示出了每个命令元素的简短描述440。

类似于消息，命令可以向sequence元素指派对于每个会话单调增加的整数值。例如，整数值可以开始于“1”并且针对每个会话单调增加。基于sequence元素的检测值，接收者按序列号顺序来处理命令。

Name元素是必需元素，其指示出命令的名称。Name元素的值是字符串。

命令请求使用params元素来将命令的参数传递给接收者。Params元素是必需元素，其具有包括字典在内的值。具体的参数元素和值可取决于具体的命令而变化，如图4所示。

当发送者需要指示出命令被分割成多个片段时，命令需要more元素。每个片段重复使用原始命令的“sequence”值。当存在时，more元素的值是Boolean值“TRUE”。

图5是示出示例命令响应元素的表格。命令响应元素包括“name”、“sequence”、“params”、“more”、“result”和“response”。针对每个命令响应元素，提供了值的类型520。Name和sequence元素的值例如是字符串。Params元素的值是字典。More和response元素的值是Boolean值“TRUE”，result元素的值是数组。

表格第三栏530示出了各个命令响应元素是否是必需的。另外，针对每个命令响应，在表格第四栏中呈现了简短描述540。例如，name元素描述命令的名称，例如“get”。此外，与命令请求相对应的命令响应的sequence元素应当与母命令请求具有相同的sequence值。类似于命令，params元素被命令响应用来向接收者传递命令响应的参数。Params元素是必需元素，其具有包括字典在内的值。具体的参数元素和值可以取决于具体的命令响应而变化，如图5所示。另外，命令响应使用与其所关联的命令请求相同的参数值。

Response元素指示出消息主体项是命令响应。没有response元素则指示出主体是命令请求。Response元素的值是值为“TRUE”的Boolean。

命令响应使用被指派了整数值的sequence元素。如上所述，被指派给sequence元素的值对应于此前由接收者发送的命令sequence。接收者基于sequence值按序列顺序来处理命令响应。正常而言，发送者严格地每在给定消息中接收到一个命令就发送一个命令响应。但是，如果命令响应的状况是S_NotCompleted（指示出对命令的处理尚未完成），则发送者可以在后续消息中发送针对该命令的另一命令响应。可替代地，如果命令被分割成多个片段，则可针对每一命令片段发送一个命令响应。

Result元素是包括在命令响应中的必需元素。Result元素的值是指示出命令请求的结果的一个或多个状况项的数组。当不能以及时的方式（例如在客户端的传送请求超时之前）完成命令时，接收者可以返回诸如S_NotCompleted（602）之类的状况来指示出命令未完成。这个状况并不是指示命令成功与否，而是向命令发送者通知结果将稍后在会话中可得。当在接收到最后状况之前会话终止时，假定失败状况，例如E_Failed状况。未知命令请求产生未知状况值，例如E_UnknownCommand（608）。此外，对于有状态命令的预期以外命令产生状态差错值，例如E_StateError（610）。

在接收者在处理有状态命令时遭遇差错的情况下，针对消息中的同一命令族的后续有状态命令可能根本就不被处理。在此情况中，针对这些命令返回诸如E_CommandNotProcessed（609）之类的状况以指示出命令未被处理。取决于情形，发送者可以再次尝试这些命令。

命令定义

图6、7、8、9、10、11、12、13、14、15、16、17、18和19是示出命令和命令定义的示例的表格。同步协议140定义了在同步会话期间可发送的这些命令。命令的此列表并不是包含所有命令的列表。可以添加其它命令来扩展并延伸同步协议以提供其它服务。

基原命令

图6、7、8、9、10和11所列出的命令是可以修改接收者上的任意资源的无状态命令。可用的无状态命令包括“get”、“put”和“delete”。这些无状态命令能够实现同步协议140内的对象交换或RESTful语义。每个命令可以包括一个或多个参数，例如“uri”、“value”、“item-type”、“items”、“idmap”、“userid”、“authtype”、“auth”、“version”、“anchors”等等。这些参数中的一些是必需的，而其它是可选的。

例如，“uri”参数是被指派了字符串值的必需参数。“uri”参数可以指定要访问的所希望资源。同步协议140没有指定“uri”参数是表示客户端设备110或服务器120上的实际资源（例如，文件系统路径）还是虚拟资源。“value”参数的类型由客户端设备110和服务器120来确定。另外，“value”参数的类型并不由同步协议140指定。“value”参数的逻辑类型可以使用“item-type”参数来显式地指定。无论如何，“value”参数的表示必须是有效的特性列表类型。

出于限制对所指示URI的访问的目的，接收者可以使用消息的“userid”作为经授权的主要用户。如果会话授权不够充分，则命令中可以可选地包括“userid”、“authtype”和“auth”元素。

图6是示出get命令及其关联参数610的表格，关联参数610包括“uri”、“userid”、“authtype”和“auth”。这些参数中的每一个被指派了字符串值620。表格还示出了这些参数中的任一个是否是必需的630。虽然uri参数是必需的（由核选标记（check mark）指示），但是其余参数可以可选地包括在get命令中。此外，还提供了参数的描述640。Uri参数的值描述要取得的数据对象的URI。可选userid参数的值描述是否可选地覆盖（override）消息的userid。可选authtype参数的值可以描述可选的认证类型。可选auth字符串值的值可以描述可选的认证证书。

图7是示出get命令响应的示例参数710的表格。这些示例参数包括“uri”、“value”和“item-type”。关联的参数值720对于这些参数而言是字符串。第四栏730示出uri和value参数是必需的而item-type是可选的。还示出了参数的描述740。类似于get命令，get命令响应的uri参数描述get命令所请求的数据对象的URI。Value参数描述URI的值。例如，get命令使得发送者能够从接收者请求希望的数据对象或值。作为响应，接收者向get命令的发送者发送get命令响应。Get命令响应包括value参数，用以针对get命令所指示的URI返回结果值。此外，get命令响应的可选item-type参数描述值的类型。

图8是示出put命令的示例参数的表格。Put命令使得发送者能够将任意数据对象转递给接收者。示例参数810包括“uri”、“value”、“item-type”、“userid”、“authtype”和“auth”。该表格示出这些参数810中的每一个被指派了字符串参数值820。此外，表格还示出参数是否是必需的830。例如，uri和value参数是必需的而其余参数是可选的。最后一栏示出各个参数810的描述840。Uri参数的值表示要替换的数据对象的URI。Value参数指定要放入到接收者的值。Item-type参数描述值的逻辑类型。可选的userid参数的值描述是否可选地覆盖消息的userid。可选authtype参数的值可以描述可选的认证类型。可选auth字符串值的值可以描述可选的认证证书。

图9是示出put命令响应的示例参数910的表格。作为对put命令的响应，接收者发送包括uri参数的put命令响应。如第四栏930中的核选标记所示，uri参数是必需参数。参数类型920是uri参数的字符串。类似于put命令，uri参数描述940响应于put命令而替换的数据对象的URI。

图10是示出delete命令的示例参数的表格。Delete命令包括各种参数1010，例如“uri”、“userid”、“authtype”和“auth”。参数类型1020对于这些参数而言是字符串。如第四栏1030中的核选标记所示，uri参数是必需的。其余参数是可选的。参数1010的描述1040类似于针对get和put命令所描述的那些。Delete命令使得发送者能够请求去除指定的URI。

图11是示出delete命令响应的示例参数1110的表格。Delete命令响应包括uri参数。表格示出uri参数类型1120是字符串。Uri参数是必需的（1130），并因而包括在delete命令响应中。表格还包括对参数的描述1140。例如，字符串类型uri参数描述响应于delete命令而删除的对象的URI。

图12、13、14、15、16、17、18和19所列出的命令是有状态命令。同步协议70还提供了有状态sync族命令和命令响应。有状态命令包括sync-start、sync-changes、sync-commit和sync-cancel。这些有状态命令使能了客户端设备110与服务器120之间的结构化数据同步。这些有状态命令和命令响应中的每一个都包括“uri”参数，用以标识将受给定命令影响的数据类状态机。

图12是示出sync-start命令的示例参数1210的表格。sync-start命令使得接收者能够创建针对给定数据类的同步状态机。示例参数1210包括“uri”和“anchors”。参数类型1220对于uri参数是字符串。参数类型1220对于anchors参数是字典。如第三栏1230中的核选标记所示，“uri”和“anchors”参数是必需的参数。

表格还包括各个参数的描述1240。例如，uri参数指示出数据类名称，例如针对联系人的字符串“com.apple.Contacts”或者针对日历的字符串“com.apple.Calendars”。当检测到接收者不支持该数据类时，返回状况E_NotSupported（612）。当检测到数据类未被使能时，返回状况E_NotAllowed（604）。在这两种情况中，状况“param-name”元素都应当存在，并且应当使值“uri”指示出uri参数是所返回状况的成因。anchors参数包含在同步协商阶段期间使用的信息。该信息可以包括所请求的同步模式（“mode”）；数据存储库版本（“device_version”，“server_version”）；同步锚（“last_device_anchor”，“next_device_anchor”，“last_server_anchor”，“next_server_anchor”）。Anchor元素的“device_version”参数描述了客户端设备110的版本。Anchor元素的“server_version”参数描述了服务器进程120的版本。Anchors参数可以包括设备、服务器、过滤器和复位锚。这些锚可用于请求同步模式。默认的同步模式是快速同步模式。这些锚可用于指定同步方向。默认的同步方向是“双向”，这指示出将从客户端设备110向服务器进程120以及从服务器进程120向客户端设备110发送改变。

图13是示出sync-start命令响应的示例参数的表格。Sync-start命令响应的示例参数1310可以包括“uri”和“anchors”参数。Uri和anchors参数的参数类型1320分别是字符串和字典。表格还示出这些参数是不是必需参数（1330）。表格中还示出了参数的描述1340。Uri参数描述数据类的名称，例如联系人、日历等等。可为客户端设备110、服务器120、过滤器和复位提供anchors参数。另外，anchors参数可用于指示所请求的同步模式，例如快速、慢速和复位。默认的同步模式是快速。

当接收者想要使用所提交的信息来同步时，接收者利用sync-start命令响应来返回OK状况S_OK（600）。当接收者想要利用经过调整的参数（例如，使用与客户端请求的同步模式不同的同步模式）来同步时，接收者返回协商失败状况，例如E_NegotiationFailed（613）。当接收者不支持提供来的发送者的版本（例如“device_version”）时，接收者返回诸如E_VersionNotSupported（612）之类的状况，用以指示出版本得不到支持。当接收者不支持所希望的同步方向（例如“direction”）时，接收者返回诸如E_NotSupported（614）之类的状况，用以指示出所希望的同步方向得不到支持。在所有这些情况中，状况包括“param-name”参数，其中值“anchors”指示出命令的“anchors”参数中的元素是不成功状况的成因。另外，接收者可以在命令响应的“params”字典中指示出所希望的同步模式和anchors。

当客户端设备110希望并行地同步多个数据类时，客户端设备110针对每一个数据类发送单独的“sync-start”命令请求，如下面的图28所示。这些命令被包括在同一消息中以使得服务器120能够处理同一同步任务内的命令。当服务器120接受从客户端设备110接收的“sync-start”命令时，客户端设备110开始发送“sync-changes”命令。在已经开始同步的会话期间发送“sync-start”命令产生诸如E_StateError（610）状况之类的状态差错状况。

当在单个会话中同步多个数据类时，用于各个数据类的命令在不同的状态机上操作。通常，服务器120一直等待，直到所有数据类都已完成拉取阶段或者在混合经改变数据之前取消为止。

图14是示出sync-changes命令的示例参数的表格。参数1410可以包括“uri”、“itemtype”、“items”、“anchors”和“idmap”。Uri和itemtype参数的参数类型1420是字符串。Anchors、items和idmap参数的参数类型是字典。表格在第四栏1430示出uri、itemtype和items参数是必需的，而idmap和anchors是可选的。表格还包括这些参数的描述1440。uri参数描述所请求的改变的数据类。Itemtype参数描述在sync-changes命令中标识的项或数据的类型。Items参数描述项的字典，例如取决于itemtype的格式/类型。Items参数的关联键可以是设备recordid。Idmap参数描述GUID-LUID对的字典。关联键是服务器记录id，并且值是设备记录id。Anchors参数可被包括作为“checkpoint anchor”。当存在时，接收器利用所提供来的值来更新其锚。如果会话中断，接收者可以开始与检查点锚的后续同步会话，并继续正常地同步而不会进入慢速同步模式。

Sync-changes命令使得客户端设备110能够将改变发送到服务器120。可替代地，服务器120可将更新发送到客户端设备110。Uri参数指示出要更新或改变的数据项的数据类。正发送的数据项的类型由itemtype参数指示。Itemtype参数可以指示出item参数表示完整记录（“records”）还是字段级改变（“changes”）。当检测到客户端设备110要求id映射时，由设备LUID在items参数中为数据项提供键项（bekeyed）。Items参数的字典的格式取决于项类型。Items参数的值具有齐次的（homogeneous）项类型。Items参数可以是用以指示出无需再发送项的空数组。例如，空数组可以指示出不存在改变或者不存在记录。

当检测到不存在设备改变或者同步模式是“复位”时，客户端设备110利用“items”参数为空数组的“sync-changes”命令。如果用于该数据类的所有适当数据项都不包括在命令参数中，则“more”Boolean标志元素也被包括。“more”Boolean标志元素可用于将量大的同步数据打碎成较小的块。这在要交换的数据的大小大于接收者的接受力时是有用的。例如，接收者可能具有消息大小限制。可替代地，“more”Boolean标志元素可以使能在单个会话中针对给定数据类的多种项类型的交换。当服务器120已经从客户端设备110接收到针对所有数据类的最新的“sync-changes”块时，服务器120将所有提供来的数据与中央数据库相同步。然后，协议会话中的客户端-服务器角色反转。

此时，客户端设备110开始处理来自服务器120的命令。客户端设备110还可向服务器120返回命令响应。来自服务器的任何同步数据更新随后在“sync-changes”命令中被发送。当不需要更新时，服务器120发送“items”参数为空数组的“sync-changes”命令。在处理来自服务器120的“sync-changes”命令请求的同时，客户端设备110对这些命令进行响应，并使用“idmap”参数在命令响应的“params”中包括用于添加事务的任何所要求映射信息。“idmap”参数在来自客户端设备的“sync-changes”命令中被发送用以更新现有映射。例如，可以独立于服务器120改变数据实体而更新id映射。在“sync-start”之前或者“sync-commit”或“sync-cancel”之后的会话期间发送“sync-changes”命令产生差错状况，例如E_StateError（610）状况。客户端设备110可以省略发送“sync-changes”命令响应并推迟发送“idmap”参数，直到后续同步会话的“sync-changes”命令为止。这可被执行来减少完成同步会话所需的传送往返行程的数目。

图15是示出synch-changes命令响应的示例参数的表格。参数1510包括“uri”、“anchors”和“idmap”。表格包括这些参数的参数类型1520。Uri参数是字符串类型，而anchors和idmap参数是字典。表格还包括对参数是否是必需的（1530）的指示。Uri参数是必需的，而anchors和idmap参数是可选的。表格还包括这些参数的描述1540。Uri参数指示出所请求改变的数据类。Anchors参数是用于指示出上一次同步会话停止的特定时间点的检查点锚。Idmap参数是GUID-LUID对的字典，其中键包括服务器记录id。键的值可以包括设备记录id。

图16是示出sync-commit命令的示例参数的表格。Sync-commit命令的参数1610包括“uri”和“anchors”。Sync-commit命令用于交付同步操作。该命令指示出发送者已经交付并且还正在告诉接收者去交付。表格示出了参数是否是必需的（1630）。例如，“uri”参数是必需的，而anchors参数是可选的。

表格还示出了参数的参数类型1620。Uri参数是字符串类型，而anchors参数是字典。表格还示出了参数的描述1640。Uri参数指示出用以交付同步改变的数据类。Anchors参数被客户端设备110用于发送“next_device_anchor”以供服务器120存储。作为响应，服务器120在sync-commit命令中向设备110发送“next_server_anchor”。另外，在sync-commit命令中指示出并返回在下一次同步中要使用的同步模式。在最后的“sync-changes”之前或者在“sync-commit”或“sync-cancel”之后的会话期间发送“sync-commit”命令产生差错状况，例如E_StateError（601）差错状况。

图17是示出sync-commit命令响应的示例参数的表格。参数1710包括“uri”参数。Uri参数的参数类型1720是字符串。如表格第四栏1730所示，uri参数是包括在sync-commit命令响应中的必需参数。Uri参数的描述1740示出：uri参数指示出在同步会话期间交付的数据类。设备110可以省略发送“sync-commit”命令响应以减少完成同步会话所需的传送往返行程的数目。通过将在“sync-commit”命令中接收到的同步锚提交作为下一次会话的“sync-start”命令中的锚参数，服务器120可以推断出前一“sync-commit”已被接收到。

图18是示出sync-cancel命令的示例参数的表格。Sync-cancel命令用于取消同步操作。Sync-cancel命令指示出发送者已经取消并且还正在告诉接收者去取消。接收者应当将其针对该数据类已经作出的任何改变回滚到由上一次接收的同步锚表示的状态。表格示出sync-cancel命令的参数1810包括“uri”参数和anchors参数。Uri参数的参数类型1820是字符串，而anchors参数是字典。表格还在第四栏1830中示出参数是否是必需的。Uri参数是必需的，而anchors参数是可选的。表格还示出了参数的描述1840。Uri参数指示出要取消同步的数据类。Anchors参数可用于指定要针对下一次同步会话使用的锚和/或同步模式。在“sync-start”之前或者在“sync-commit”或“sync-cancel”之后的会话期间发送“sync-cancel”命令产生差错状况，例如E_StateError（610）差错状况。设备110可以省略发送“sync-cancel”命令响应以减少完成同步会话所需的传送往返行程的数目。通过将在“sync-cancel”命令中接收的同步锚提交作为下一次会话的“sync-start”命令中的anchors参数，服务器120可以推断出前一“sync-cancel”已被接收。

图19是示出sync-cancel命令响应的示例参数的表格。该命令响应的可用参数1910包括“uri”参数。Uri参数的参数类型1920是字符串。表格还在第四栏1930中示出了对参数是否是必需的指示。如核选标记所示，uri参数必需包括在命令响应中。表格还包括uri参数的描述1940。Uri参数指示出要取消同步的数据类。

状况

图20是示出示例状况元素的表格。示例状况元素示出在第一栏2010中，而相应的值示出在第二栏2020中。表格的第三栏2030示出了状况元素是否是必需的。此外，表格的最后一栏2040示出了对每一状况元素的简短描述。

通过对给定命令或消息进行处理而产生的状况由“status”元素表示。单个状况元素可以出现在消息头部中。当消息未被处理时，相应的状况元素被包括在消息头部中。一数组的“状况”元素被包括在命令响应的“results”参数中。

状况元素指示出命令请求的结果。状况项是字典。字典可以包含“status”元素并包括“code”元素，用以指示出相应命令请求的结果状况。“status”元素的值是字符串。“code”元素的值包括整数字符串或整数。“description”元素是可以存在于命令中的可选元素。“description”元素的值是字符串。“description”元素纯粹是信息并且对命令的处理不具有影响。

可以存在“param-name”、“param-key”和“param-index”。它们被用于为某些命令提供多状况响应。“param-name”值必须是字符串，并且指示出Status项对应于命令请求中的哪个参数。“param-index”值必须是字符串或者整数。如果“param-name”元素存在并且其在命令请求中的值是数组，则“param-index”必须存在。“param-index”的值指示出命令请求中该Status项所对应的“param-name”项的索引。索引值是基于零的。“param-key”值必须是字符串。如果“param-name”元素存在并且其在命令请求中的值是字典，则“param-key”必须存在。“param-key”的值指示出命令请求中该Status项所对应的“param-name”项的键的值。

“param-name”、“param-key”和“param-index”元素也可存在。它们并不是必需元素，并且可用于为某些命令提供多状况响应。“param-name”状况元素的值是字符串，其指示出该状况元素对应于命令请求中的哪个参数。“param-index”元素的值可以是字符串或者整数。当“param-name”状况元素存在并且与命令请求中的“param-name”状况元素的值相匹配的参数值是数组时，“param-index”状况元素被包括在状况字典中。“param-index”状况元素的值指示出名称与命令请求中status元素所对应的“param-name”状况元素的值相对应的参数在数组参数项中的索引。索引状况元素的值是基于零的。“param-key”元素的值是字符串，其指示出该状况元素对应于命令请求中的哪个参数。“param-key”状况元素的值是字符串。当“param-name”状况元素存在并且与命令请求中“aparam-name”状况元素的值相匹配的参数值为字典时，“param-key”状况元素被包括在状况字典中。“param-index”状况元素的值指示出名称与命令请求中status元素所对应的“param-name”状况元素的值相对应的参数在字典参数项中的键。

如果原始参数是数组，则状况中的索引指的是产生该状况的参数的索引。索引从零基础开始计数。该零基础机制使得能够返回一稀疏数组的状况。例如，考虑下面示出的命令（名称为“examplecommand”），该命令具有作为数组的参数“items”。假设命令中除了两个项以外的所有项都形成良好，而第二和第五项具有值（“bad”）。

<dict>

<key>name</key>

<string>examplecommand</string>

<key>sequence</key><string>3</string>

<key>params</key>

<dict>

<key>items</key>

<array>

<string>good</string>

<string>bad</string>

<string>good</string>

<string>good</string>

<string>bad</string>

<string>good</string>

<string>good</string>

</array>

</dict>

</dict>

对上述“examplecommand”的命令响应可以呈现如下：

<dict>

<key>name</key>

<string>examplecommand</string>

<key>sequence</key><string>3</string>

<key>response</key><true/>

<key>result</key>

<array>

<dict>

<key>code</key>

<string>602</string>

<key>status</key>

<string>S_Ok</string>

</dict>

<dict>

<key>code</key>

<string>607</string>

<key>param-name</key>

<string>items</string>

<key>param-index</key>

<string>1</string>

</dict>

<dict>

<key>code</key>

<string>607</string>

<key>param-name</key>

<string>items</string>

<key>param-index</key>

<string>4</string>

</dict>

</array>

</dict>

这示出对于除了被指示为成功的项以外的所有项，要针对该命令返回多个状况。但是，为索引为1（从零开始计数，因此是命令列表中的第二项）的参数“items”提供的值是坏值（状况码为607）。第五项（索引4）也是相同情况。这种机制使得对于成功的任何其它项可不报告状况。这种机制能够在向服务器发送大量项并且仅少量失败时显著地减少带宽利用要求。

当需要在单个命令响应中返回多个状况时，可通过包括诸如S_MultiStatus（601）之类的状况作为状况数组的第一元素来表示状况的稀疏数组。后续的状况元素于是可以为参数类型为数组的任何失败的参数元素指示出参数索引值和不同状况。可替代地，后续状况元素可以为参数类型为字典的任何失败的参数元素指示出参数键值和不同状况。

对于一般状况，可以保留诸如状况码范围600-699之类的某一范围内的状况码。对于由服务器返回的并且一般导致当前会话终止的差错，可以保留诸如范围700-799之类的另一范围内的状况码。

图21是示出可包括在命令和命令响应中的状况的示例状况码的表格。第一栏2110描述可用状况。关联状况码示出在第二栏2120中。第三栏2130示出对各个状况的描述。最后一栏2140示出各个状况的父元素或参数。

表格描述了成功状况和差错状况。在图21所示的示例中，向“S_OK”状况指派了码600用以指示成功。父元素可以是消息头部或命令响应。另一成功状况是被指派给码601的“S-MultiStatus”状况用以指示具有多值状况的成功。父元素是命令响应。

差错状况包括被指派给码602的“E_NotCompleted”状况，用以指示出对该命令的命令处理尚未完成。父元素是命令响应。“E_NotFound”差错状况被指派给码603，用以指示出所指示的数据对象或URI找不到。父元素是命令响应。“E_NotAllowed”差错状况被指派给码604，用以指示出可能由于例如不足的访问权限，所以操作不被允许。父元素是命令响应。“E_MissingParam”差错状况被指派给码605，用以指示出命令缺失必需参数。“E_ParamError”差错状况被指派给码606，用以指示出所提供来的参数是错误的。父元素是命令响应。“E_BadValue”差错状况被指派给码607，用以指示出提供了坏值。父元素是消息头部或命令响应。“E_UnknownCommand”被指派给码608用以指示出未知命令被发出并被忽略。父元素是命令响应。“E_CommandNotProcessed”差错状况被指派给码609用以指示出由于处理前一命令的差错导致命令未被处理。父元素是命令响应。“E_StateError”是被指派给码610的差错状况，用以指示出基于命令族的当前状态机接收到了预期以外的命令。父元素是命令响应。“E_LimitExceeded”差错状况被指派给了码611，用以指示提供来太多的项。父元素是命令响应。“E_VersionNotSupported”差错状况被指派给码612，用以指示协议或命令版本得不到支持。父元素是消息头部或命令响应。“E_NegotiationFailed”差错状况被指派给码613，用以指示同步模式协商失败。父元素是命令响应。“E_NotSupported”差错状况被指派给码614，用以指示出尝试了得不到支持的或者未实施的操作。父元素是消息头部或命令响应。“E_Failed”差错状况被指派给码615，用以指示一般故障。父元素是消息头部或命令响应。“E_Canceled”差错状况被指派给码616，用以指示出当前状态机已被取消。父元素是命令响应。“E_ServiceBusy”差错状况被指派给码700，用以指示服务器120太忙并且无法处理该消息。此状况码还指示出设备110应当很快就再次尝试该命令。父码是消息头部。“E_ServiceUnavailable”差错状况被指派给码701用以指示服务器120不能工作并且无法处理该消息。此状况码还指示出设备110应当很快再次尝试。父元素是消息头部。“E_ServiceError”差错状况被指派给码702用以指示服务器120具有内部差错。父元素是消息头部或命令响应。“E_BadRequest”差错状况被指派给码703用以指示服务器120无法理解该消息。父元素是消息头部。“E_RetryLater”差错状况被指派给码704用以指示服务器120需要客户端设备110稍后再试。父元素是消息头部。

图22是示出接收命令的给定状况的效果的表格。指示符“C”指示出仅接收到状况的该命令出故障。指示符“F”指示出命令族状态机的终止。“sync”命令的状态机的终止示例是对“sync-cancel”即将到来的指示。指示符“M”指示出消息未被处理。指示符“S”指示出会话将终止。

接收到“E_NotFound”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_NotAllowed”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_MissingParam”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。另外，消息不被处理。接收到“E_ParamError”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_BadValue”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。另外，消息不被处理。接收到“E_UnknownCommand”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_CommandNotProcessed”差错状况的效果是get、put和delete、sync-start、sync-changes、sync-cancel和sync-commit命令出故障。接收到“E_StateError”差错状况的效果是对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_LimitExceeded”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。另外，消息不被处理。接收到“E_VersionNotSupported”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。另外，会话将终止。接收到“E_NegotiationFailed”差错状况的效果是sync-start命令出故障。接收到“E_NotSupported”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_Failed”差错状况的效果是get、put和delete命令出故障。对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。另外，会话将终止。接收到“E_Canceled”差错状况的效果是对于sync-start、sync-changes、sync-cancel和sync-commit命令，数据类状态机被终止。接收到“E_ServiceBusy”差错状况的效果是会话将被终止。接收到“E_ServiceUnavailable”差错状况的效果是会话将被终止。接收到“E_ServiceError”差错状况的效果是对于所有命令，会话都将终止。接收到“E_BadRequest”差错状况的效果是会话将被终止。接收到“E_RetryLater”差错状况的效果是会话将被终止。

锚

在不同时间在设备和服务器之间交换诸如同步模式、同步方向、代理版本和同步锚之类的同步状态信息。包括在命令和命令响应中的“anchors”元素（如图12-20所示）被用于捆绑此信息。“anchors”元素被实现为字典。

图23是示出anchors元素的示例键的表格。表格包括示出同步锚键2310、关联键类型2320和键的描述2330的栏。“mode”键表示所需的或经过协商的同步模式。Mode键可以可选地存在于anchors元素中。当存在时，mode键的值被实现为字符串，并且字符串值包括表示同步模式的“慢速”、“快速”或“复位”。当mode键的值不存在时，消息的接收者推断值为“快速”。因此，在发送者没有指示mode键值的情况下，接收者假设快速同步模式。

“direction”键表示所需的或经过协商的同步方向。Direction键的值可以可选地存在于anchors元素中。当存在时，direction键的值被实现为字符串，并且字符串值可以包括“to_server”、“to_device”或“twoway”。因此，三个值将同步方向指示为从设备110向服务器120同步、从服务器120向设备110同步或者两个方向都同步。当direction键的值不存在时，接收者推断该值为“twoway”。

“device_version”键由设备110发送并且表示设备的数据源代理版本。当存在时，device_version键的值被实现为字符串。此信息可被服务器120用于推断特定于设备软件的给定版本的行为或能力。服务器120例如可以确定：对于给定设备代理版本，同步不被允许。

“server_version”键由服务器120发送并且表示服务器的数据源代理版本。当存在时，server_version键的值被实现为字符串。此信息可被设备110用于推断特定于服务器软件的给定版本的行为或能力。设备110例如可以确定：对于给定服务器代理版本，同步不被允许。

实际的锚被使用键“last_device_anchor”、“next_device_anchor”、“last_server_anchor”和“next_server_anchor”来交换。这些键的每一个的值可以存在于“anchors”字典中。当存在时，这些键中每一个的值被实现为字符串。当不存在时，接收者推断这些键的上一次已知值。

Anchors元素的键的值被认为是不透明的，并且实体不应当尝试从另一实体的anchor键解码或推断含义。例如，客户端设备不应当对“next_server_anchor”或“last_server_anchor”作出任何假设。

同步协议特征

当客户端设备110向服务器120发送差异（即，改变的、删除的或新的数据）时，客户端设备110经由“sync-changes”命令的“item-type”参数指示出使用的是“记录级差异”（RLD）还是“字段级差异”（FLD）。“item-type”参数中的值“改变”指示出FLD，而值“记录”指示出RLD。对于特定数据类，支持RLD的设备针对给定的经改变记录发送整个数据集。与之不同，支持FLD的设备仅发送该数据类的数据集中针对经改变记录的经改变特性。

对于RLD，支持优化，这使得客户端设备110能够发送诸如指示出给定特性未被改变并且尚未被删除的“+**no—change**+”之类的特殊值。这有助于避免发送大的数据项，例如未被改变的联系人图像。

Id映射

当检测到针对一数据类的例如在客户端设备110中的数据存储库希望使用id映射时，可在来自服务器120的命令或者针对“sync-changes”命令的命令响应中包括“idmap”参数。“idmap”参数的值是字典，其将服务器的通用唯一标识（UUID）映射到客户端设备110的本地唯一标识（LUID）。之后，服务器120使用客户端设备110的LUID来参考所映射的实体。

优化

断开的会话可能导致无线通信的消息/分组丢失。同步协议140使能从断开的会话恢复而无需放弃“快速”同步。通过即使在断开会话的情况下也维持“快速”同步，通信往返行程的数目得以减少。往返行程的数目的减少可以降低或最小化消息/分组丢失。

同步协议140被设计为使得在正常情形下传送消息（HTTP请求/响应往返行程）的数目最小化。保持在“快速”同步模式的能力可以通过交换较少量的数据来最小化带宽利用率以及用于每一次同步处理的努力。并且，频繁的快速同步意味着设备110/服务器120对决不会彼此偏离很多。换而言之，设备110和服务器120保持比没有快速同步的可能情况更加同步。此外，这种无线“滴流式同步”（trickle syncing）能够产生更好的用户体验。

某些事件会导致快速同步对（例如，客户端设备110和服务器120对）采取较不高效的同步模式（例如，慢速同步模式）。这些事件可以包括设备数据破坏、中断的同步会话、未能对一致的同步锚达成一致意见、数据结构复位（例如，当用户从另一机器推送针对该数据类的全新数据集时）。无论何时发生问题，同步协议140都可以避免悲观并最小化或者消除回退到慢速同步的需要。

同步协议140实现了用于优化客户端设备110与服务器120之间的数据同步的各种技术。例如，优化技术包括使能乐观的协商和交付的同步阶段压缩；并行地实现多个数据类状态机；使用同步锚检查点；以及使能会话鲁棒性。

图24示出了同步会话的一个示例。客户端设备110与服务器120之间的同步会话包括交换各种消息2410、2420、2430、2440、2450和2460。例如，消息12410被发送者发送到接收者。在图24所示的示例中，发送者是客户端设备110，接收者是服务器120。消息12410包括用于协商同步会话的同步模式的sync-start命令。响应于消息12310，接收者发送消息22420，消息22420包括诸如sync-start命令响应之类的命令响应。命令响应包括用于指示出消息12410中包括的命令是成功还是失败等的状况。在消息22420的结尾处，第一往返行程结束。如果需要，可以交换附加消息n、n+1、n+2等来完成同步会话。同步会话例如可以结束于对最后一个消息n+1的接收。在一些实现方式中，可以交换附加的可选消息2450、2460等。

图25示出了客户端设备110与服务器120之间的最佳快速或复位数据同步的示例。同步阶段压缩使得客户端设备110能够压缩不同的同步状态机阶段。例如，当客户端设备110相信可能的同步模式将是“快速”或“复位”时，客户端设备110在第一消息2510中向服务器120发送协商（“sync-start”）和拉取阶段命令（“sync-changes”）。同步阶段压缩可以在服务器120拒绝所请求的同步模式的情况下最小化或者消除浪费的网络流量。在图25所示的示例中，客户端设备110发送的第一消息2510包括“sync-start”和“sync-change”命令。但是，服务器120可以不在第二消息2520中发送“sync-commit”命令。取而代之，服务器120在第二消息2520中发送“sync-start”响应、“sync-changes”响应和“sync-changes”命令。在第二往返行程2530中，客户端设备110发送sync-change响应和“sync-commit”命令。服务器120利用“sync-commit”响应来作出应答。

图26示出了客户端设备110与服务器120之间的最佳快速或复位同步的另一示例。客户端设备110在第一消息2610中向服务器120发送协商（“sync-start”）和拉取阶段命令（“sync-changes”）。Sync-start协商命令可以包括指示出数据类、锚和同步模式的参数。在图26所示的示例中，指示出快速同步模式。

在图26所示的示例中，同步服务器120通过在同一消息中发送其针对给定数据类的“sync-changes”和“sync-commit”命令来压缩推送和交付阶段。响应于sync-start和sync-change命令，服务器120在第二消息2620中利用sync-start命令响应（OK、数据类、锚）和sync-change命令响应（OK、数据类）进行答复。另外，服务器120还在第二消息2620中包括sync-changes命令（数据类、改变）和sync-commit命令（数据类、锚）以完成一个往返行程。因此，乐观方法可以在单个HTTP往返行程中完成数据同步。

当客户端设备110在第二往返行程2630中利用用于id映射的可选消息来对服务器120在第二消息2620中的“sync-changes”命令作出响应时，数据同步可在两个往返行程中完成。客户端设备110还可在可选消息中发送sync-commit响应。

在一些实现方式中，客户端设备110可以推迟向服务器120发送id映射直到后一会话为止，并且可以省略发送sync-commit响应，这是因为服务器120能够通过对在后续会话中发送的同步锚进行比较来推断出命令已被接收并被处理。图27示出了客户端与服务器之间的示例数据同步，其中，当服务器的前一消息是最后消息时，设备省略发送针对“sync-changes”或“sync-commit”的命令响应。在该情况中，任何待决的id映射（如果有必要的话）都在后续同步会话中被发送到服务器120。

在第一消息2710中，客户端设备110如参考图25所述地对协商和拉取阶段进行压缩。作为响应，服务器120发送第二消息2720，其中，如参考图26所述地对推送和交付阶段进行了压缩。第一会话在一个往返行程中完成。

第二同步会话由客户端设备110发起，其中，在第三消息2730中压缩了拉取和协商阶段。另外，第一会话所余留的待决id映射被发送到服务器120。服务器120在第四消息2740中响应以sync-changes和sync-commit命令。

图28图示出了慢速同步的示例。当客户端设备110相信下一同步模式将是“慢速”同步模式时，客户端设备110不对协商和拉取阶段进行压缩，这是因为在初始请求消息2810中向服务器120发送其整个数据集相对于例如处理成本而言是昂贵的。另外，当检测到服务器120已经协商到“复位”同步模式时，发送数据将浪费带宽。

在此慢速同步模式中，客户端设备110在第一消息2810中发送sync-start命令，其中表明了数据类、锚和慢速同步模式。服务器120在第二消息2820中响应以sync-start响应。在第三消息2830（第二往返行程）中，客户端设备110发送针对数据类的sync-changes命令。服务器120在下一消息2840中通过包括sync-changes响应（OK、数据类）、sync-changes命令（数据类）和sync-commit命令（数据类、锚）来作出响应。在第三往返行程2850中，客户端设备110发送sync-changes响应（OK、数据类、idmap）和sync-commit响应（OK）。

图29示出了并行地同步多个数据类的示例。并行地实现多个数据类状态机（“parallelism”）使得能够并行地同步多个数据类。如在所有“sync”族命令中的“uri”必需参数所指定的每一个数据类操作其自身的独特状态机。因此，在最佳情况中，所有数据类可在单个传送往返行程中快速同步。与之相比，诸如开放移动联盟——数据同步协议（以前称为SyncML协议）OMA DS/SyncML之类的其它同步协议串行地进行同步并且对于每一数据类可能要求5个或者更多往返行程。

在图29所示的示例中，对诸如联系人、日历和书签之类的多个数据类进行并行同步。在第一消息2810中，客户端设备110并行地发送针对这些数据类的sync-start命令。在同一消息2910中，客户端设备110还发送针对多个数据类的sync-changes命令。服务器120发送具有针对多个数据类的sync-start响应和sync-changes响应的响应2920。例如，来自服务器120的sync-start响应说明日历数据类由于失败的协商而在服务器120上被复位。另外，针对日历的sync-changes响应说明针对日历数据类尚未对改变进行处理。如sync-start响应的OK状况所示，针对联系人和书签的sync-start命令是成功的。如sync-changes响应的S_NotCompleted状况所示，针对联系人和书签的sync-changes命令尚未完成。

在下一消息2930中，客户端设备110发送请求复位同步（服务器在前一日历sync-start命令响应中所请求的同步模式）的另一sync-start命令以及针对日历数据类的具有空的项参数的sync-changes命令。服务器120在下一消息2940中响应以：针对联系人、日历和书签数据类的sync-start响应和sync-changes响应；针对联系人和书签的sync-changes响应；针对日历的指示出有更多改变未决的sync-changes命令；以及针对联系人和书签的sync-commit命令。这两个消息2930和2940组成了第二往返行程。

第三往返行程开始于来自客户端设备的消息2950，其中具有针对联系人、日历和书签的sync-changes响应。消息2950包括针对联系人和书签的sync-commit响应。为了完成第三往返行程，服务器120在下一消息2960中向客户端设备110发送针对数据类的sync-changes命令和sync-commit命令。这样，仅在三个传送协议往返行程中，就可以完成多数据类同步，同步模式再次协商（日历在服务器上被复位），以及分割sync-changes（来自服务器的日历改变在消息2940和消息2960中被发送）。

可选的第四往返行程2970可被实现来使得客户端设备110能够向服务器120发送针对日历的具有idmap的sync-changes响应和sync-commit响应。

服务器120不执行混合阶段，直到所有数据类都已完成拉取阶段（即，接收到第三消息）为止。这使得服务器120能够在单个同步任务中执行所有工作。服务器针对其它数据类发送S_NotCompleted，直到针对所有数据类的所有客户端110改变都已被服务器120接收为止。

同步锚检查点

同步协议使用命令和命令响应中的“同步锚”参数来组织和维持可跟踪的同步会话。服务器120可以相对其内部版本化方法来管理命令和命令响应中的锚。

同步锚是客户端设备110与服务器120在同步处理期间交换的不透明数据。然后，在交付阶段，新的一组锚可被交换并坚持以供后面的同步会话期间使用。作为比较，其它同步协议使用在同步会话开始时的锚，并且仅在同步会话成功完成时更新锚，或者如果会话被取消或者预期以外地终止则将锚回滚。

协商期间在预期锚与实际锚之间的任何差别（称为锚失配）会产生慢速同步，或者至少是重传来自失败的同步会话的所有数据。在不可靠的数据网络上，这会导致如下情形：其中，没有任何进展并且与服务器的同步被有利地阻止成功完成同步，直到外部条件改变为止。预期以外的会话故障也会导致在下一个同步会话上的锚失配。

OTA同步协议140使得服务器120能够在同步会话期间的不同检查点可选地返回经更新的锚。“anchor”参数可以存在于任何sync族命令或命令响应中。检查点锚包含“next_server_anchor”元素并且可以包含“mode”元素。这使得能够对同步锚进行细粒度的更新以降低锚失配的可能性和影响。每一个服务器锚被利用如下信息来编码：该信息向服务器120提供与在锚被生成时的内部服务器状态有关的精确信息。例如，可利用如下信息对服务器锚进行编码：该信息是关于从客户端设备110请求的改变是否已与中央数据库混合的。也可利用关于客户端设备110已接受哪些更新的信息来编码服务器锚。此外，还可利用关于同步会话是否被正常完成的信息来编码服务器锚。服务器锚中可编码其它内部服务器状态。

响应于客户端设备的最后“sync-changes”命令，示例锚检查点可以包括“服务器混合阶段的结尾”。锚检查点还可包括在分割的“sync-changes”和交付阶段等等的点。

服务器120可智能地决定添加检查点锚的时间和位置。当检查点锚被放置在“sync-changes”命令中时，检查点锚保证接收到的数据集强制实施数据类的格局的数据完整性要求。例如，数据完整性要求可以包括：与添加了检查点的数据集中的未知实体无关。在拉取阶段完成之后，即使同步会话被取消，也可由客户端设备110保存最近的检查点锚。

当不再需要检查点锚时，或者当服务器需要释放关联的服务器侧的用于维持检查点状态的资源时，服务器120将使检查点锚到期。当客户端设备110提供未知的或者到期的检查点锚时，同步会话将仍然进入慢速同步模式。

在下一个同步会话协商阶段，即“sync-start”命令期间，客户端设备110将其最后保存的锚发送给服务器120。服务器120使用编码在这些锚中的信息来从最近保存的检查点开始同步会话，即使前一同步会话预期以外地终止或者“sync-commit”命令响应未被显式地返回到服务器120也是如此。当客户端设备110在同步会话期间接收到这样的锚时，客户端设备110保留来自服务器的最近的锚，并保存其值以在用于下一同步会话的“sync-start”命令中发送。

图30示出了使用检查点锚的示例同步会话。客户端设备110通过发送消息3010来发起同步会话。客户端设备110在消息3010中使用锚a0。该锚a0可以是来自前一同步会话的最近的服务器锚值。客户端设备110和服务器120按需交换其它消息3020、3030、3040、3050和3060。在同步会话的不同点处，服务器120使用这些消息3020、3030、3040、3050和3060来返回检查点锚a1、a2和a3。

在接收和处理来自服务器120的包含“anchors”元素的各个消息时，客户端设备110对其锚进行更新。当同步会话中断或者消息丢失时，客户端设备在下一会话的“sync-start”命令中提供其成功处理了的最近锚。取决于接收到哪个锚值，客户端设备110可以按需推断必须采取哪些动作来完成前一个同步。因此，即使在极其脆弱的无线网络上或者在需要发送大数据集时也可实现递增的同步进展。

图31是示出示例检查点锚的表格。表格包括描述可能的检查点锚3110、关联的同步阶段3120和与检查点锚相关联的服务器状态3130的栏。例如，锚a0可以表示协商阶段，其没有引起服务器状态的改变。锚a1可以表示推送阶段。服务器120应用客户端设备110所请求的改变，并且服务器120将其改变的第1部分发送到客户端设备110。锚a2可以表示由服务器110发起的推送阶段。服务器将其改变的第2部分发送到客户端设备110。锚a3可以表示交付阶段并且用信号通知交付改变已经完成。该锚用信号通知同步会话已经完成。

设备设定

同步协议120提供了一种供服务器120动态地请求设备设定和能力的机制。“get”和“put”命令可用于交换信息。在任何时候，服务器120都可发送例如“uri”参数具有值“deviceinfo”的“get”命令以请求设备设定和能力。可替代地，客户端设备110可向服务器120发送具有相同“uri”参数的“put”命令。“uri”参数的值是包含各种键-值对的字典。当存在时，“userid”的值表示认证的主要用户并且被实现为字符串。当存在时，“authtype”的值表示认证方案并且被实现为字符串。当存在时，“auth”的值表示认证证书并且被表示为字符串。当接收者想要执行操作时，接收者返回诸如状况S_OK（600）之类的成功状况。当所请求的URI是未知的时，接收者返回诸如状况E_NotFound（603）之类的状况用以指示出该URI未被找到并且是未知的。当所请求的操作不被允许时，例如，经授权的主要用户不被允许删除URI时，接收者返回诸如状况E_NotAllowed（604）之类的状况用以指示出所请求的操作不被允许。当所请求的操作由于提供来的数据错误而无法执行时，接收者返回诸如状况E_BadValue（607）之类的状况用以指示出所请求的操作无法执行。当所请求的操作由于提供来的“itemtype”错误而无法执行时，接收者返回诸如状况E_NotSupported（614）之类的状况用以指示出所请求的操作得不到支持。

图32示出了针对“uri”参数的示例键-值对的表格。“uri”参数的可用键3210包括version、msisdn、deviceid、name、model、carrier和dataclasses。Version、msisdn、deviceid、name、model和carrier键的关联值3220是字符串值。Dataclasses键的值3220是字典。表格还示出了对这些键的关联描述3230。例如，version键-值可以描述产品版本，例如版本1.1.4。Msisdn键-值可以描述当前安装的SIM卡的电话号码。Deviceid键-值可以描述ICCID。Name键-值可以描述用户设备的名称，例如EctoPhone。Model键-值可以描述客户端设备110的机型，例如

等等。Carrier键-值可以描述电信公司名称，例如

等等。Dataclasses键-值可以描述。

当客户端设备110第一次与服务器120同步时，服务器120通过发送“get”命令来请求设备信息。之后，当设备信息改变时，客户端设备110通过发送“put”命令来将经改变的设备信息发送到服务器120。

过滤

过滤是基于数据项中的值来约束与客户端设备110同步的数据项集合的能力。例如，用户可能仅想同步某一群组集合中包含的联系人，或者在围绕当前日期的某一时间窗内的日历事件。

在诸如

过滤器之类的数据共享/管理应用中，在线缆同步期间由计算机强制实施设定以对发送到诸如

之类的客户端设备110的数据项集合进行约束或过滤。同步协议140在无线同步解决方案中提供类似的过滤功能。由服务器120强制实施来自

的相同过滤器设定而无需任何用户动作。因此，可自动执行过滤。可替代地，可向用户呈现在客户端设备110上的用户接口（UI）以使得用户能够显示并编辑要强制实施的过滤器设定。

同步协议140使得能够使用基原命令在客户端设备110与服务器120之间交换过滤器设定。使用“dataclass/<dataclassname>/filter”形式的“uri”参数来指定过滤器信息。过滤器信息的值是字典。

图33是示出过滤器设定的示例键-值对的表格。过滤器设定的可用键3310包括default_container、constrain_containers和discard_after_days。这些过滤器设定键的值3320分别是字符串、数组和字符串。Default_container键的数据类120包括联系人和日历。此外，Constrain_constrainers键的数据类120也包括联系人和日历。Discard_after_days键的数据类120包括日历。

Default_container键描述容器实体的标识（LUID），例如联系人的群组ID和事件的日历ID。Constrain_containers键描述要包括的容器实体的LUID的集合，例如要包括的群组的集合。Discard_after_days键描述如下天数：在该天数以后，比所描述的天数旧的事件应当被删除。

图34是以伪巴科斯诺尔范式（pseudo BNF，Backus-Naur Form）的图示的示例。伪巴科斯诺尔范式是描述句法（syntax）的一种快捷方式。BNF是使能对上下文无关语法的表达的元句法。上下文无关语法可以通过使用两组规则来定义编程语言的句法，这两组规则是词法规则（Lexicalrule）和句法规则（Syntactic rule）。增广型BNF是BNF的修改版本，其使用不同的命名规则、重复、替代、顺序独立性和值范围。

图35示出了示例同步会话。图35所示的示例同步会话包括经分割的sync-changes和放入的过滤器信息。客户端设备110在第一消息3510中向服务器120发送协商阶段命令（“sync-start”）和拉取阶段命令（“sync-changes”）。Put命令被用于发送针对特定数据类的数据项。在图35所示的示例中，put命令中指示出的数据类是联系人。此外，数据项被过滤以约束针对该数据类要同步的数据。

在第二消息3520中，服务器120通过发送具有状况“S_OK”的sync-start命令响应来作出响应以指示出联系人数据类的成功协商。另外，anchors被用于指示出检查点。此外，服务器120还发送针对联系人数据类的具有“more”Boolean标志的sync-changes命令，其中，“more”Boolean标志指示出并非针对该数据类的所有适当数据项都包括在命令参数中。此外，第二消息3520可以包括put命令响应，其中具有指示出成功放入的“S_OK”状况。

在第三消息3530中，客户端设备110包括sync-changes命令响应，其具有针对联系人数据类的由uri参数指示出的“S_OK”状况。此外，例如idmap被包括以提供GUID-LUID映射。在第四消息3540中，服务器120发送sync-changes命令，其具有指示出联系人数据类的uri参数。此外，“more”Boolean被包括以指示出后面将跟随其它数据。在第五消息3550中，客户端设备110发送sync-changes命令响应，其具有状况“S_OK”用以指示出对联系人数据类的成功更新。在第六消息3560中，服务器120发送针对联系人数据类的sync-changes命令和sync-commit命令。客户端设备110在第七消息3570中利用指示出成功更新的sync-changes命令响应来作出响应。客户端设备110还包括sync-commit响应（OK）用以指示出客户端设备已交付改变。最后一个消息3580具有空的消息主体用以指示出同步会话的最后一个消息。

图36、37a、37b、38a、38b、38c、38d、39a、39b、39c、40a和40b表示同步会话的线迹（Wiretrace）示例。图36示出用于复位同步会话的四种示例消息的概要。图37a和37b示出从客户端设备110发送到服务器120的示例消息。Sync-start命令包括值为“com.apple.Contacts”的指示出数据类的uri参数。此外，同步模式被指示为“复位”。消息还包括具有相同数据类（com.apple.Contacts）和空的改变的sync-changes命令。

图38a、38b、38c和38d示出了从服务器120发送到客户端设备110的示例消息。服务器120发送sync-start命令响应，其具有状况“S_OK”用以指示出成功协商。该消息还包括sync-changes命令响应，其具有状况“S_OK”用以指示出成功的数据更新。另外，服务器120还包括sync-changes命令，其发送一个联系人、电话号码和电子邮件地址。服务器120还发送get命令以从客户端设备110拉取设备信息。

图39a、39b和39c示出了从客户端设备110发送的示例消息。该消息包括sync-changes命令响应，其具有状况“S_OK”用以指示出对改变后的数据项的成功更新。Idmap参数被提供来指示出GUID到LUID的映射。消息还包括get命令响应，其具有状况“S_OK”用以指示出在返回设备信息方面的成功获取操作。此外，消息还包括sync-commit命令用以指示出客户端设备110已经交付并且服务器120也应当交付。

图40a和40b示出了从服务器120发送的示例消息。服务器120发送sync-commit命令响应，其具有状况“S_OK”用以指示出服务器120也已交付改变。

图41、42a、42b、43a、43b和43c示出了用于快速同步的示例消息。客户端设备110和服务器120各自具有一次删除。图41示出了用于快速同步的两种示例消息的概要。图42a和42b示出了从客户端设备110发送的用于快速同步的示例消息。该消息包括用于协商阶段的sync-start命令。Uri参数指示出作为com.apple.Contacts的数据类。同步模式被指示为快速。该消息还包括sync-changes命令用以删除针对所指示出的com.apple.Contacts数据类的数据记录。

图43a、43b和43c示出了响应于客户端设备110所发送的消息而从服务器120发送的示例消息。该消息包括具有用以指示出成功协商的状况“S_OK”的sync-start命令响应。该消息还包括sync-changes命令响应，其具有状况“S_OK”用以指示出对客户端设备110所指示的数据记录的成功删除。另外，服务器120还发送sync-changes命令用以请求另一数据记录的删除。在该sync-changes命令中由uri参数指示出了相同的数据类，com.apple.Contacts。因此，此次是由服务器120请求删除来自com.apple.Contacts的另一数据记录。来自服务器120的消息还包括sync-commit命令用以指示出服务器120已交付同步并且客户端设备110也应当交付。

图44a和44b示出了用于同步客户端设备110和服务器120的示例处理。发送者发起（4402）与接收者的协商阶段。在此示例中，发送者是客户端设备110，而接收者是服务器120。协商阶段是通过发送具有诸如sync-start之类的有状态sync族命令的消息来发起（4402）的。Sync-start命令包括指示出特定数据类的uri参数和可以包括所请求的同步模式、数据存储库版本和/或同步锚的anchors参数。当并行地同步多个数据类时，针对每一个数据类来发送单独的“sync-sart”命令请求。这些并行sync-start命令被包括在同一消息中以使得服务器能够在同一同步任务中对它们进行处理。

服务器120通过向客户端设备110发送具有sync-start命令响应的消息来对协商阶段作出响应（4404）。对协商是否成功进行判断（4406）。对uri参数所指示的数据类进行检测并分析以判断服务器120是否支持并使能该数据类（4424）。当检测到该数据类不被支持时，生成诸如“E_NotSupported（612）”之类的差错状况（4432）。所生成的差错状况可被包括在sync-start命令响应中以指示出数据类得不到支持。当检测到服务器120未使能该数据类时，生成诸如“E_NotAllowed（604）”之类的差错状况。所生成的状况被包括在sync-start命令响应中以指示出该数据类未被使能。当检测到数据类得到支持并且被使能时，生成诸如“S_OK”之类的成功状况（4426）。所生成的状况被包括在sync-start命令响应中用以指示出服务器120支持并且使能了该数据类。

当sync-start命令的anchors参数包括所请求的同步模式时，所请求的同步模式被分析以判断服务器120是否接受（4428）该同步模式。当该同步模式不被服务器120接受时，诸如“E_NegotiationFailed（613）”之类的差错状况被生成（4434）。所生成的状况被包括在sync-start命令响应中以指示出所请求的同步模式不被接受。服务器120可以决定（4436）是否建议使用另外的同步模式。当服务器120想要以另外的模式进行同步时，所建议的另外模式被包括（4438）在sync-start命令响应中的anchors参数中。

当所请求的同步模式被接受时，诸如“S_OK”之类的成功状况被生成（4430）。所生成的成功状况被包括在sync-start命令响应中。

当检测到协商成功时（如“S_OK”状况所指示的），同步会话前进（4408）到拉取阶段。当同步模式为快速时，客户端设备110将经改变的记录发送到服务器120。当同步模式为“慢速”时，所有记录都被发送到服务器120。改变被使用sync-changes有状态命令来发送。服务器120利用相应的sync-changes命令响应来对sync-changes命令作出响应，以指示出改变是否已被接受。成功状况“S_OK”指示出改变已被接受。

当所有的改变都已被接收时，服务器120前进（4410）到混合阶段。当在单个会话中对多个数据类进行同步时，针对各个数据类的sync-changes命令将具有不同的状态机。然而，服务器120一直等待直到所有数据类都已完成拉取阶段或者在前进到混合阶段之前取消为止。服务器120可以拒绝任何检测到的无效改变。

在混合阶段期间，服务器判定（4412）对于该数据类是否存在任何冲突。当检测到存在冲突时，服务器120判定（4416）是由其自身解决冲突还是由用户或客户端设备110来解决冲突。在服务器120解决冲突的情况下，服务器120可以依赖于启发法来解决冲突。例如，发起最近的同步的客户端设备110可被选择作为赢家。

对于诸如数据类和/或数据项之类的某些情形，用户/客户端设备110可被选择作为解决冲突的一方。然后，检测到的冲突被发送到客户端设备110以使得客户端设备110能够解决冲突。此外，例如可通过在客户端设备110上的显示单元上显示检测到的冲突来向用户呈现这些冲突。用户可以手动解决冲突。冲突解决的结果随后可在下一同步会话期间被从设备110发送到服务器120。

来自服务器120（接收者）的改变可在推送阶段（4414）期间被发送到客户端设备110。服务器120可向客户端设备发送具有sync-changes命令的消息以将改变推送给客户端设备110。

最后，一旦所有更新都已被接收，就进入交付阶段（4416）。双方一致认定同步成功，坚持它们当前的同步锚，并将所交换的数据交付给它们各自的数据存储库。在交付阶段中，消息是利用sync-commit命令和命令响应来发送的。

此说明书中描述的主题和功能操作的实施例可被实现在数字电子电路中，或者用计算机软件、固件或硬件（包括此说明书中公开的结构以及它们的结构性等同物）或者其中一个或多个的组合来实现。此说明书中描述的主题的实施例可被实现为一个或多个计算机程序产品，即编码在有形程序载体上供数据处理装置执行或者控制数据处理装置的操作的一个或多个计算机程序指令命令。有形程序载体可以是传播信号或者计算机可读介质。传播信号是人工生成的信号，例如机器生成的电信号、光信号或电磁信号，这种人工生成的信号被生成用以对要传送到合适的接收装置以供计算机执行的信息进行编码。计算机可读介质可以是机器可读存储设备、机器可读存储基底、存储设备、实现机器可读传播信号的事物的合成物或者它们中的一项或多项的组合。

术语“数据处理装置”涵盖了用于处理数据所有的装置、设备和机器，例如包括可编程的处理器、计算机、或者多个处理器或计算机。装置除了硬件以外，还可以包括为所涉及的计算机程序创建执行环境的代码，例如构成下述内容的代码：处理器固件、协议栈、数据库管理系统、操作系统、或者它们中一项或多项的组合。

计算机程序（也称为程序、软件、软件应用、脚本、或代码）可以写成任何形式的编程语言，包括编译语言或解释语言，或者表述性或过程性的语言，它可以以任何形式来部署，包括独立的程序或者作为模块、组件、子例程或者适用于计算环境中的其他单元。计算机程序不一定要对应于文件系统中的文件。程序可以被储存在保存其他程序或数据（例如标记语言文档中储存的一个或多个脚本）的文件的一部分中，专用于所涉及的程序的单一文件中，或者多个协作的文件中（例如储存一个或多个模块、子程序或代码部分的多个文件）。计算机程序可以部署成在一个计算机或多个计算机上执行，所述多个计算机位于一个地点或分布在多个地点并由通信网络而互连。

这份说明书中所述的处理和逻辑流程可以由一个或多个可编程处理器来执行，这些处理器执行一个或多个计算机程序来通过对输入数据进行操作并产生输出而执行功能。也可以由专门目的的逻辑电路（例如FPGA（现场可编程门阵列）或ASIC（专用集成电路））来执行这些处理和逻辑流程以及由这些专门目的的逻辑电路来实现装置。

适于执行计算机程序的处理器例如既包括通用和专用目的的微处理器，也包括任何种类的数字计算机的任一个或多个处理器。通常，处理器将从只读存储器、或随机存取存储器、或者这二者接收指令和数据。计算机的主要元件是用于执行指令的处理器以及用于储存指令和数据的一个或多个存储器设备。通常，计算机还会包括用于储存数据的一个或多个海量储存设备（例如磁盘、磁光盘或光盘），或者以可操作的方式耦合来从该设备接收数据、向其传输数据或既接收又传输。但是，计算机不一定要具有这些设备。此外，计算机也可以嵌入另一设备中。

适于储存计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、介质和存储器设备，例如包括半导体存储器设备（例如EPROM、EEPROM和闪存设备）、磁盘（例如内部硬盘或可移动盘）、磁光盘、以及CD ROM和DVD-ROM盘。处理器和存储器可以由专门目的的逻辑电路提供补充，或者结合到其中。

为了提供与用户的交互，这份说明书中所述主题的实施例可以在具有用于向用户显示信息的显示设备（例如CRT（阴极射线管）或LCD（液晶显示）监视器）以及键盘和点选设备（例如鼠标器或轨迹球）的计算机上实现，用户能够通过所述键盘和点选装置来向计算机提供输入。其他种类的设备也可以用来提供与用户的交互，例如，来自用户的输入可以以任何形式被接收，包括声波、语音或触觉输入。

这份说明书中所述主题的实施例可以在下述形式中实现：包括后端组件（例如作为数据服务器）的计算系统、或者包括中间件组件（例如应用服务器）的计算系统、或者包括前端组件（例如客户端计算机，其具有图形用户界面或Web浏览器，用户可以通过它们来与这份说明书中所述主题的实现形式进行交互）的计算系统、或者一个或多个这种后端组件、中间件组件或前端组件的组合。系统的组件可以由任何形式的数字数据通信介质（例如通信网络）来互连。通信网络的示例包括局域网（LAN）和广域网（WAN），例如因特网。

计算系统可以包括客户端和服务器。客户机和服务器通常彼此处于远程，并通常通过通信网络来交互。客户端和服务器的关系起因于运行在相应计算机上、并彼此具有客户端－服务器关系的计算机程序。

尽管这份说明书包含了许多具体细节，但是这些不应认为是对任何发明的或所要求保护的范围的限制，而应作为可以专用于特定发明的特定实施例的特征的描述。这份说明书中以不同实施例的形式描述的某些特征也可以在一个实施例中结合来实现。相反，以单一实施例的形式描述的各个特征也可以在多个实施例中分别实现或者以任何合适的子组合形式来实现。此外，尽管上文可能将多个特征作为以特定组合的形式来作用并且甚至最初如此主张了权利，但在某些情况下，来自所主张权利的组合形式的一个或多个特征也可以从该组合形式中被除去，所主张权利的组合形式也可以针对子组合或者子组合的变形。

类似地，尽管在附图中以特定顺序描述了多个操作，但是这不应认为要求这些操作必须以所示的特定顺序或依次的顺序来执行，或者必须执行全部的所示操作来获得所需的结果。在某些情况下，多任务和并行处理可能是有利的。另外，在上述实施例中各个系统组件的分开不应认为在所有实施例中都要求这种分开，应当明白，所述的程序组件和系统可以大体上一起集成在单一的软件产品或封装在多个软件产品中。

只描述了一些实现形式和示例，根据本申请中所述和所示的内容可以作出其他的实现形式、改进形式和变更形式。

Claims (26)

1.一种在包括两个消息的一个往返行程中同步数据的方法，所述方法包括：

在服务器处，响应于来自至少一个客户端设备的第一消息，发起同步会话，以使与多个数据类相关联的数据与所述至少一个客户端设备同步，其中所述消息包括针对所述多个数据类中的每一个数据类的所提议同步模式；以及

从所述服务器发送第二消息给所述至少一个客户端设备，以完成所述同步会话，所述第二消息包括用于指示每个所提议同步模式的接受或者拒绝的状况码。

2.如权利要求1所述的方法，还包括：

基于所述状况码，使用针对每个数据类的所接受的所提议同步模式或者替换同步模式来同步所述数据。

3.如权利要求1所述的方法，还包括：

在所述服务器处，响应于接收到所述第一消息，并行协商针对所述多个数据类中的每一个数据类的所提议同步模式。

4.一种同步数据的方法，所述方法包括：

在服务器处，响应于来自至少一个客户端设备的第一消息，发起同步会话，以使与多个数据类相关联的数据与所述至少一个客户端设备同步，其中所述消息包括针对所述多个数据类中的每一个数据类的所提议同步模式；

在所述服务器处，响应于接收到所述第一消息，并行协商针对所述多个数据类中的每一个数据类的所提议同步模式；

在所述服务器处，生成指示针对所述多个数据类中的每一个数据类的所提议同步模式是被接受还是被拒绝的状况码；

使用被指派给所述多个数据类中的每一个数据类的所接受的同步模式或者替换同步模式，来发起同步所述数据；

在所述服务器处，检测所述服务器与所述至少一个客户端设备之间的、网络连接中的中断所述同步会话的中断；以及

使用在所述网络中断之前先前被指派给所述多个数据类中的每一个数据类的所接受的同步模式或者替换同步模式，来恢复所述同步会话。

5.如权利要求4所述的方法，还包括：

发送应答消息给所述至少一个客户端设备，所述应答消息包括所生成的状况码。

6.如权利要求4所述的方法，其中，来自所述至少一个客户端设备的消息包括头部和主体，其中所述主体包括命令元素的序列。

7.如权利要求6所述的方法，其中，所述应答消息包括头部和主体，其中所述主体包括命令响应元素的序列。

8.如权利要求7所述的方法，还包括：

为所述消息、所述应答消息、命令元素和命令响应元素的每一者指派唯一标签，以确保适当排序和丢失检测。

9.如权利要求6所述的方法，包括：

在所述消息或者所述应答消息的头部设置标志，其中所述标志指示所述同步会话完成。

10.如权利要求6所述的方法，其中，所述消息或者所述应答消息的头部之一或者两者包括版本号。

11.如权利要求4所述的方法，包括：

指派保持追踪所述同步会话的状态的锚。

12.如权利要求11所述的方法，其中，恢复所述同步会话包括：

使用所指派的锚来标识在所述中断之前所述同步会话的状态。

13.如权利要求4所述的方法，包括：

标识与待同步的数据相关联的冲突；以及

解决所标识的冲突。

14.一种在包括两个消息的一个往返行程中同步数据的设备，所述设备包括：

用于在服务器处，响应于来自至少一个客户端设备的第一消息，发起同步会话，以使与多个数据类相关联的数据与所述至少一个客户端设备同步的装置，其中所述消息包括针对所述多个数据类中的每一个数据类的所提议同步模式；以及

用于从所述服务器发送第二消息给所述至少一个客户端设备，以完成所述同步会话的装置，所述第二消息包括用于指示每个所提议同步模式的接受或者拒绝的状况码。

15.如权利要求14所述的设备，还包括：

用于基于所述状况码，使用针对每个数据类的所接受的所提议同步模式或者替换同步模式来同步所述数据的装置。

16.如权利要求14所述的设备，还包括：

用于在所述服务器处，响应于接收到所述第一消息，并行协商针对所述多个数据类中的每一个数据类的所提议同步模式的装置。

17.一种同步数据的设备，所述设备包括：

用于在服务器处，响应于来自至少一个客户端设备的第一消息，发起同步会话，以使与多个数据类相关联的数据与所述至少一个客户端设备同步的装置，其中所述消息包括针对所述多个数据类中的每一个数据类的所提议同步模式；

用于在所述服务器处，响应于接收到所述第一消息，并行协商针对所述多个数据类中的每一个数据类的所提议同步模式的装置；

用于在所述服务器处，生成指示针对所述多个数据类中的每一个数据类的所提议同步模式是被接受还是被拒绝的状况码的装置；

用于使用被指派给所述多个数据类中的每一个数据类的所接受的同步模式或者替换同步模式，来发起同步所述数据的装置；

用于在所述服务器处，检测所述服务器与所述至少一个客户端设备之间的网络连接中的中断所述同步会话的中断的装置；以及

用于使用在所述网络中断之前先前被指派给所述多个数据类中的每一个数据类的所接受的同步模式或者替换同步模式，来恢复所述同步会话的装置。

18.如权利要求17所述的设备，还包括：

用于发送应答消息给所述至少一个客户端设备的装置，所述应答消息包括所生成的状况码。

19.如权利要求17所述的设备，其中，来自所述至少一个客户端设备的消息包括头部和主体，其中所述主体包括命令元素的序列。

20.如权利要求19所述的设备，其中，所述应答消息包括头部和主体，其中所述主体包括命令响应元素的序列。

21.如权利要求20所述的设备，还包括：

用于为所述消息、所述应答消息、命令元素和命令响应元素的每一者指派唯一标签，以确保适当排序和丢失检测的装置。

22.如权利要求19所述的设备，还包括：

用于在所述消息或者所述应答消息的头部设置标志的装置，其中所述标志指示所述同步会话完成。

23.如权利要求19所述的设备，其中，所述消息或者所述应答消息的头部之一或者两者包括版本号。

24.如权利要求17所述的设备，包括：

用于指派保持追踪所述同步会话的状态的锚的装置。

25.如权利要求24所述的设备，其中，用于恢复同步会话的装置包括：

用于使用所指派的锚来标识在所述中断之前所述同步会话的状态的装置。

26.如权利要求17所述的设备，包括：

用于标识与待同步的数据相关联的冲突的装置；以及

用于解决所标识的冲突的装置。

Images