MQTT訊息型別

2021-10-09 15:46:10 字數 1560 閱讀 9735

客戶端到服務端的網路連線建立後,客戶端傳送給服務端的第乙個報文必須是connect報文 [mqtt-3.1.0-1]。

在乙個網路連線上,客戶端只能傳送一次connect報文。服務端必須將客戶端傳送的第二個connect報文當作協議違規處理並斷開客戶端的連線 [mqtt-3.1.0-2]。有關錯誤處理的資訊請檢視4.8節。

有效載荷包含乙個或多個編碼的字段。包括客戶端的唯一識別符號,will主題,will訊息,使用者名稱和密碼。除了客戶端標識之外,其它的字段都是可選的,基於標誌位來決定可變報頭中是否需要包含這些字段。

服務端傳送connack報文響應從客戶端收到的connect報文。服務端傳送給客戶端的第乙個報文必須是connack [mqtt-3.2.0-1]。

如果客戶端在合理的時間內沒有收到服務端的connack報文,客戶端應該關閉網路連線。合理 的時間取決於應用的型別和通訊基礎設施。

publish控制報文是指從客戶端向服務端或者服務端向客戶端傳輸乙個應用訊息。

puback報文是對qos 1等級的publish報文的響應。

pubrec報文是對qos等級2的publish報文的響應。它是qos 2等級協議交換的第二個報文。

pubrel報文是對pubrec報文的響應。它是qos 2等級協議交換的第三個報文。

pubcomp報文是對pubrel報文的響應。它是qos 2等級協議交換的第四個也是最後乙個報文。

客戶端向服務端傳送subscribe報文用於建立乙個或多個訂閱。每個訂閱註冊客戶端關心的乙個或多個主題。為了將應用訊息**給與那些訂閱匹配的主題,服務端傳送publish報文給客戶端。subscribe報文也(為每個訂閱)指定了最大的qos等級,服務端根據這個傳送應用訊息給客戶端。

服務端傳送suback報文給客戶端,用於確認它已收到並且正在處理subscribe報文。

suback報文包含乙個返回碼清單,它們指定了subscribe請求的每個訂閱被授予的最大qos等級.

客戶端傳送unsubscribe報文給服務端,用於取消訂閱主題。

服務端傳送unsuback報文給客戶端用於確認收到unsubscribe報文。

客戶端傳送pingreq報文給服務端的。用於:

在沒有任何其它控制報文從客戶端發給服務的時,告知服務端客戶端還活著。

請求服務端傳送 響應確認它還活著。

使用網路以確認網路連線沒有斷開

服務端傳送pingresp報文響應客戶端的pingreq報文。表示服務端還活著。

保持連線(keep alive)處理中用到這個報文

disconnect報文是客戶端發給服務端的最後乙個控制報文。表示客戶端正常斷開連線。

enum msgtypes

{ connect = 1, connack, publish, puback, pubrec, pubrel,

pubcomp, subscribe, suback, unsubscribe, unsuback,

pingreq, pingresp, disconnect

mqtt保留訊息

mqtt保留訊息 1個topic 主題 只有唯一的retain 保留 訊息,broker會儲存每個topic的最後一條retain訊息。每個client訂閱topic後會立即讀取到retain訊息,不必要等待傳送。訂閱topic時可以使用萬用字元,就會收到匹配的每個topic的retain訊息。如果...

mqtt 訊息重傳

訊息重傳 mqtt協議標準規範的一部分。協議規定作為通訊雙方 服務端 和 客戶端 對於自己傳送到對端的 publish 訊息都應該滿足其 服務質量的要求。qos 1 訊息至少送達一次 即傳送端會一直重發該訊息,除非收到了對端對該訊息的確認。是在mqtt協議的上層 即業務的應用層 相同qos1 訊息可...

android訊息推送 mqtt協議

對與訊息推送是什麼個概念,在此就不贅述啦。google自帶的c2md服務,可以幫助我們實現該功能,可以該伺服器在國外,所以鑑於網速等各種條件限制,我們也沒法實現。為解決該問題,在讀了大量的部落格等質料之後,終於見到啦陽光。第三個是由ibm提供的mqtt協議的實現,就相當於乙個 開啟1883埠,在se...