前言 之前看了一些关于Mqtt协议的文章，看完了没有去做笔记，过了这么久忘了很多。最近刚好在做相关的东西，需要用到，就顺便记下来了。 正文 cleansession 清除会话 在客户端连接服务端时设置。 值为：true/false 作用：服务器必须在客户端断开之后继续存储/保持客户端的订阅状态，包括以下状态 存储订阅的消息Qos1和Qos2消息，当客户端重新订阅时发送 服务端正在发送消息给客户端期间连接丢失导致发送失败的消息 retain 持久消息。 想一下以下场景，你有个温湿度传感器，每隔几个钟向主题发送一次消息，此时你有个新的客户端订阅了这个主题，那它难道要等上几个钟才能获得消息吗？可不可以一订阅就获取上一次发送的消息呢？ 答案是可以的 值为: true/false 作用：表示发送的消息需要一直持久保存（不受服务器重启影响），不但要发送给当前的订阅者，并且以后新来的订阅了此Topic name的订阅者会马上得到推送。 注意：新来的订阅了此topic name的订阅者指的是新的clientID用户，也就是说假如你是叫12345的用户在同一次的连接中多次重复订阅的话是和订阅一次一样的；.... Mqtt协议——cleansession、retain、will、Shared Subscription mqtt
遗嘱消息是 MQTT 为那些可能出现 意外断线 的设备提供的将 遗嘱 优雅地发送给第三方的能力。意外断线包括但不限于： 因网络故障或网络波动，设备在保持连接周期内未能通讯，连接被服务端关闭 设备意外掉电 设备尝试进行不被允许的操作而被服务端关闭连接，例如订阅自身权限以外的主题等 遗嘱消息可以看作是一个简化版的 PUBLISH 消息，他也包含 Topic, Payload, QoS 等字段。遗嘱消息会在设备与服务端连接时，通过 CONNECT 报文指定，然后在设备意外断线时由服务端将该遗嘱消息发布到连接时指定的遗嘱主题（Will Topic）上。这也意味着服务端必须在回复 CONNACK 之前完成遗嘱消息的存储，以确保之后任一时刻发生意外断线的情况，服务端都能保证遗嘱消息被发布。 以下为遗嘱消息在 MQTT 5.0 和 MQTT 3.1 & 3.1.1 的差异： MQTT 5.0 MQTT 3.1 & 3.1.1 Will Retain Yes Yes Will QoS Yes Yes Will Flag Yes Yes Will Properties Yes No Wi.... MQTT 遗嘱消息（Will Message）的使用 emqx
基于MQTT 3.1版本，标准MQTT发布遗嘱消息的几种情况。 如果想设置遗嘱消息，那么客户端请求和代理服务器链接之前，必须把遗嘱消息提前填写好，在请求连接时，把遗嘱消息发给代理服务器。 MQTT遗嘱消息，什么时候订阅者会收到代理服务器发布的遗嘱消息？以下四种情况： 服务端发生了I/O 错误或者网络失败； 客户端在定义的心跳时期失联； 客户端在发送下线包之前关闭网络连接； 服务端在收到下线包之前关闭网络连接。 遗嘱标志 Will Flag 位置： 连接标志的第2位。 遗嘱标志（ Will Flag） 被设置为1， 表示如果连接请求被接受了， 遗嘱（ Will Message） 消息必须被存储在服务端并且与这个网络连接关联。 之后网络连接关闭时， 服务端必须发布这个遗嘱消息， 除非服务端收到DISCONNECT报文时删除了这个遗嘱消息。 遗嘱消息发布的条件， 包括但不限于： 服务端检测到了一个I/O错误或者网络故障。 客户端在保持连接（ Keep Alive） 的时间内未能通讯。 客户端没有先发送DISCONNECT报文直接关闭了网络连接。 由于协议错误服务端关闭了网络连接。 如果遗嘱.... MQTT 遗嘱消息（Will Message）发布 mqtt
暴风之鸟