MQTT-SN之功能描述.doc

1、MQTT-SN之功能描述56.html2015紧接上文，这是第三篇，主要是对MQTT-SN1.2 协议进行总体性功能描述。嗯，这一部分可以结合着MQTT协议对比着来看。网关的广播和发现网关只能在成功连接到 MQTT Server之后，才能够周期性的在无线个人区域网 WPNs 内对所有客户端广播ADVERTISE消息，便于客户端被动知道网关的存在。在同一网络下，多个拥有不同 Id 的网关可有同时运行中，但会由客户端根据信号强弱决定连接具体网关，无论何时只能连接一个网关。客户端可维护一份可用网关列表（包含网关地址），在接收到包含有新的网关id 的 ADVERTISE和 GWINFO消息后，其列表需

2、要添加新的网关元素进去。ADVERTISE广播消息包含的下一次广播间隔时长Duration 属性，单位秒，设为变量T_ADV ，应该尽可能大与15 分钟（ 900 秒），频率降低是为了避免低速个人区域网络的拥塞。针对接收ADVERTISE消息频率，处理能力较强客户端可以用于监督网关是否可用。eg ：客户端连续N_ADV 次接收不到某个网关ADVERTISE广播消息，可认为此网关经死掉不可用并且从已维护的网关列表中移除。同样的，作为备用的网关认为主网关已挂掉，此时可处于激活状态，正常发挥作用。网关发送广播消息ADVERTISE的时间间隔很长，这对导致新加入的客户端不利，但客户端可以直接发送SEA

3、RCHGW广播消息进行查询网关。大量的新入设备会造成广播风暴造成网络拥挤，每一个新加入的客户端在发送SEARCHGW广播消息之前都需要获取一个随机的延迟发送值(0-Tsearchgw)，在延迟等待发送期间若接收到其它客户端发送的SEARCHGW广播消息，会取消掉自己的SEARCHGW广播消息发送，等待网关GWINFO 消息通知。SEARCHGW消息属性 radius 广播半径，记为变量Rb ， 1 跳（ 1 hop ）在一般密集部署下的MQTT-SN客户端基本可用。网关接收到SEARCHGW会即刻回复包含自身id 的 GWINFO 消息。客户端收到SEARCHGW后，若有需要延迟发送的SEAR

4、CHGW会取消掉，若自身维护一份多个可用网关列表，在等待T_GWINFO时间内没有收到GWINFO 消息，会从列表中取出一条网关信息组装成GWINFO消息并广播出去。这就要求客户端已运行多时，并且维护多个可用网关列表。GWINFO和 SEARCHGW所包含半径radius 属性值一致，这就要求底层网络在传输时进行决定是否需要传输到其它类型网络中。若没有接收到响应，SEARCHGW消息可能被重新传输。两个连续的SEARCHGW消息重传间隔应该呈指数形式增加，避免太密集传输。客户端的连接建立无论是基于哪一种传输协议，TCP or UDP ，客户端都需要建立连接，并且保持心跳，逻辑上和服务器端保持一

5、条不断线的双向通道。下面一张图，演示了客户端建立连接的过程，并且设定客户端在 CONNECT 消息中标志位字段中遗嘱WILL属性为 true ，然后就有了遗嘱主题 /消息的请求过程。很多情况下，连接 CONNECT是不需要遗嘱支持的，网关会直接返回 CONNACK消息，但网关会因为拥塞或不支持一些CONNET 特性， CONNACK 所包含返回代码字段 ReturnCode 中包含拒绝代码，要求客户端检查是否连接成功，区别对待。比如：CONNACK消息返回状态码为0x01（ Rejected: congestion ，因拥塞被拒绝） ，客户端需要在T_WAIT 时间间隔后进行重试。回话清理已经

6、连接的客户端断线后，若之前在CONNECT中没有设置过会话清理 （ Clean Session ）标识，那么之前的订阅等信息在网关处将会持久存在。相比 MQTT ，MQTT-SN中的“ CleanSession ”标识被扩展到遗嘱特性中。在CONNECT消息中，CleanSession和 Will 组合将会产生以下效果：CleanSession=true, Will=true:网关将会删除之前对应的所有订阅和遗嘱，新的遗嘱主题/消息稍后即将重新处理CleanSession=true, Will=false:网关将会删除之前对应的所有订阅和遗嘱，返回CONNACK消息CleanSession=f

7、alse, Will=true:网关将继续持有之前对应的所有订阅，新的遗嘱主题/消息稍后即将重新处理CleanSession=false, Will=false:网关将会继续持有之前对应的所有订阅和遗嘱等数据，并返回CONNACK消息更新遗嘱流程CONNEECTION中标志位 Will 中设置是否需要更新遗嘱主题/消息空 WILLTOPIC （两个字节）消息将会促使网关删除对应遗嘱数据WILLTOPICUPD/WILLMSGUPD可以更新 /修改遗嘱主题、遗嘱消息空白 WILLTOPICUPD（两个字节）消息意味着请求网清空对应已有的遗嘱数据主题注册流程受限于无线传感器网络的有限带宽和微小消息

8、负载，PUBLISH消息中不能够包含完整的主题名称topic name 。这就需要客户端和网关之间通过注册流程，获取主题名称对应的（ 16 位的自然数） topic id ，然后塞入PUBLISH 消息的topicId 属性中。客户端发送REGISTER消息，网关返回 REGACK消息，其所包含的 ReturenCode属性决定注册成功与否：ReturnCode= “ accepted topicId”， 可以很愉快的使用在稍后的 PUBLISH 消息中ReturnCode =“ rejected: congestion”，客户端需要稍等一段时间（ T_WAIT 表示，大于5 分钟）再次重新注

9、册ReturnCode =“ rejected: invalid topic ID/not supported”，客户端需要稍作调整，再次重新注册任意时间，只能执行一个 REGISTER 消息，有没有完成注册流程，需要等待。网关 -客户端方向，网关发送 REGISTER 消息给通知客户端指定 topicId 对应某个主题， 以便后面发送 PUBLISH 消息使用。若客户端在订阅 SUBSCRIBE 消息时使用了通配符（ #/+ ），那么与之相匹配的 topic name 也将被一一通知到。因此不建议使用通配符，较为低效。客户端发布流程客户端一旦获取到topic name对应 topic id

10、，就可以直接发送 PUBLISH 消息了。这和 MQTT 协议相比， PUBLISH 消息中 Topic Name 被替换成 Topic Id ，除此之外，还要注意ReturnCode ：ReturnCode =“ rejected: congestion”，客户端需要稍等一段时间（5分钟）后再次重试ReturnCode =“ rejected: invalid topic ID”，客户端需要重新注册topic name获取topic id，然后再次重新发布QoS 1和QoS 2在任一时间，都必须等待已有PUBLISH消息完成，才能进行下面的PUBLISH消息发布流程。预定义 topic id

11、 和两个字符的topic name预定义的 topic id 已提前指派好对应的topic name ，需要客户端和网关在代码层级支持，省略了中间注册流程，在连接建立之后可以马上进行PUBLISH消息，但这需要在PUBLISH标志Flags字段中设置TopicIdType值为0b01（0b10表示两个字节长度的短topic name）。虽然可以快速发送PUBLISH消息，但客户端想订阅预定义的topic id，接收对应的PUBLISH消息，一样需要发送SUBSCRIBLE消息请求进行订阅。若乱指定预定义topic id，会收到ReturnCode=“ Rejection: invalid to

12、pic Id”的异常。预定义的短 topic name 只有两个字符长度的字符串 （也是两个字节），topic id 为两个字节表示的一个自然数 （ 0-65535 ），两者使用场景一致， 都需要在标志位 Flags 设置 TopicIdType具体值， 0b01 表示预定义topic id ，0b10 表示两个字节长度的短 topic name ，需要分清。PUBLISH对应 QoS -1 值这对仅仅支持 PUBLISH QoS -1 的非常简单的客户端实现而言，除此之外不支持任何特性。它不关心连接是否建立，也没有注册、订阅这一说，按照已经固化到代码中的网关地址直接发送 PUBLISH 消息

13、，不关心网关地址是否正确、网关是否存活、消息是否发送成功。下面的 PUBLISH属性值依赖于QoS -1 的情况：QoS 标志，被置为0b11TopicIdType标志，可能是（预定义是（短 topic name ）0b10topic id）0b01也可能TopicId字段，预定义topic id或短topic nameData字段，需要发送的数据，没啥变化客户端的订阅和退订客户端对某个主题感兴趣，可以发起SUBSCRIBLE流程，携带上感兴趣的主题名（ topic id ），服务器一般会返回包含有指定主题 Id （topic id ）的 SUBACK 消息。订阅失败，可以从 PUBACK 的

14、 ReturnCode 中获知：ReturnCode =“ rejected: congestion”，客户端需要稍等一段时间 T_WAIT （5 分钟）后再次重试有一种情况是 SUBSCRIBLE 订阅主题包含通配符，网关的处理就很简单，在 SUBACK 中返回的 topic id 为 0x0000 。稍后，网关向客户端发送REGISTER消息走注册流程，通知通配符匹配到的主题对应的topic id 值。来自客户端的SUBSCRIBLE消息一样支持预定义topic id，以及短 topic name ，这和 PUBLISH消息差不多。退订就很简单， 客户端发送UNSUBSCRIBLE消息，网

15、关返回 UNSUBACK 消息。但同一时刻，客户端只允许处理订阅 SUBSCRIBLE 或取消订阅 UNSUBSCRIBLE 按照串行化顺序， 下一个操作依赖于上一个操作完全成功。网关发布流程服务器发布流程和客户端类似，在发布之前需要检测其主题是否已经向客户端提前注册过，若无需要把主题和指定的topic id 放入 REGISTER消息中发送给客户端进行注册流程，然后等待客户端处理结果REGACK 。注册通过，然后才能正常发送PUBLISH消息。网关需要确保REGISTER 的主题以及 PUBLISH负载都不能太长超过当前网络负载上限（比如在消息的内容ZigBee 环境下不能超过60 个字节）

16、，取消注册/发布流程就好了。网关发布PUBLISH消息时，客户端检测到未知的topic id，把拒绝理由封装到PUBACK后，网关遇到ReturnCode= “ Rejected: invalid Topic IDtopic”非法id ，需要考虑删除或重新注册。客户端或许会拒绝其注册，或许会不允许PUBLISH消息，网关如上静默处理就好了，失败就失败了， 不需要告知别人。客户端发布流程于此类似，需要在发布之前进行主题注册以获取指定的topic id ，提交 PUBLISH消息后，同样需要检查PUBACK 所包含的 ReturnCode字段是接受还是拒绝，因网络拥塞而产生的拒绝，客户端需要在T_

17、WAIT 时间后再次重试。客户端的发布必须是串行方式，下一个需要发送到PUBLISH消息需要等待上一个发送成功被网关接受之后才能进行处理。心跳保活流程一般是客户端 - 网关，网关 - 客户端也没有问题。但要求PINGREQ - PINGRESP一定要单个时针循环，PINGREQ发送者不能也是PINGRESP的发送者，那样不但乱了流程，也浪费了网络资源。嗯，不允许双向互发。客户端可基于心跳机制监测已连接网关健康与否，连续多次接收不到来自网关的PINGRESP消息后，客户端连接下一个可替换的网关。因为客户端的连接和心跳和其它客户端状态属性不同步，但这可能会带来一个问题，同一时间若有大量的客户端洪水

18、般同时连接一个网关，网关可能毫无征兆的会被冲垮掉。这就要求网关要有批量的连接处理能力，并发特性增强才行。客户端断线流程客户端主动发送DISCONNECT消息告知网关需要断线之后，若有交换信息的需要可以重新发起一个新的会话连接。DISCONNECT消息之后，网关不会清理掉已有订阅和遗嘱数据，除非在之前的CONNECT消息中已硬性设置了CleanSession 会话清理标识为 true 。网关接收到 DISCONNECT 消息之后会返回一个 DISCONNECT 消息作为响应。有一种情况是客户端会突然接收到来自网关的DISCONNECT消息，这也许是网关自身发生了异常错误，或网关无法定位客户端的消

19、息归属（客户端的消息和客户端无法关联到一起） ，此时客户端需要发送CONNECT消息重建与网关的会话连接。客户端重传流程客户端 - 网关的消息都是单路传播的，这依赖于客户端所持有的已连接网关的单播地址。客户端发送一个消息之后，需要启动一个重试定时器Tretry和一个重试计数器Nretry 用以监督网关消息响应。定时器会被客户端在指定时间内接收到来自网关的消息后取消掉，若没有准时接收到则会触发定时器执行消息重发流程，连续Nretry 次重发后，客户端会直接取消掉当前流程，判断当前网关已经断线，需要连接到另外一个可用的网关。假如另外的网关也是连接失败，会尝试重连之前的网关。若在休眠状态下，一旦超过

20、重试计数器值，客户端直接进入休眠状态。客户端休眠支持策略这里所说的客户端指的是依赖电池驱动的电子设备，你要明白一个事实，节省电池资源是多麽的重要，省电就是关键，没电了就没得玩了嘛。当不处于激活状态时为了省电就得需要进入睡眠 /休眠状态，当有数据需要接收或发送时就可以醒过来。网关嘛需要追踪设备的休眠状态并且支持缓存需要发送给休眠设备的消息，在设备唤醒时一一发送。下面是客户端的状态转换图，很清晰描述了各种状态之间的交互：客户端具有五种状态：激活（ active ），休眠（ asleep ），唤醒（ awake ），断线（ disconnected ），丢失（ lost ），每次只能是其中一种。网关需要监督客户端的状态， 开始于 CONNECT 消息中存活时长字段（ keep alive ），在大于存活时长时间内网关接收不到来自客户端消息，网关认为客户端已经处于丢失状态（lost ），会激活对应的遗嘱特性若存在的话。客户端发送 DISCONNECT 消息但没有 duration 休眠时长字段，网关这将处于没有时间监督的断线状态。一旦包含 duration 休眠时长字段，表示客户端需