 |
| |
一、OBEX协议浅析
目前的红外线传输大都遵循OBEX协议，这是由微软、苹果、诺基亚等公司专门为红外线传输而制定的一整套协议规则。最新协议版本是1.3版，在官方网站上下载要20美元（有钱的可以去下，我反正是玩玩，叫我交钱是不可能的，本文中实现的依据是在网上找到的OBEX协议1.2版本的文档）。协议文档的第二章OBEX Object Model是关键部份，实现文件传输必须对这章说明仔细研究清楚。以下先就对这章的一些关键点进行讲解。
1、OBEX协议的对象模型
1）OBEX协议使用一系列的数据包（header）来进行某种对象（通常是文件）的传输，其基本格式是这样的：
<Header ID>'数据包的标识
<Header Value> '数据包内的数据
其中<Header ID>是个单字节（八位二进制）字符，这个字符的低六位标识数据包代表的意义，高两位表示这个数据包的总长度的表达方式，如下表：
| 高俩位二进制数据 |
意义 |
| 00 |
这个数据包的<header Value>是一个以空字符结尾的unicode字符串 |
| 01 |
这个数据包的<header Value>是一个以空字符结尾的单字节组成的字符串，<header Value>的前两个字节数据组成的16位整数表示整个数据包的长度（包括<header id>及<header value>的总长） |
| 10 |
<header Value>的长度只有一个字节数据 |
| 11 |
<header Value>的长度只有四个字节数据，并以网格数据格式排列（高位数据放在低位字节中存储） |
注意：在<header Value>的16位数据（如包的长度、Unicode字符在发送方均要做高位字放在低位字发送的处理。由于没注意这个问题，我曾在开头的四五天时间里呕血数升而一直没有成功将数据发送成功）
在应用中，数据包可以嵌套。也就是：Header Value可以包含其它的数据包，所以长度标识非常重要，它可以帮助软件的实现根据包的长度迅速分离出包内的数据。
在本文实现中主要用到的数据包标识如下（其余的项请参阅详细官方协议）：
常用数据包标识列表
| 十六进制值 |
标识名称 |
标识含义 |
| 0x01 |
Name |
标记对象的名称（通常是文件的文件名） |
| 0xC3 |
Length |
以字节为单位计算的对象长度 |
| 0x44 |
Time |
时间（以ISO 8601规范为标准） |
| 0x480x49 |
BodyEnd of Body |
标识一个对象数据块的开始标识这是对象的最后一个数据块 |
OBEX协议数据对象传输是按照服务器端/客户端的方式进行的，每个操作均提供一个操作码以明确操作的含义。以下给出部分数据发送所需操作码列表：
| 0x80 |
Connect |
标识申请开始一个对象传输会话，并可以在这个数据包中告知红外接收方一些必要的兼容性信息。 |
| 0x81 |
Disconnect |
标识对象传输会话结束 |
| 0x020x82 |
PutFinal_Put |
发送对象的put动作（当标识为0x82时说明这是最后的一个Put动作） |
| 0xA0 |
Success |
说明接收端已成功收到put动作发送的所有数据（一般是在成功收到Final_Put标识的数据包后的反馈） |
| 0x90 |
Continue |
说明接收端已收到put动作发送的数据，因为Final_Put还没出现，所以要求发送端继续发送数据。 |
发送方和接收方是的通信的基本格式如下：
| 字节0 |
字节1，2 |
字节三以后的数据 |
| 操作码 |
整个通信数据包的长度 |
通讯的数据 |
以下结合基本传输步骤，对上文列出的数据包使用方法进行讲解：
1、由发送方向接收文件的接收方进行连接请求。
发送方需要使用的操作码为Connect，在OBEX协议中对Connect数据包格式作如下规定：
| 字节0 |
字节1、2 |
字节3 |
字节4 |
字节5、6 |
字节7 |
| Connect操作码（0x80） |
Connect数据包的总长度 |
OBEX协议的版本（目前为1.0，16进制表示为0x10） |
保留未用，设为0 |
最大可处理的OBEX包长度 |
其它的数据包（可选） |
服务端根据连接的请求向客户端做出响应：
| 字节0 |
字节1、2 |
字节3 |
字节4 |
字节5、6 |
字节7 |
| 响应的操作码 |
响应数据包的总长度 |
OBEX协议的版本（目前为1.0，16进制表示为0x10） |
保留未用，设为0 |
最大可处理的OBEX包长度 |
其它的数据包（可选） |
如果接收方允许连接，响应的操作码会为Success(0xA0)其它的响应操作码均被认为连接失败。
2、发送方向接收方发送数据
发送方通过put和Final_Put这两个操作将传输的数据信息向接收方发送。
发送方的Put/Final_Put使用格式。
| 字节0 |
字节1，2 |
字节三以后的数据 |
| Put操作码(0x02)Final_Put操作码(0x82) |
整个通信数据包的长度 |
通讯的数据（由其它的例如name/body等数据包构成） |
当最后一次传输对象的数据时要使用Final_Put告知接收方这是最后一个数据包了，以便接收方根据接收到的数据进行处理（例如将接收到的文件存盘）。
接收方的响应格式：
| 字节0 |
字节1，2 |
字节三以后的数据 |
| 响应操作码典型的有两个值：Success操作码（0xA0）Continue操作码（0x90 ） |
整个通信数据包的长度 |
通讯的数据（由其它的例如name/body等数据包构成） |
如果接收方成功收到put操作的数据，应该返回Continue开始的响应信息，告知发送方继续发送，在成功收到Final_Put发送的数据后，应返回Success响应信息，告知发送方整个对象都接收完成。（但由于部分适配器只会返回Success响应，出于兼容性考虑，在编程中应理解为无论接收到Success或Continue响应都代表数据发送成功。）
3、发送方关闭连接
发送方在最后应以Disconnect信息明确结束连接，这并不是必须的，但推荐使用。
发送方格式：
| 字节0 |
字节1，2 |
字节三以后的数据 |
| Disconnect操作码 |
整个通信数据包的长度 |
可选的通讯的数据（由其它的数据包构成） |
接收方响应：
| 字节0 |
字节1，2 |
字节三以后的数据 |
| Success操作码（0xA0）服务不可用操作码（0xD3） |
整个通信数据包的长度 |
可选的通讯的数据（由其它的数据包构成） |
当成功断开时，接收方会发送Success信息。否则，如果发送方的disconnect操作包含错误信息（例如一个错误的连接ID）时，会返加0xD3操作码。但并不能操作所有接收方的程序都实现这个响应的功能，也就是说，发送方并不能保证一定会得到响应信息。
(责任编辑：luwei) |
|
|
精彩生活 
