1.MQTT 簡述
MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸協議),是一種基於發佈/訂閱(publish/subscribe)模式的“輕量級”通訊協議,該協議構建於 TCP/IP 協議上,由 IBM 在1999年發佈。MQTT 最大優點在於,可以以極少的代碼和有限的帶寬,爲連接遠程設備提供實時可靠的消息服務。作爲一種低開銷、低帶寬佔用的即時通訊協議,使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。
MQTT 是一個基於客戶端-服務器的消息發佈/訂閱傳輸協議。MQTT 協議是輕量、簡單、開放和易於實現的,這些特點使它適用範圍非常廣泛。在很多情況下,包括受限的環境中,如:機器與機器(M2M)通信和物聯網(IoT)。其在,通過衛星鏈路通信傳感器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中已廣泛使用。
2 MQTT 功能介紹
MQTT 協議運行在 TCP/IP 或其他網絡協議之上,它將建立客戶端到服務器的連接,提供兩者之間的一個有序的、無損的、基於字節流的雙向傳輸。當應用數據通過 MQTT 網絡發送時, MQTT 會把與之相關的服務質量(QoS)和主題名(Topic)相關連,其特點包括:
- 使用發佈/訂閱消息模式,它提供了一對多消息分發,以實現與應用程序的解耦。
- 對負載內容屏蔽的消息傳輸機制。
- 對傳輸消息有三種服務質量(QoS):
- 最多一次,這一級別會發生消息丟失或重複,消息發佈依賴於底層 TCP/IP 網絡。即:<=1
- 至多一次,這一級別會確保消息到達,但消息可能會重複。即:>=1
- 只有一次,確保消息只有一次到達。即:=1。在一些要求比較嚴格的計費系統中,可以使用此級別。
- 數據傳輸和協議交換的最小化(協議頭部只有2字節),以減少網絡流量。
- 通知機制,異常中斷時通知傳輸雙方。
3 MQTT 客戶端
一個使用MQTT協議的應用程序或者設備,它總是建立到服務器的網絡連接。客戶端可以:
- 與服務器建立連接
- 發佈其他客戶端可能會訂閱的信息
- 接收其它客戶端發佈的消息
- 退訂已訂閱的消息
4.MQTT 協議中的方法
MQTT協議中定義了一些方法(也被稱爲動作), 用來表示對確定資源所進行操作。 這個資源可以代表預先存在的數據或動態生成數據,這取決於服務器的實現。通常來說,資源指服務器上的文件或輸出。
-
Connect:等待與服務器建立連接。
-
Disconnect:等待 MQTT 客戶端完成所做的工作,並與服務器斷開 TCP/IP 會話。
-
Subscribe:等待完成訂閱。
-
UnSubscribe:等待服務器取消客戶端的一個或多個 Topics 訂閱。
-
Publish:MQTT 客戶端發送消息請求,發送完成後返回應用程序線程。
5.MQTT 協議中的訂閱、主題、會話 -
訂閱(Subscription)
訂閱包含主題篩選器(Topic Filter)和最大服務質量(QoS)。訂閱會與一個會話(Session)關聯。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。 -
會話(Session)
每個客戶端與服務器建立連接後就是一個會話,客戶端和服務器之間有狀態交互。會話存在於一個網絡之間,也可能在客戶端和服務器之間跨越多個連續的網絡連接。 -
主題名(Topic Name)
連接到一個應用程序消息的標籤,該標籤與服務器的訂閱相匹配。服務器會將消息發送給訂閱所匹配標籤的每個客戶端。 -
主題篩選器(Topic Filter)
一個對主題名通配符篩選器,在訂閱表達式中使用,表示訂閱所匹配到的多個主題。 -
負載(Payload)
消息訂閱者所具體接收的內容。 -
應用消息 Application Message
MQTT協議通過網絡傳輸應用數據。應用消息通過MQTT傳輸時,它們有關聯的服務質量(QoS)和主題(Topic)。 -
控制報文 MQTT Control Packet
通過網絡連接發送的信息數據包。MQTT規範定義了十四種不同類型的控制報文,其中一個(PUBLISH報文)用於傳輸應用消息。
下面結合rtthread系統第三方包my-mqtt的代碼進行分析:
1.mqtt協議的依託接觸是TCP協議,在網絡的傳輸層以上。Mqtt的使用主要分爲以下幾個動作:
-
mqtt客戶端與服務器之間通過協議底層的socket實現連接。
-
Mqtt客戶端訂閱主題,同樣是通過最底層的socket發送出去。
-
Mqtt客戶端接收服務器推送所訂閱主題的信息。
-
Mqtt客戶端可將指定主題的內容發佈到服務器。
-
客戶端與服務器之間建立心跳包機制。
-以上所有動作都依賴於mqtt協議中包含的14條指令類型。
2.my-mqtt是在espcle paho_mqtt版本基礎優化來的,下面按照個人理解去解釋該代碼在具體工作時的機制是什麼。
- paho_mqtt_start函數是整個mqtt的開始,開始前需要先設置好mqtt_client中的參數,在該函數中工作比較簡單,主要是創建了一個互斥量和一個消息隊列,創建了一個主線程(paho_mqtt_thread)實現接下來的所有操作。
- 在paho_mqtt_thread主線程中,對所有的參數進行了檢查,然後解析url並socket連接到mqtt服務器(函數是net_connect),成功和服務器建立socket連接後進行mqtt服務器的真正連接,這裏涉及到了用戶名、密碼等參數的使用,然後實現connect的回調。
- 客戶端與服務器實現mqtt連接後,客戶端就可以根據client結構體中主題表實現多個topic的訂閱,然後實現上線的回調。
mqtt_subscribe(c, topic, qos);
...
c->online_callback(c);
- 然後函數進入線程的主循環中,在該循環中實現了ping包(心跳包)的發送:
len = MQTTSerialize_pingreq(c->buf, c->buf_size);
rc = send_packet(c, c->buf, len);
由於客戶端已經服務器建立了socket連接,爲了高效的實現來自服務器數據的接收,使用了
select(c->sock+ 1, &readset, RT_NULL, RT_NULL, &timeout);
如果有接收到數據,則處理接收數據(mqtt_cycle©函數負責)
if (FD_ISSET(c->sock, &readset)) {
rc_t = mqtt_cycle(c);
if (rc_t < 0) goto __mqtt_disconnect;
}
- 到了這一步就可以等着服務器的推送了,其處理函數就是mqtt_cycle()函數,在該函數中,先對接收的數據進行解析,判斷包的類型,比如是應答還是推送。這裏用到的消息類型主要有UNSUBACK、SUBACK、PUBCOMP、PUBACK、CONNACK、PUBREC、PUBREL。當收到的是連接、訂閱後的回覆時,則將回復的消息發送到消息隊列中:
case SUBACK:
{
...
rt_mq_send(c->msg_queue, &msg, sizeof(mqtt_message_ack));
}
當接收到的是publish後的回覆,也就是消息等級爲1 or 2時,直接處理。
case PUBREL:
{
...
if (MQTTDeserialize_ack(&type, &dup, &mypacketid, c->readbuf, c->readbuf_size) != 1)
...
else if ((rc = send_packet(c, c->buf, len)) != PAHO_SUCCESS) // send the PUBREL packet
...
}
- 以上已經完成了主題訂閱及接收服務器推送的數據處理,現在再看一下客戶端想要往服務器發送某主題的數據時是如何操作的。paho_mqtt_publish函數如下:
int paho_mqtt_publish(mqtt_client *client, enum QoS qos, const char *topic, void *payload, size_t length)
該函數中有client參數、QoS等級、topic主題、payload載荷、消息長度。然後根據入參進行組建成符合mqtt協議的數據格式。組裝完後調用send_packet發佈到服務器。
send_packet(client, client->buf, len))
發送完後阻塞一定時間等待消息隊列的數據,即服務器的應答,從而判斷是否成功。
這裏需要再深入理解三個等級的具體工作流程,下圖是等級0的流程:
如上圖所示,發佈者向服務器發佈消息後,服務器不會應答,服務器直接推送給訂閱者。下圖是等級1的流程:
如上圖所示,發佈者向服務器發佈消息後,服務器會應答一個puback包,以表示服務器收到了,服務器推送給訂閱者後,訂閱者會應答一個puback包。下圖是等級2的流程:
如上圖所示,發佈者向服務器發佈消息後,服務器會應答一個PUBREC包,以表示服務器收到了,發佈者再發送一個PUBREL包,詢問服務器是真的收到了嗎,服務器再給應答一個PUBCONP包告訴發佈者真收到了。服務器推送給訂閱者後,訂閱者應答一個PUBREC包,以表示訂閱者收到了,服務器再發送一個PUBREL包,詢問訂閱者是真的收到了嗎,訂閱者再給應答一個PUBCONP包告訴服務器真收到了。