2. 程式人生 > >Netty實現高效能IOT伺服器(Groza)之手撕MQTT協議篇上

Netty實現高效能IOT伺服器(Groza)之手撕MQTT協議篇上

阿新 • • 發佈：2018-11-07

 

 

 

前言

誕生及優勢

MQTT由Andy Stanford-Clark（IBM）和Arlen Nipper（Eurotech，現為Cirrus Link）於1999年開發，用於監測穿越沙漠的石油管道。目標是擁有一個頻寬有效且使用很少電池電量的協議，因為這些裝置是通過衛星鏈路連線的，當時這種裝置非常昂貴。 與HTTP及其請求/響應範例相比，該協議使用釋出/訂閱體系結構。釋出/訂閱是事件驅動的，可以將訊息推送到客戶端。中央通訊點是MQTT代理，它負責排程傳送者和合法接收者之間的所有訊息。向代理髮布訊息的每個客戶端都在訊息中包含一個主題。主題是代理的路由資訊​。

每個想要接收訊息的客戶端都訂閱某個主題，並且代理將具有匹配主題的所有訊息傳遞給客戶端。因此，客戶不必彼此瞭解，他們只通過主題進行通訊。該架構支援高度可擴充套件的解決方案，而不依賴於資料生產者和資料使用者。

釋出/訂閱架構

與HTTP的區別在於客戶端不必提取所需的資訊，但是在有新內容的情況下，代理會將資訊推送到客戶端。因此，每個MQTT客戶端都與代理具有永久開啟的TCP連線。如果此連線在任何情況下中斷，MQTT代理可以緩衝所有訊息，並在它重新聯機時將它們傳送到客戶端。 如前所述，MQTT中用於分派訊息的核心概念是主題。主題是一個簡單的字串，可以有更多的層次結構級別，用斜槓分隔。用於傳送起居室的溫度資料的示例主題可以是房屋/起居室/溫度

。一方面，客戶端可以訂閱確切的主題，或者另一方面使用萬用字元。對房屋/ + /溫度的訂閱將導致所有訊息傳送到先前提到的主題房屋/起居室/溫度以及在起居室的地方具有任意值的任何主題，例如房屋/廚房/溫度。加號是單級萬用字元，只允許一個層次結構的任意值。如果您需要訂閱多個級別，例如訂閱整個子樹，還有一個多級萬用字元（＃）。它允許訂閱所有底層層次結構級別。比如房子/＃訂閱以house開頭的所有主題。

 

 

適用人群

以下內容需要你對照著MQTT協議內容仔細推敲

推薦資源:

MQTT協議中文版: https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/01-Introduction.html

MQTT Version 3.1.1: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

 

MQTT控制報文格式

MQTT控制報文結構

結構 備註
Fixed header 固定報頭，所有控制報文都包含
Variable header 可變報頭，部分控制報文包含
Payload 有效載荷，部分控制報文包含

 

固定報頭 Fixed header

  +-----+-----+-----+-----+-----+------+------+------+-------+
  |     |     |     |     |     |      |      |      |       |
  | Bit |  7  |  6  |  5  |  4  |  3   |  2   |  1   |  0    |
  +-----------+-----+-----+------------+------+------+-------+
  |     |                       |                            |
  |byte1|MQTT ControlPacket type|         Flags             |
 +----------------------------------------------------------+
 |     |                                                   |
 |byte2|         Remaining Length                         |
 +----------------------------------------------------------+

 

控制報文型別(MQTT Control Packet type)

名字 值 報文流動方向 描述
Reserved 0 禁止 保留
CONNECT 1 客戶端到服務端 客戶端請求連線服務端
CONNACK 2 服務端到客戶端 連線報文確認
PUBLISH 3 兩個方向都允許 釋出訊息
PUBACK 4 兩個方向都允許 QoS 1訊息釋出收到確認
PUBREC 5 兩個方向都允許 釋出收到（保證交付第一步）
PUBREL 6 兩個方向都允許 釋出釋放（保證交付第二步）
PUBCOMP 7 兩個方向都允許 QoS 2訊息釋出完成（保證互動第三步）
SUBSCRIBE 8 客戶端到服務端 客戶端訂閱請求
SUBACK 9 服務端到客戶端 訂閱請求報文確認
UNSUBSCRIBE 10 客戶端到服務端 客戶端取消訂閱請求
UNSUBACK 11 服務端到客戶端 取消訂閱報文確認
PINGREQ 12 客戶端到服務端 心跳請求
PINGRESP 13 服務端到客戶端 心跳響應
DISCONNECT 14 客戶端到服務端 客戶端斷開連線
Reserved 15 禁止 保留

 

標誌(Flags)

控制報文 固定報頭標誌 Bit 3 Bit 2 Bit 1 Bit 0
CONNECT Reserved 0 0 0 0
CONNACK Reserved 0 0 0 0
PUBLISH Used in MQTT 3.1.1 DUP1 QoS2 QoS2 RETAIN3
PUBACK Reserved 0 0 0 0
PUBREC Reserved 0 0 0 0
PUBREL Reserved 0 0 1 0
PUBCOMP Reserved 0 0 0 0
SUBSCRIBE Reserved 0 0 1 0
SUBACK Reserved 0 0 0 0
UNSUBSCRIBE Reserved 0 0 1 0
UNSUBACK Reserved 0 0 0 0
PINGREQ Reserved 0 0 0 0
PINGRESP Reserved 0 0 0 0
DISCONNECT Reserved 0 0 0 0
Bit3 Bit2 Bit1 Bit0
DUP Qos Qos RETAIN

  • DUP =控制報文的重複分發標誌

  • QoS = PUBLISH報文的服務質量等級

  • RETAIN = PUBLISH報文的保留標誌

備註:

服務質量等級Qos:位置：第1個位元組，第2-1位。這個欄位表示應用訊息分發的服務質量等級保證。

QoS值 Bit 2 Bit 1 描述
0 0 0 最多分發一次
1 0 1 至少分發一次
2 1 0 只分發一次
- 1 1 保留位

 

剩餘長度(Remaining Length)

位置：從第2個位元組開始。

剩餘長度（Remaining Length）表示當前報文剩餘部分的位元組數，包括可變報頭和負載的資料。剩餘長度不包括用於編碼剩餘長度欄位本身的位元組數。

 

可變報頭(Variable header)

某些MQTT控制報文包含一個可變報頭部分。它在固定報頭和負載之間。可變報頭的內容根據報文型別的不同而不同。可變報頭的報文識別符號（Packet Identifier）欄位存在於在多個型別的報文裡。這個在後續的MQTT各個控制報文中進行手撕。

 

有效載荷(Payload)

某些MQTT控制報文在報文的最後部分包含一個有效載荷，對於PUBLISH來說有效載荷就是應用訊息。

包含有效載荷的控制報文Control Packets that contain a Payload

控制報文 有效載荷
CONNECT 需要
CONNACK 不需要
PUBLISH 可選
PUBACK 不需要
PUBREC 不需要
PUBREL 不需要
PUBCOMP 不需要
SUBSCRIBE 需要
SUBACK 需要
UNSUBSCRIBE 需要
UNSUBACK 不需要
PINGREQ 不需要
PINGRESP 不需要
DISCONNECT 不需要

 

 

MQTT控制報文

CONNECT – 連線服務端

客戶端到服務端的網路連線建立後，客戶端傳送給服務端的第一個報文必須是CONNECT報文 。

在一個網路連線上，客戶端只能傳送一次CONNECT報文。服務端必須將客戶端傳送的第二個CONNECT報文當作協議違規處理並斷開客戶端的連線。

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

可變報頭

CONNECT報文的可變報頭按下列次序包含四個欄位：協議名（Protocol Name），協議級別（Protocol Level），連線標誌（Connect Flags）和保持連線（Keep Alive）。

協議名（Protocol Name）

協議名是表示協議名 MQTT 的UTF-8編碼的字串。MQTT規範的後續版本不會改變這個字串的偏移和長度。

如果協議名不正確服務端可以斷開客戶端的連線，也可以按照某些其它規範繼續處理CONNECT報文。對於後一種情況，按照本規範，服務端不能繼續處理CONNECT報文

協議級別（Protocol Level）

客戶端用8位的無符號值表示協議的修訂版本。對於3.1.1版協議，協議級別欄位的值是4(0x04)。

如果發現不支援的協議級別，服務端必須給傳送一個返回碼為0x01（不支援的協議級別）的CONNACK報文響應CONNECT報文，然後斷開客戶端的連線 。

連線標誌（Connect Flags）

連線標誌位元組包含一些用於指定MQTT連線行為的引數。它還指出有效載荷中的欄位是否存在

  +-------+---------+----------+--------+------+-------+-------+--------+--------+
  |       |         |          |        |      |       |       |        |        |
  |  Bit  |    7    |    6     |   5    |  4   |  3    |   2   |   1    |   0    |
  +--------------------------------------------+---------------------------------+
  |       |User Name|Password  | Will   |              | Will  | Clean  |        |
  |       | Flag   | Flag     | Retain | Will Qos   | Flag |Session |Reser^ed|
 +--------------------------------------------+---------------------------------+
 |       |         |         |       |     |       |       |       |       |
 | byte8 |   X   |   X     |   X   |   X |   X   |   X   |   X   |   0   |
 +-------+---------+----------+--------+------+-------+-------+--------+--------+
 ​

服務端必須驗證CONNECT控制報文的保留標誌位（第0位）是否為0，如果不為0必須斷開客戶端連線 。

清理會話 Clean Session

位置：連線標誌位元組的第1位

這個二進位制位指定了會話狀態的處理方式。

客戶端和服務端可以儲存會話狀態，以支援跨網路連線的可靠訊息傳輸。這個標誌位用於控制會話狀態的生存時間。

遺囑標誌 Will Flag

位置：連線標誌的第2位。

遺囑標誌（Will Flag）被設定為1，表示如果連線請求被接受了，遺囑（Will Message）訊息必須被儲存在服務端並且與這個網路連線關聯。之後網路連線關閉時，服務端必須釋出這個遺囑訊息，除非服務端收到DISCONNECT報文時刪除了這個遺囑訊息

遺囑QoS Will QoS

位置：連線標誌的第4和第3位。

這兩位用於指定釋出遺囑訊息時使用的服務質量等級。

遺囑保留 Will Retain

位置：連線標誌的第5位。

如果遺囑訊息被髮布時需要保留，需要指定這一位的值。

使用者名稱標誌 User Name Flag

位置：連線標誌的第7位。

如果使用者名稱（User Name）標誌被設定為0，有效載荷中不能包含使用者名稱欄位 。

如果使用者名稱（User Name）標誌被設定為1，有效載荷中必須包含使用者名稱欄位 。

密碼標誌 Password Flag

位置：連線標誌的第6位。

如果密碼（Password）標誌被設定為0，有效載荷中不能包含密碼欄位 。

如果密碼（Password）標誌被設定為1，有效載荷中必須包含密碼欄位 。

如果使用者名稱標誌被設定為0，密碼標誌也必須設定為0 。

保持連線 Keep Alive

保持連線（Keep Alive）是一個以秒為單位的時間間隔，表示為一個16位的字，它是指在客戶端傳輸完成一個控制報文的時刻到傳送下一個報文的時刻，兩者之間允許空閒的最大時間間隔。

客戶端負責保證控制報文傳送的時間間隔不超過保持連線的值。如果沒有任何其它的控制報文可以傳送，客戶端必須傳送一個PINGREQ報文 。

有效載荷

CONNECT報文的有效載荷（payload）包含一個或多個以長度為字首的欄位，可變報頭中的標誌決定是否包含這些欄位。如果包含的話，必須按這個順序出現：客戶端識別符號，遺囑主題，遺囑訊息，使用者名稱，密碼 。

響應Response

  1. 網路連線建立後，如果服務端在合理的時間內沒有收到CONNECT報文，服務端應該關閉這個連線。

  2. 服務端必須按照3.1節的要求驗證CONNECT報文，如果報文不符合規範，服務端不傳送CONNACK報文直接關閉網路連線 [MQTT-3.1.4-1]。

  3. 服務端可以檢查CONNECT報文的內容是不是滿足任何進一步的限制，可以執行身份驗證和授權檢查。如果任何一項檢查沒通過，按照3.2節的描述，它應該傳送一個適當的、返回碼非零的CONNACK響應，並且必須關閉這個網路連線。

CONNACK – 確認連線請求

服務端傳送CONNACK報文響應從客戶端收到的CONNECT報文。服務端傳送給客戶端的第一個報文必須是CONNACK。

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

剩餘長度欄位

表示可變報頭的長度。對於CONNACK報文這個值等於2。

可變報頭

連線確認標誌 Connect Acknowledge Flags

第1個位元組是 連線確認標誌，位7-1是保留位且必須設定為0。 第0 (SP)位 是當前會話（Session Present）標誌。

當前會話 Session Present

位置：連線確認標誌的第0位。

連線返回碼 Connect Return code

位置：可變報頭的第2個位元組。

連線返回碼欄位使用一個位元組的無符號值。如果服務端收到一個合法的CONNECT報文，但出於某些原因無法處理它，服務端應該嘗試傳送一個包含非零返回碼（表格中的某一個）的CONNACK報文。如果服務端傳送了一個包含非零返回碼的CONNACK報文，那麼它必須關閉網路連線 。

表格 3.1 –連線返回碼的值
值 返回碼響應 描述
0 0x00連線已接受 連線已被服務端接受
1 0x01連線已拒絕，不支援的協議版本 服務端不支援客戶端請求的MQTT協議級別
2 0x02連線已拒絕，不合格的客戶端識別符號 客戶端識別符號是正確的UTF-8編碼，但服務端不允許使用
3 0x03連線已拒絕，服務端不可用 網路連線已建立，但MQTT服務不可用
4 0x04連線已拒絕，無效的使用者名稱或密碼 使用者名稱或密碼的資料格式無效
5 0x05連線已拒絕，未授權 客戶端未被授權連線到此伺服器
6-255   保留

有效載荷

CONNACK報文沒有有效載荷。

 

 

PUBLISH – 釋出訊息

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

固定報頭

  • DUP =控制報文的重複分發標誌

  • QoS = PUBLISH報文的服務質量等級

  • RETAIN = PUBLISH報文的保留標誌

可變報頭

可變報頭按順序包含主題名和報文識別符號。

主題名 Topic Name

主題名（Topic Name）用於識別有效載荷資料應該被髮布到哪一個資訊通道。

主題名必須是PUBLISH報文可變報頭的第一個欄位。它必須是 1.5.3節定義的UTF-8編碼的字串。

PUBLISH報文中的主題名不能包含萬用字元 。

服務端傳送給訂閱客戶端的PUBLISH報文的主題名必須匹配該訂閱的主題過濾器（根據 4.7節定義的匹配過程）。

報文識別符號 Packet Identifier

只有當QoS等級是1或2時，報文識別符號（Packet Identifier）欄位才能出現在PUBLISH報文中。2.3.1節提供了有關報文識別符號的更多資訊。

有效載荷

有效載荷包含將被髮布的應用訊息。

資料的內容和格式是應用特定的。有效載荷的長度這樣計算：用固定報頭中的剩餘長度欄位的值減去可變報頭的長度。包含零長度有效載荷的PUBLISH報文是合法的。

響應

PUBLISH報文的接收者必須按照根據PUBLISH報文中的QoS等級傳送響應。

服務質量等級 預期響應
QoS 0 無響應
QoS 1 PUBACK報文
QoS 2 PUBREC報文

PUBACK –釋出確認

PUBACK報文是對QoS 1等級的PUBLISH報文的響應。

剩餘長度欄位

表示可變報頭的長度。對PUBACK報文這個值等於2.

可變報頭

包含等待確認的PUBLISH報文的報文識別符號。

有效載荷

PUBACK報文沒有有效載荷。

PUBREC – 釋出收到（QoS 2，第一步）

PUBREC報文是對QoS等級2的PUBLISH報文的響應。它是QoS 2等級協議交換的第二個報文。

剩餘長度欄位

表示可變報頭的長度。對PUBREC報文它的值等於2。

可變報頭

可變報頭包含等待確認的PUBLISH報文的報文識別符號。

有效載荷

PUBREC報文沒有有效載荷。

Netty實現

 

   MqttMessage pubRecMessage = MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.PUBREC, false, MqttQoS.AT_MOST_ONCE, false, 2),
                  MqttMessageIdVariableHeader.from(variableHeader.messageId()),
                  null);

 

PUBREL – 釋出釋放（QoS 2，第二步）

PUBREL報文是對PUBREC報文的響應。它是QoS 2等級協議交換的第三個報文。

PUBREL控制報文固定報頭的第3,2,1,0位是保留位，必須被設定為0,0,1,0。服務端必須將其它的任何值都當做是不合法的並關閉網路連線 。

剩餘長度欄位

表示可變報頭的長度。對PUBREL報文這個值等於2.

可變報頭

可變報頭包含與等待確認的PUBREC報文相同的報文識別符號。

有效載荷

PUBREL報文沒有有效載荷。

Netty實現

  MqttMessage pubRelMessage = MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.PUBREC, false, MqttQoS.AT_LEAST_ONCE, false, 2),
                  MqttMessageIdVariableHeader.from(variableHeader.messageId()),
                  null);

 

 

PUBCOMP – 釋出完成（QoS 2，第三步）

PUBCOMP報文是對PUBREL報文的響應。它是QoS 2等級協議交換的第四個也是最後一個報文。

剩餘長度欄位

表示可變報頭的長度。對PUBCOMP報文這個值等於2。

可變報頭

可變報頭包含與等待確認的PUBREL報文相同的報文識別符號。

有效載荷

PUBCOMP報文沒有有效載荷。

Netty實現

   MqttMessage pubCompMessage = MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.PUBCOMP, false, MqttQoS.AT_MOST_ONCE, false, 2),
                  MqttMessageIdVariableHeader.from(variableHeader.messageId()),
                  null);

 

 

SUBSCRIBE - 訂閱主題

客戶端向服務端傳送SUBSCRIBE報文用於建立一個或多個訂閱。每個訂閱註冊客戶端關心的一個或多個主題。為了將應用訊息轉發給與那些訂閱匹配的主題，服務端傳送PUBLISH報文給客戶端。SUBSCRIBE報文也（為每個訂閱）指定了最大的QoS等級，服務端根據這個傳送應用訊息給客戶端。

剩餘長度欄位

等於可變報頭的長度（2位元組）加上有效載荷的長度。

可變報頭

可變報頭包含報文識別符號。

有效載荷

SUBSCRIBE報文的有效載荷包含了一個主題過濾器列表，它們表示客戶端想要訂閱的主題。

SUBSCRIBE報文有效載荷中的主題過濾器列表必須是1.5.3節定義的UTF-8字串 [MQTT-3.8.3-1]。

服務端應該支援包含萬用字元（4.7.1節定義的）的主題過濾器。如果服務端選擇不支援包含萬用字元的主題過濾器，必須拒絕任何包含萬用字元過濾器的訂閱請求 [MQTT-3.8.3-2]。

每一個過濾器後面跟著一個位元組，這個位元組被叫做 服務質量要求（Requested QoS）。它給出了服務端向客戶端傳送應用訊息所允許的最大QoS等級。

SUBSCRIBE報文的有效載荷必須包含至少一對主題過濾器 和 QoS等級欄位組合。沒有有效載荷的SUBSCRIBE報文是違反協議的 [MQTT-3.8.3-3]。有關錯誤處理的資訊請檢視4.8節。

請求的最大服務質量等級欄位編碼為一個位元組，它後面跟著UTF-8編碼的主題名，那些主題過濾器 /和QoS等級組合是連續地打包。

 

當前版本的協議沒有用到服務質量要求（Requested QoS）位元組的高六位。如果有效載荷中的任何位是非零值，或者QoS不等於0,1或2，服務端必須認為SUBSCRIBE報文是不合法的並關閉網路連線 。

SUBACK – 訂閱確認

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

SUBACK報文包含一個返回碼清單，它們指定了SUBSCRIBE請求的每個訂閱被授予的最大QoS等級。

剩餘長度欄位

等於可變報頭的長度加上有效載荷的長度。

可變報頭

可變報頭包含等待確認的SUBSCRIBE報文的報文識別符號。

有效載荷

有效載荷包含一個返回碼清單。每個返回碼對應等待確認的SUBSCRIBE報文中的一個主題過濾器。返回碼的順序必須和SUBSCRIBE報文中主題過濾器的順序相同 。

Bit 7 6 5 4 3 2 1 0
  返回碼              
byte 1 X 0 0 0 0 0 X X

允許的返回碼值：

  • 0x00 - 最大QoS 0

  • 0x01 - 成功 – 最大QoS 1

  • 0x02 - 成功 – 最大 QoS 2

  • 0x80 - Failure 失敗

0x00, 0x01, 0x02, 0x80之外的SUBACK返回碼是保留的，不能使用。

UNSUBSCRIBE –取消訂閱

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

UNSUBSCRIBE報文固定報頭的第3,2,1,0位是保留位且必須分別設定為0,0,1,0。

即:

  • DUP =控制報文的重複分發標誌 : false

  • QoS = PUBLISH報文的服務質量等級: Qos1(至少分發一次)

  • RETAIN = PUBLISH報文的保留標誌: false

服務端必須認為任何其它的值都是不合法的並關閉網路連線 。

剩餘長度欄位

等於可變報頭的長度加上有效載荷的長度。

可變報頭

有效載荷

UNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。UNSUBSCRIBE報文中的主題過濾器必須是連續打包的。

UNSUBSCRIBE報文的有效載荷必須至少包含一個訊息過濾器。沒有有效載荷的UNSUBSCRIBE報文是違反協議的。

響應

UNSUBSCRIBE報文提供的主題過濾器（無論是否包含萬用字元）必須與服務端持有的這個客戶端的當前主題過濾器集合逐個字元比較。如果有任何過濾器完全匹配，那麼它（服務端）自己的訂閱將被刪除，否則不會有進一步的處理 。

如果服務端刪除了一個訂閱：

  • 它必須停止分發任何新訊息給這個客戶端 。

  • 它必須完成分發任何已經開始往客戶端傳送的QoS 1和QoS 2的訊息。

  • 它可以繼續傳送任何現存的準備分發給客戶端的快取訊息。

服務端必須傳送UNSUBACK報文響應客戶端的UNSUBSCRIBE請求。UNSUBACK報文必須包含和UNSUBSCRIBE報文相同的報文識別符號 。即使沒有刪除任何主題訂閱，服務端也必須傳送一個UNSUBACK響應 。

如果服務端收到包含多個主題過濾器的UNSUBSCRIBE報文，它必須如同收到了一系列的多個UNSUBSCRIBE報文一樣處理那個報文，除了將它們的響應合併到一個單獨的UNSUBACK報文外。

UNSUBACK – 取消訂閱確認

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

剩餘長度欄位

表示可變報頭的長度，對UNSUBACK報文這個值等於2。

可變報頭

可變報頭包含等待確認的UNSUBSCRIBE報文的報文識別符號。

有效載荷

UNSUBACK報文沒有有效載荷。

Netty實現

 MqttUnsubAckMessage unsubAckMessage = (MqttUnsubAckMessage)MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.UNSUBACK, false, MqttQoS.AT_MOST_ONCE, false, 2),
   MqttMessageIdVariableHeader.from(msg.variableHeader().messageId()),
   null);

 

 

PINGREQ – 心跳請求

客戶端傳送PINGREQ報文給服務端的。用於：

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

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

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

保持連線（Keep Alive）處理中用到這個報文。

可變報頭

PINGREQ報文沒有可變報頭。

有效載荷

PINGREQ報文沒有有效載荷。

響應

服務端必須傳送 PINGRESP報文響應客戶端的PINGREQ報文

Netty實現

   MqttMessage pingReqMessage = MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.PINGREQ, false,MqttQoS.AT_MOST_ONCE, false, 0),
                  null,
                  null);

 

 

PINGRESP – 心跳響應

服務端傳送PINGRESP報文響應客戶端的PINGREQ報文。表示服務端還活著。保持連線（Keep Alive）處理中用到這個報文。

可變報頭

PINGRESP報文沒有可變報頭。

有效載荷

PINGRESP報文沒有有效載荷。

Netty實現

  MqttMessage pingRespMessage = MqttMessageFactory.newMessage(
   new MqttFixedHeader(MqttMessageType.PINGREQ, false,MqttQoS.AT_MOST_ONCE, false, 0),
                  null,
                  null);

 

 

 

DISCONNECT –斷開連線

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

可變報頭

DISCONNECT報文沒有可變報頭。

有效載荷

DISCONNECT報文沒有有效載荷。

響應

客戶端傳送DISCONNECT報文之後：

  • 必須關閉網路連線 。

  • 不能通過那個網路連線再發送任何控制報文 。

服務端在收到DISCONNECT報文時：

  • 必須丟棄任何與當前連線關聯的未釋出的遺囑訊息。

  • 應該關閉網路連線，如果客戶端 還沒有這麼做。

Netty實現

 MqttMessage disConn

相關推薦

Netty實現高效能IOT伺服器(Groza)之手撕MQTT協議篇上

      前言 誕生及優勢 MQTT由Andy Stanford-Clark（IBM）和Arlen Nipper（Eurotech，現為Cirrus Link）於1999年開發，用於監測穿越沙漠的石油管道。目標是擁有一個頻寬有效且使用很少電池電量的協議，因為這

Netty實現高效能IOT伺服器(Groza)之精盡程式碼篇中

if (!msg.variableHeader().isCleanSession()){ List<DupPublishMessageStore> dupPublishMessageStoreList = grozaDupPublishMessageStoreS

Netty實現高效能的HTTP伺服器

16:58:59.130 [nioEventLoopGroup-3-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.maxSharedCapacityFactor: 2 16:58:59.130 [nioEventLoopGroup-3-1

採用完成埠（IOCP）實現高效能網路伺服器（Windows c++版）

前言 　TCP\IP已成為業界通訊標準。現在越來越多的程式需要聯網。網路系統分為服務端和客戶端，也就是c\s模式(client \ server)。client一般有一個或少數幾個連線；server則需要處理大量連線。大部分情況下，只有服務端才特別考慮效能問題。本文主要介紹服務端處理方法，當然也可以用於客戶端

深入解析netty的高效能、高併發之道

一丶 Netty基礎入門 Netty是一個高效能、非同步事件驅動的NIO框架，它提供了對TCP、UDP和檔案傳輸的支援，作為一個非同步NIO框架，Netty的所有IO操作都是非同步非阻塞的，通過Future-Listener機制，使用者可以方便的主動獲取或者通過通知

用 Linux epoll 實現高效能 HTTP 伺服器

用 Linux epoll 實現高效能 HTTP 伺服器 為了程式碼的整潔性，本文章所介紹功能將使用 C++ 實現。實際使用中可轉為 C 語言使用。 此專案只能在Linux下使用，windows請繞道。 專案概括 本專案是使用 Linux epoll 實現的一個簡單

Netty實現高效能高併發

1. 背景 1.1. 驚人的效能資料 最近一個圈內朋友通過私信告訴我，通過使用Netty4 + Thrift壓縮二進位制編解碼技術，他們實現了10W TPS（1K的複雜POJO物件）的跨節點遠端服務呼叫。相比於傳統基於Java序列化+BIO（同步阻塞IO）的通訊框架，

Java非同步NIO框架Netty實現高效能高併發

RPC包括：訊息的編碼、解碼、讀取和傳送；  轉自：http://blog.csdn.net/woshisap/article/details/74022825 本文是對上述文章的總結、精簡。2.1. RPC呼叫的效能模型分析2.1.1. 傳統RPC呼叫效能差的三宗罪 網路

【Python面試必看系列】之手撕程式碼

明天有個筆試，有可能會現場手撕程式碼，所以現在先提前準備幾個常見的程式設計題練練手 一、氣泡排序 lis=[1,8,0,5,6,3,7,4,2] temp=[] for i in range(0,len(lis)): for j in range(i+1,len(lis)

Java多執行緒基礎之手撕生產者和消費者模式

問題描述 資料結構： 生產者/消費者 快取區(共享資源) 規則： 生產/消費者同時操作快取區。 當快取區為空的時候，消費者不能消費，即消費者阻塞。 當快取區為滿的時候，生產者不能生產，即生產者阻

伺服器開發之Unity3d（C#）圖片上傳下載

一、前言 遊戲中圖片的上傳下載是一個亙古不變的話題，這次在開發遊戲伺服器的過程中也不可避免的出現了圖片下載和上傳的問題。遇到了PNG圖片下載完成後透明的部分變成黑色、圖片上傳附帶驗證資訊、下載後文件不一樣的問題。 二、問題回顧 伺服器上面儲存了

Netty5使用者手冊之二：使用netty實現Discard伺服器程式

<span style="font-family:Microsoft YaHei;font-size:14px;">package com.zzj.nio.netty; import io.netty.bootstrap.ServerBootstrap; import io.netty.chan

透徹理解Spring事務設計思想之手寫實現

數據庫操作 cal 了解 hashmap 個數 這一 use action 管道 前言 事務，是描述一組操作的抽象，比如對數據庫的一組操作，要麽全部成功，要麽全部失敗。事務具有4個特性：Atomicity（原子性），Consistency（一致性），Isolation（隔離

理解數據庫連接池底層原理之手寫實現

ring cda color 要去 分配 .com 管理 roc tex 前言 數據庫連接池的基本思想是：為數據庫連接建立一個“緩沖池”，預先在池中放入一定數量的數據庫連接管道，需要時，從池子中取出管道進行使用，操作完畢後，在將管道放入池子中，從而避免了頻繁的向數據庫申請資

漫談NIO(3)之Netty實現

ext tty 數據 ftp nios 區別 med event sync 1.前言 上一章結合Java的NIO例子，講解了多路IO復用的一個基本使用方法，通過實際編碼加深對其理解。本章開始進入Netty的環節，前面兩章都是為了Netty進行鋪墊說明。此節將對比Ja

hbase之createTable完整的netty實現執行流程

hbase的客戶端程式碼並不想hive一樣用java編寫,shell呼叫，而是使用ruby編寫。 在admin.rb檔案中方法create，其中接受兩個引數，其中第二個引數型別為變長引數。 而在create方法的最後，呼叫了admin.createTable,其中的admin是hbaes.

五、通過Protobuf整合Netty實現對協議訊息客戶端與伺服器通訊實戰

目錄 一、Protocol Buffers 是什麼？ 二、Protocol Buffers 檔案和訊息詳解 三、專案實戰，直接掌握的protobuf應用。 一、Protocol Buffers 是什麼？         1、官網翻譯

四、Netty實現webSocket，實現伺服器與瀏覽器（HTML）線上聊天功能

        由於http協議有一個缺陷：通訊只能由客戶端發起。如果伺服器有連續的狀態變化，客戶端要獲知只能使用"輪詢"：每隔一段時候，就發出一個詢問，瞭解伺服器有沒有新的資訊。輪詢的效率低，非常浪費資源（因為必須不停連線，或者 HTTP 連線始終開啟）

二、Netty實現伺服器與客戶端完整互動連線實戰

        本節內容是程式碼實現伺服器與客戶端完整連線過程。整體把控netty的工作流程。我們先不要被某個類，某個api的封裝深入挖掘，這樣你會踩很多坑，陷入進去而拔不出來，後面我會一一講解，原始碼剖析工作原理。這就是我個人學習技術的一種方法，深入淺出

基於netty實現http伺服器

匯入netty4的依賴 <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>