一、Funambol ds 是用于客户端与云端的数据同步, 包含通讯录, 日历行程, 视频及文件等. 这里主要研究通讯录的同步实现机制, 通讯录的同步应用比较广泛, 对DS(Data Synchronization)的同步具备代表性. 之前讲到的funambol dm, 两者都是基于SyncML, 但是DM是属于设备信息和应用升级包的同步. 两者的数据载体类型不一样, DS更着重于数据的完整性与实时性, 同时, 客户端与云端的增删改操作给数据带来更多的变化性, 要求具备完善的数据变化检测机制, 实现起来相比DM会更复杂些.
二、DS同步类型包含双向同步, 慢同步, 单边客户端同步, 单边服务端同步, 客户端刷新同步,服务端刷新同步. 所谓刷新同步, 其实是把所有数据进行同步, 不去检测区分增删改的数据. 应用最多的是双向同步, 也是实现起来最为复杂的一种. 双向同步要求将客户端的操作所变化的数据更新到云端, 同时, 云端也要将变化的数据传递至客户端更新, 可以作交集, 也可以作并集, 其中两端可能会产生数据冲突, 具体遵照实际业务规则, 目的是保持两端数据的一致性, 完整性.
三、双向同步的简要的交互流程, 请看图1:
从发送请求到结束会话, 主要做了两件事情, 第一, 是把客户端的数据更新至服务端; 第二, 是把云端的数据更新至客户端.
四、具体的协议传输流程, 请看图2:
整个流程主要分为四个步骤:
1. 初始化: 彼此握手, 建立会话, 如果之前没有同步, 第一次进行交互时, 客户端会发送自己的设备信息, 服务端也会发送自己所能支持提供的服务信息, 这些信息包含系统版本, 固件版本, 机型, 同步数据类型, 协议版本等等. 同时, 会在这里判断用户是否合法, 标识本次同步的数据类型.
2. 同步客户端数据: 客户端将增删改数据以VCARD格式传递给云端, funambol ds支持vcard 和sifc两种通讯录格式, 早期使用sifc, 目前vcard应用最为广泛. 服务端会进行检测匹配, 保存数据, 并对每条数据的执行结果反馈给客户端, 如果某条数据失败, 是不会影响到其他数据的同步.
3. 同步服务端数据: 服务端会有相应的检测机制, 去获取需要更新到客户端的数据. 客户端接收数据执行更新后, 同样, 需要将每条数据的执行结果传递给服务端.
4. 结束会话: 两端数据交互完成后, 发送标识, 结束本次会话. 日志记录, 结果统计等操作放在这里会比较合适.
如果有兴趣, 想要更深入的了解, 可以研究下官方的文档:
OMA-SyncML-DataSyncProtocol.pdf
funambol-push-design.odt
funambol-ds-service-design-document.odt