IrMC规范学习笔记（四）

    IrMC(Infrared Mobile Communications 红外移动设备通讯)规范1.1 是由红外数据协会(www.irda.org)制订的，用于无线红外设备的信息传输。目前由于工作需要进行移动电话电话簿的同步开发，对该规范进行了初步的了解和学习，以后我会把IrMC相关规范的中文译文和自己的一些心得发布上来，这也是我现在每天的工作内容。希望有共同兴趣和爱好的朋友一起来交流学习。由于重点是电话簿的同步，所以主要是关于电话簿的内容，而像日历卡片，消息和记事本等内容暂时跳过。

    接着上次的同步锚点，包含两种类型，变更计数器和时间标签，下面分别简单描述一下。

    1. 变更计数器

    在IrMC规范1.1中推荐使用变更计数器同步锚点以减少使用时间标签引起的问题。变更计数器是一个32位无符号整型数据，其值从0到4294967295。每次设备对象库被复位或者使用级别2 OBEX的GET操作存储对象库操作后都要将其设置为0，每次对象库内容被改变时候，包括添加、删除和修改对象库中一个对象的操作，将其值增加1。最近一次变更计数器可以由IrMC客户通过级别4 OBEX的GET命令获取，格式如下：GET "telecom/XX/luid/cc.log"，其中XX是变更计数器对应的对象库的名字，例如，获取电话簿对象库最近一次的变更计数器：GET "telecom/pb/luid/cc.log"。

    2. 时间标签

    IrMC规范也允许使用时间标签同步锚点，标识指定对象被更改和删除的时间。其格式如下所示，例如：世界标准时间（UTC）2005年3月27日下午3时49分20秒表示为，20050327T154920Z。由于存在一些可变因素影响时间标签锚点，所以在信息日志中规定了3个属性来限制该锚点，可参考前面文章了解这3个属性。

    注意，一定要确保当前时间标签锚点的值大于先前记录值。但是现实往往存在当前值小于先前时刻的情况，例如，当设备在旅游时候设置为自动根据时区调整时间，或者用户自己调整了设备的时间等

    另外，还要确保每个对象的时间标签锚点是唯一的。

    当使用该锚点，在使用级别4 OBEX的CONNECT操作时候，要锁定数据库。至于如何进行级别4的连接操作，会在后面详细说明。

数据库标识（Database IDs）

    IrMC设备创建对象库同时为其创建一个对应的数据库标识。数据库标识是一个任意的字符串，IrMC客户通过它可以判断服务器数据库自从上次同步以来是否被复位或者替换。因此，如果数据库被复位，或者被客户通过级别2的PUT操作替换都要重新创建一个数据库标识，而且如果对象库支持变更计数器类型同步锚点，则当计数器的值从最大值4294967295回滚到0的时候，也认为是数据库进行复位并重新创建一个标识。既然每次数据库被替换都要重新创建标识，所以要求标识必须是唯一的。

    IrMC设备提供的信息日志的第二行指定对应对象库的数据库标识。

物理和软删除

    通常情况IrMC客户基于下面两种原因要求服务器进行对象删除操作：

1. 用户在客户端数据库中删除了对象，则同步时候要求服务器也必须删除该对象。
2. 设备空间不足，删除其他对象以容纳其他对象。

    相似的，用户也可能基于下面原因删除设备中的对象：

1. 用户已经不需要一个库中的对象记录。
2. 用户发现设备空间不足，从而删除一些记录来腾出空间。

    那么不论对于上面那种情况，操作的另一方都无法确定删除操作是基于什么目的，是彻底从设备中移除还是只是为了腾出空间。为了解决这个问题，就要求IrMC设备支持区分物理删除和软删除的概念，则操作方根据当前删除操作的具体要求进行相应操作，并为另一方所接受。至于对于支持区分物理删除和软删除的设备如何实施在前面已经详细说明。

变更日志

    变更日志，作为同步的辅助工具用于级别4的信息交换。它提供了一种简单的方法允许客户端获取设备的序列号、数据库标识、最大存储容量和当前存储容量。此外，它还提供自从上次同步以来设备发生变更的最新列表。

    变更日志中发生变更的记录按照时间顺序明确排列，最近的变更在表中最前面的位置。变更日志中关于变更的条目对应于对象库中每个发生变更的特定对象。

    变更日志中关于对象变更的条目都包含以下属性：

• 变更类型（Action）：M表示修改（添加操作也属于此类型），D表示删除或者H表示物理删除。
• 变更计数器（Change Counter）：该属性可选，但是规范推荐使用此属性。如果该属性不存在，则设备必须提供时间标签属性
• 时间标签（Timestamp）：该属性可选，如果该属性不存在，则必须提供变更计数器属性。
• 本地唯一标识（LUID）：发生变更对象的本地唯一标识

    注意：没有必要每次传输整个变更日志，所以为了避免混淆，存储的变更日志要参考存储在IrMC设备上的变更日志，传送的变更日志则参考传送给IrMC客户的变更日志。而且服务器未必一定存储变更日志，它可能在需要时候动态创建变更日志。

    日志可以容纳的记录数目由设备类型确定。如果增加新的变更条目时候日志已满，则会删除最早的条目。日志必须足够大以便能够容纳同步时候所有的变更。

    1. 获取变更日志

     IrMC客户可以通过使用类似下面的OBEX的GET操作获取设备变更日志：“GET telecom/XX/luid/#####.log”   ，其中XX是指定的对象库名称，#####标识同步锚点的值。例如，如果使用变更计数器锚点，则telecom/pb/luid/123.log表示客户端希望获取电话簿对象库所有大于123的变更记录；而telecom/pb/luid/20050328T150000Z.log表示客户端希望获取电话簿对象库所有2005年3月28号下午3点以后的变更记录。如果设备是第一次被请求变更日志，则客户端根据锚点类型分别指定0.log和19000101T000000Z.log日志对象进行请求，服务器则负责确定客户请求的锚点类型。

    如果客户提交的锚点比设备变更日志中最早的记录还要小，则所有已经被删除条目和“*”被服务器返回；如果客户提交的锚点比日志中最新的记录大，则服务器返回“*”。在变更日志获取返回“*”的情况下，就要考虑进行双方的完全同步了。

    如果数据库被复位，或者被客户通过级别2的PUT操作替换，或者如果对象库支持变更计数器类型同步锚点，则当计数器的值从最大值4294967295回滚到0的时候，都要将变更日志清空。

    服务器返回的变更日志都是采用如下顺序：第一行返回设备序列号，第二行返回数据库标识，第三行和第四行则为当前对象数目和对象库容量，接下来是变更条目。这样也便于同步引擎快速确定数据库是否已经复位或者被替换。下面看一个例子（我从一款西门子6C6手机上得到的）：

    SN：354735001562449

    DID：14578531

    Total-Records：1

    Maximum-Records：1000

    M:28::2684358915

    H:27::2684358913

    下面我将说明日志内容的详细定义。（突然才发现我还没有写解析变更日志的VC程序，看来今天的任务又要增加一项了，但是还想去放风筝，郁闷）

    2. 变更日志格式定义

    <变更－修改>    定义为    M

    <变更－删除>    定义为    D

    <变更－物理－删除>    定义为     H

    <变更－变更计数器>    定义为     一个以ASCII编码表示的32位无符号整型数据，0－4294967295

    <变更－时间标签>    定义为     标准日期格式，前面有说明

    <变更－变更条目>    定义为     <变更－修改>|<变更－删除>|<变更－物理－删除> : <变更－变更计数器:>|<变更－时间标签> : CRLF

    <变更－条目已满>    定义为     <变更－物理－删除条目> *

    <变更日志对象>    定义为    <设备序列号>CRLF<数据库标识>CRLF<当前对象数目>CRLF<最大容量>CRLF<变更－变更条目>|<变更－条目已满>

4:28 PM - Mar. 28, 2005 - post comment