本篇内容主要讲解“MQTT遗嘱消息乱发问题怎么解决”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MQTT遗嘱消息乱发问题怎么解决”吧!

创新互联公司是一家专注于成都网站设计、网站建设与策划设计,洱源网站建设哪家好?创新互联公司做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:洱源等地区。洱源做网站价格咨询:18980820575

背景：

• 设备支持MQTT协议，主动推送设备消息到MQTT服务器。

• 设备定义了上线消息和下线消息，下线消息由"遗嘱"消息来实现，上线消息由设备发送，当客户端重连时，会主动发送上线请求。

• 业务服务器订阅MQTT服务器，来接受设备的消息。

问题：

• 发现上下线消息时混乱的，即业务服务器收到设备的下线消息，但是设备仍然在推送消息，似乎并没有下线。

思考：

1. 谁来发送"遗嘱"下线消息？
   MQTT服务器

2. MQTT服务器如何判断是否下线？

遗嘱消息发布的条件，包括但不限于：

1. 服务端检测到了一个I/O错误或者网络故障。

2. 客户端在保持连接（Keep Alive）的时间内未能通讯。

3. 客户端没有先发送DISCONNECT报文直接关闭了网络连接。

4. 由于协议错误服务端关闭了网络连接。

3. 重启设备判断什么条件才会触发"遗嘱"？
   断开设备后，MQTT服务器并不会立刻发送"遗嘱"消息，而是在一段时间后，即心跳时间(上述第二种)后才会触发"遗嘱"消息，这很好理解，断电后服务器啥消息都没收到，就会认为客户端其实没有断开。

4. wireshark能拯救世界！
   重启设备后，一段时间，MQTT服务器下发了一条“下线”消息，我通过wireshark仔细分析，结果有一条非常有意思的消息！
   MQTT服务器一直向设备发送"挥手“报文(断开连接第一步)，但设备压根不管，仍然一直向MQTT服务器发送数据，而且MQTT服务器仍然一直接收数据。

思考：

1. 这是谁的问题？
   我知道"挥手"报文是tcp协议规定，也就是“挥手“的处理层是传输层处理，而传输层的处理肯定和MQTT服务器无关。至于传输层会出现bug这种事情，我简直不敢想。 也就是最大的可能是客户端。但是传输层出现问题，这怎么可能？？？？

• 我发现MQTT服务器回客户端"挥手"消息(灰色的那条)的端口是3340，而MQTT服务器回客户端ack消息的端口是3344，这怎么可能？

  深思熟虑后，以及对比多家开源MQTT服务器后，我终于发现真正问题 。

  MQTT的遗嘱判断非常简单，只要判断连接断开就立刻发送遗嘱消息，不需要判断全部存活的连接中，是否包含相同的clientID

2. 定睛一看（每次在这种细节上，我总是不够细心，或许这是我的一个属性吧）
   我观察了很久，突然发现一个非常“震惊”的消息。
   

5. 对整个bug流程梳理。
   设备在某段时间掉电，然后又重新连接了。此时设备发送上线消息，但是MQTT服务器在一段时间后，终于判断连接断开，从而发送下线消息。

解决方法：

1. 放弃"遗嘱"消息，通过一段时间是否收到业务据来判断客户端是否“宕机”。

2. 自己实现MQTT服务器，每次发送遗嘱消息时，对整个active连接判断是否有相同的clientID，我一直都是这么做的。

3. 生成一个随机值A，对遗嘱消息进行修改，遗嘱消息都带上一个A。对上线消息进行修改，带上一个A。
   当业务服务器，收到上线消息时，要把clientID和随机值A绑定存下来，获得下线消息时，从里面取出随机值，和当前的clientID绑定的随机值对比，如果相同则说明确实下线，如果不相同，则说明这是上个连接的值。

到此，相信大家对“MQTT遗嘱消息乱发问题怎么解决”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！

分享名称：MQTT遗嘱消息乱发问题怎么解决
链接URL：http://www.tsicrk.com/article/jjhjii.html