本篇内容主要讲解“MQTT遗嘱消息乱发问题怎么解决”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MQTT遗嘱消息乱发问题怎么解决”吧!
创新互联公司是一家专注于成都网站设计、网站建设与策划设计,洱源网站建设哪家好?创新互联公司做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:洱源等地区。洱源做网站价格咨询:18980820575
设备支持MQTT协议，主动推送设备消息到MQTT服务器。
设备定义了上线消息和下线消息，下线消息由"遗嘱"消息来实现，上线消息由设备发送，当客户端重连时，会主动发送上线请求。
业务服务器订阅MQTT服务器，来接受设备的消息。
发现上下线消息时混乱的，即业务服务器收到设备的下线消息，但是设备仍然在推送消息，似乎并没有下线。
谁来发送"遗嘱"下线消息？
MQTT服务器
MQTT服务器如何判断是否下线？
遗嘱消息发布的条件，包括但不限于：
服务端检测到了一个I/O错误或者网络故障。
客户端在保持连接（Keep Alive）的时间内未能通讯。
客户端没有先发送DISCONNECT报文直接关闭了网络连接。
由于协议错误服务端关闭了网络连接。
重启设备判断什么条件才会触发"遗嘱"？
断开设备后，MQTT服务器并不会立刻发送"遗嘱"消息，而是在一段时间后，即心跳时间(上述第二种)后才会触发"遗嘱"消息，这很好理解，断电后服务器啥消息都没收到，就会认为客户端其实没有断开。
wireshark能拯救世界！
重启设备后，一段时间，MQTT服务器下发了一条“下线”消息，我通过wireshark仔细分析，结果有一条非常有意思的消息！
MQTT服务器一直向设备发送"挥手“报文(断开连接第一步)，但设备压根不管，仍然一直向MQTT服务器发送数据，而且MQTT服务器仍然一直接收数据。
思考：
这是谁的问题？
我知道"挥手"报文是tcp协议规定，也就是“挥手“的处理层是传输层处理，而传输层的处理肯定和MQTT服务器无关。至于传输层会出现bug这种事情，我简直不敢想。 也就是最大的可能是客户端。但是传输层出现问题，这怎么可能？？？？
我发现MQTT服务器回客户端"挥手"消息(灰色的那条)的端口是3340，而MQTT服务器回客户端ack消息的端口是3344，这怎么可能？
深思熟虑后，以及对比多家开源MQTT服务器后，我终于发现真正问题 。
MQTT的遗嘱判断非常简单，只要判断连接断开就立刻发送遗嘱消息，不需要判断全部存活的连接中，是否包含相同的clientID
定睛一看（每次在这种细节上，我总是不够细心，或许这是我的一个属性吧）
我观察了很久，突然发现一个非常“震惊”的消息。
对整个bug流程梳理。
设备在某段时间掉电，然后又重新连接了。此时设备发送上线消息，但是MQTT服务器在一段时间后，终于判断连接断开，从而发送下线消息。
放弃"遗嘱"消息，通过一段时间是否收到业务据来判断客户端是否“宕机”。
自己实现MQTT服务器，每次发送遗嘱消息时，对整个active连接判断是否有相同的clientID，我一直都是这么做的。
生成一个随机值A，对遗嘱消息进行修改，遗嘱消息都带上一个A。对上线消息进行修改，带上一个A。
当业务服务器，收到上线消息时，要把clientID和随机值A绑定存下来，获得下线消息时，从里面取出随机值，和当前的clientID绑定的随机值对比，如果相同则说明确实下线，如果不相同，则说明这是上个连接的值。
到此，相信大家对“MQTT遗嘱消息乱发问题怎么解决”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
