MQTT协议笔记之消息流

前言

前面的笔记已把所有消息类型都过了一遍,这里从消息流的角度尝试解读一下。

网络故障

在任何网络环境下,都会出现一方连接失败,比如离开公司大门那一刻没有了WIFI信号。但持续连接的另一端-服务器可能不能立即知道对方已断开。类似网络异常情况,都有可能在消息发送的过程中出现,消息发送出去,就丢失了。

MQTT协议假定客户端和服务器端稳定情况一般,彼此之通信管道不可靠,一旦客户端网络断开,情况就会很严重,很难恢复原状。

但别忘记,很多客户端会有永久性存储设备支持,比如闪存ROM、存储卡等,在通信出现异常的情况下可以用于保存关键数据或状态信息等。

总之,异常网络情况很复杂,只能小心处理之。

消息重发策略

QoS > 0情况下,PUBLISH、PUBREL、SUBSCRIBE、UNSUBSCRIBE等类型消息在发送者发送完之后,需要等待一个响应消息,若在一个指定时间段内没有收到,发送者可能需要重试。重发的消息,要求DUP标记要设置为1.

等待响应的超时应该在消息成功发送之后开始算起,并且等待超时应该是可以配置选项,以便在下一次重试的时候,适当加大。比如第一次重试超时10秒,下一次可能为20秒,再一次重试可能为60秒呢。当然,还要有一个重试次数限制的。

还有一种情况,客户端重新连接,但未在可变头部中设置clean session标记,但双方(客户端和服务器端)都应该重试先前未发送的动态消息(in-flight messages)。客户端不被强制要求发送未被确认的消息,但服务器端就得需要重发那些未被去确认的消息。

QoS level决定的消息流

QoS level为Quality of Service level的缩写,翻译成中文,服务质量等级。

MQTT 3.1协议在"4.1 Quality of Service levels and flows"章节中,仅仅讨论了客户端到服务器的发布流程,不太完整。因为决定消息到达率,能够提升发送质量的,应该是服务器发布PUBLISH消息到订阅者这一消息流方向。

QoS level 0

至多发送一次,发送即丢弃。没有确认消息,也不知道对方是否收到。

Client Message and direction Server
QoS = 0 PUBLISH 
---------->
Action: Publish message to subscribers then Forget
Reception: <=1

针对的消息不重要,丢失也无所谓。

网络层面,传输压力小。

QoS level 1

所有QoS level 1都要在可变头部中附加一个16位的消息ID。

SUBSCRIBE和UNSUBSCRIBE消息使用QoS level 1。

针对消息的发布,Qos level 1,意味着消息至少被传输一次。

发送者若在一段时间内接收不到PUBACK消息,发送者需要打开DUB标记为1,然后重新发送PUBLISH消息。因此会导致接收方可能会收到两次PUBLISH消息。针对客户端发布消息到服务器的消息流:

Client Message and direction Server
QoS = 1
DUP = 0
Message ID = x

Action: Store message

PUBLISH 
---------->

Actions:

  • Store message
  • Publish message to subscribers
  • Delete message

Reception: >=1

Action: Discard message PUBACK 
<----------

Message ID = x

针对服务器发布到订阅者的消息流:

Server Message and direction Subscriber
QoS = 1
DUP = 0
Message ID = x
PUBLISH 
---------->

Actions:

  • Store message
  • Make message available

Reception: >=1

  PUBACK 
<----------

Message ID = x

发布者(客户端/服务器)若因种种异常接收不到PUBACK消息,会再次重新发送PUBLISH消息,同时设置DUP标记为1。接收者以服务器为例,这可能会导致服务器收到重复消息,按照流程,broker(服务器)发布消息到订阅者(会导致订阅者接收到重复消息),然后发送一条PUBACK确认消息到发布者。

在业务层面,或许可以弥补MQTT协议的不足之处:重试的消息ID一定要一致接收方一定判断当前接收的消息ID是否已经接受过

但一样不能够完全确保,消息一定到达了。

QoS level 2

仅仅在PUBLISH类型消息中出现,要求在可变头部中要附加消息ID。

级别高,通信压力稍大些,但确保了仅仅传输接收一次。

先看协议中流程图,Client -> Server方向,会有一个总体印象:

Client Message and direction Server
QoS = 2
DUP = 0
Message ID = x

Action: Store message

PUBLISH 
---------->
Action(a) Store message

or

Actions(b):

  • Store message ID
  • Publish message to subscribers
  PUBREC 
<----------
Message ID = x
Message ID = x PUBREL 
---------->
Actions(a):

  • Publish message to subscribers
  • Delete message

or

Action(b): Delete message ID

Action: Discard message PUBCOMP 
<----------
Message ID = x

Server -> Subscriber

Server Message and direction Subscriber
QoS = 2
DUP = 0
Message ID = x
PUBLISH 
---------->
Action: Store message
  PUBREC 
<----------
Message ID = x
Message ID = x PUBREL 
---------->
Actions:

  • Make message available
  PUBCOMP 
<----------
Message ID = x

Server端采取的方案a和b,都包含了何时消息有效,何时处理消息。两个方案二选一,Server端自己决定。但无论死采取哪一种方式,都是在QoS level 2协议范畴下,不受影响。若一方没有接收到对应的确认消息,会从最近一次需要确认的消息重试,以便整个(QoS level 2)流程打通。

消息顺序

消息顺序会受许多因素的影响,但对于服务器程序,必须保证消息传递流程的每个阶段要和开始的顺序一致。例如,在QoS level 2定义的消息流中,PUBREL流必须和PUBLISH流具有相同的顺序发送:

Client Message and direction Server
  PUBLISH 1
---------->
PUBLISH 2
---------->
PUBLISH 3
---------->
 
  PUBREC 1
<----------
PUBREC 2
<----------
 
  PUBREL 1
---------->
 
  PUBREC 3
<----------
 
  PUBREL 2
---------->
 
  PUBCOMP 1
<----------
 
  PUBREL 3
---------->
 
  PUBCOMP 2
<----------
PUBCOMP 3
<----------
 

流动消息(in-flight messages)数量允许有一个可保证的效果:

  • 在流动消息(in-flight)窗口1中,每个传递流在下一个流开始之前完成。这保证消息以提交的顺序传递
  • 在流动消息(in-flight)大于1的窗口,只能在QoS level内被保证消息的顺序

消息的持久化

在MQTT协议中,PUBLISH消息固定头部RETAIN标记,只有为1才要求服务器需要持久保存此消息,除非新的PUBLISH覆盖。

对于持久的、最新一条PUBLISH消息,服务器不但要发送给当前的订阅者,并且新的订阅者(new subscriber,同样需要订阅了此消息对应的Topic name)会马上得到推送。

Tip:新来乍到的订阅者,只会取出最新的一个RETAIN flag = 1的消息推送,不是所有。

消息流的编码/解码

MQTT协议中,由目前定义的14种类型消息在客户端和服务器端之间数据进行交互。若以JAVA语言构建MQTT服务器,可选择Netty作为基础。

在Netty中,数据的进入和流出,代表了一次完整的交互。无论是要进入的还是要流出的数据(单独以服务器为例),都可看做字节流。若把每种类型消息抽象为一个具体对象,那么处理起来就不难了。

客户端->服务器,进入的字节流,逐个字节/单位读取,可还原成一个具体的消息对象(解码的过程)。

要发送到客户端的消息对象,转换(编码)成字节流,然后由TCP通道流转到接收者。

小结

断断续续记录了MQTT 3.1协议的若干阅读笔记,总之是把协议个人认为不够清晰,或者我不好理解的地方,着重进行了分析。也便于自己以后回过来头来翻阅,不是那么快的忘却。

原文 http://www.blogjava.net/yongboy/archive/2014/02/15/409893.html

时间: 2024-09-28 04:47:59

MQTT协议笔记之消息流的相关文章

MQTT协议笔记之发布流程

MQTT协议笔记之发布流程 前言 这次要讲到客户端/服务器的发布消息行为,与PUBLISH相关的消息类型,会在这里看到. PUBLISH 客户端发布消息经由服务器分发到所有对应的订阅者那里.一个订阅者可以订阅若干个主题(Topic name),但一个PUBLISH消息只能拥有一个主题. 消息架构一览:   Description 7 6 5 4 3 2 1 0 Fixed header/固定头部 byte 1   Message Type(3) DUP flag QoS level RETAIN

MQTT协议笔记之头部信息

前言 记忆不太好的时候,只能翻看以前的文章/笔记重新温习一遍,但找不到MQTT协议有关订阅部分的描述,好不容易从Evernote中找到贴出来,这样整个MQTT协议笔记,就比较齐全了. SUBSCRIBE 一般来讲,客户端在成功建立TCP连接之后,发送CONNECT消息,在得到服务器端授权允许建立彼此连接的CONNACK消息之后,客户端会发送SUBSCRIBE消息,订阅感兴趣的Topic主题列表(至少一个主题),一个完整示范如下:   Description 7 6 5 4 3 2 1 0 Fix

MQTT协议笔记之订阅

前言 记忆不太好的时候,只能翻看以前的文章/笔记重新温习一遍,但找不到MQTT协议有关订阅部分的描述,好不容易从Evernote中找到贴出来,这样整个MQTT协议笔记,就比较齐全了. SUBSCRIBE 一般来讲,客户端在成功建立TCP连接之后,发送CONNECT消息,在得到服务器端授权允许建立彼此连接的CONNACK消息之后,客户端会发送SUBSCRIBE消息,订阅感兴趣的Topic主题列表(至少一个主题),一个完整示范如下:   Description 7 6 5 4 3 2 1 0 Fix

MQTT协议笔记之mqtt.io项目HTTP协议支持

前言 MQTT协议诞生之初,就未曾考虑通过HTTP传输.这也正常,网络受限.不稳定网络不太适合HTTP(2G/3G网络大家使用WAP不也OK嘛).在网络较为充裕的桌面端而言,虽纯文本对比二进制而言没多大优势,受制于历史遗留和使用习惯,以及一大票传统基础设施方便控制事宜,传统互联网/企业型应用,HTTP协议都是默认最佳选择,安全可控,人机友好.选择HTTP也在情理之中. 虽桌面端日渐式微,但做统一的全平台化消息系统/消息中间件,也是趋势. MQTT OVER HTTP,为WEB环境提供HTTP通道

MQTT协议笔记之连接和心跳

前言 本篇会把连接(CONNECT).心跳(PINGREQ/PINGRESP).确认(CONNACK).断开连接(DISCONNECT)和在一起. CONNECT 像前面所说,MQTT有关字符串部分采用的修改版的UTF-8编码,CONNECT可变头部中协议名称.消息体都是采用修改版的UTF-8编码.前面基本上可变头部内容不多,下面是一个较为完整的CONNECT消息结构:   Description 7 6 5 4 3 2 1 0 Fixed header/固定头部     Message Typ

MQTT协议笔记之mqtt.io项目Websocket协议支持

前言 MQTT协议专注于网络.资源受限环境,建立之初不曾考虑WEB环境,倒也正常.虽然如此,但不代表它不适合HTML5环境. HTML5 Websocket是建立在TCP基础上的双通道通信,和TCP通信方式很类似,适用于WEB浏览器环境.虽然MQTT基因层面选择了TCP作为通信通道,但我们添加个编解码方式,MQTT Over Websocket也可以的. 这样做的好处,MQTT的使用范畴被扩展到HTML5.桌面端浏览器.移动端WebApp.Hybrid等,多了一些想像空间.这样看来,无论是移动端

MQTT协议笔记之mqtt.io项目TCP协议支持

前言 MQTT定义了物联网传输协议,其标准倾向于原始TCP实现.构建于TCP的上层协议堆栈,诸如HTTP等,在空间上多了一些处理路径,稍微耗费了CPU和内存,虽看似微乎其微,但对很多处理能力不足的嵌入式设备而言,选择原始的TCP却是最好的选择. 但单纯TCP不是所有物件联网的最佳选择,提供构建与TCP基础之上的传统的HTTP通信支持,尤其是浏览器.性能富裕的桌面涉及领域,还是企业最 可信赖.最可控的传输方式之一.支持多种多样的连接通道,让目前所有一切皆可联网,除了原始TCP Socket,还要支

MQTT协议-----订阅

MQTT协议笔记之订阅      http://www.blogjava.net/yongboy/archive/2014/04/12/412351.html MQTT - chszs的专栏    http://blog.csdn.net/chszs/article/category/6262440 MQTT的学习研究(十一) IBM MQTT 简单发布订阅实例    http://blog.csdn.net/shayuye/article/details/17590497

海鑫智圣:物联网漫谈之MQTT协议

什么是MQTT协议 MQTT(消息队列遥测传输协议)是IBM在1999年专门针对物联网等应用场景来制订的轻量级双向消息传输协议,它主要是为了解决物联网上使用到的设备的互相通信的问题,以及这些设备与后端应用系统之间通信的问题. 为什么需要MQTT(或类似)协议 随着智能硬件和移动互联网技术的快速发展,传统的互联网协议越来越难以满足物联网的需要,体现在:移动网络代价昂贵,带宽低.可靠性差:在嵌入设备中运行,处理器和内存资源有限:海量在线设备产生庞大数据,给云端带来很大的网络开销和处理压力. MQTT