本篇內容主要講解“MQTT遺囑消息亂發(fā)問題怎么解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MQTT遺囑消息亂發(fā)問題怎么解決”吧!

創(chuàng)新互聯(lián)公司是一家專注于成都網站設計、網站建設與策劃設計,洱源網站建設哪家好?創(chuàng)新互聯(lián)公司做網站,專注于網站建設十余年,網設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:洱源等地區(qū)。洱源做網站價格咨詢:18980820575

背景：

• 設備支持MQTT協(xié)議，主動推送設備消息到MQTTMQTT服務器

• MQTT服務器如何判斷是否下線？

遺囑消息發(fā)布的條件，包括但不限于：

1. 服務端檢測到了一個I/O錯誤或者網絡故障。

2. 客戶端在保持連接（Keep Alive）的時間內未能通訊。

3. 客戶端沒有先發(fā)送DISCONNECT報文直接關閉了網絡連接。

4. 由于協(xié)議錯誤服務端關閉了網絡連接。

3. 重啟設備判斷什么條件才會觸發(fā)"遺囑"？
   斷開設備后，MQTT服務器并不會立刻發(fā)送"遺囑"消息，而是在一段時間后，即心跳時間(上述第二種)后才會觸發(fā)"遺囑"消息，這很好理解，斷電后服務器啥消息都沒收到，就會認為客戶端其實沒有斷開。

4. wireshark能拯救世界！
   重啟設備后，一段時間，MQTT服務器下發(fā)了一條“下線”消息，我通過wireshark仔細分析，結果有一條非常有意思的消息！
   MQTT服務器一直向設備發(fā)送"揮手“報文(斷開連接第一步)，但設備壓根不管，仍然一直向MQTT服務器發(fā)送數據，而且MQTT服務器仍然一直接收數據。

思考：

1. 這是誰的問題？
   我知道"揮手"報文是tcp協(xié)議規(guī)定，也就是“揮手“的處理層是傳輸層處理，而傳輸層的處理肯定和MQTT服務器無關。至于傳輸層會出現(xiàn)bug這種事情，我簡直不敢想。 也就是最大的可能是客戶端。但是傳輸層出現(xiàn)問題，這怎么可能？？？？

• 我發(fā)現(xiàn)MQTT服務器回客戶端"揮手"消息(灰色的那條)的端口是3340，而MQTT服務器回客戶端ack消息的端口是3344，這怎么可能？

  深思熟慮后，以及對比多家開源MQTT服務器后，我終于發(fā)現(xiàn)真正問題 。

  MQTT的遺囑判斷非常簡單，只要判斷連接斷開就立刻發(fā)送遺囑消息，不需要判斷全部存活的連接中，是否包含相同的clientID

2. 定睛一看（每次在這種細節(jié)上，我總是不夠細心，或許這是我的一個屬性吧）
   我觀察了很久，突然發(fā)現(xiàn)一個非?！罢痼@”的消息。
   

5. 對整個bug流程梳理。
   設備在某段時間掉電，然后又重新連接了。此時設備發(fā)送上線消息，但是MQTT服務器在一段時間后，終于判斷連接斷開，從而發(fā)送下線消息。

解決方法：

1. 放棄"遺囑"消息，通過一段時間是否收到業(yè)務據來判斷客戶端是否“宕機”。

2. 自己實現(xiàn)MQTT服務器，每次發(fā)送遺囑消息時，對整個active連接判斷是否有相同的clientID，我一直都是這么做的。

3. 生成一個隨機值A，對遺囑消息進行修改，遺囑消息都帶上一個A。對上線消息進行修改，帶上一個A。
   當業(yè)務服務器，收到上線消息時，要把clientID和隨機值A綁定存下來，獲得下線消息時，從里面取出隨機值，和當前的clientID綁定的隨機值對比，如果相同則說明確實下線，如果不相同，則說明這是上個連接的值。

到此，相信大家對“MQTT遺囑消息亂發(fā)問題怎么解決”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！


網站題目：MQTT遺囑消息亂發(fā)問題怎么解決
新聞來源：http://weahome.cn/article/jjhjii.html