MQTT簡單介紹

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協(xié)議），是一種基于發(fā)布/訂閱模式的"輕量級"通訊協(xié)議，該協(xié)議構(gòu)建于TCP/IP協(xié)議上。好比你給好友發(fā)送一封電子郵件，發(fā)送完成后你可以去做別的事情，收件人也不必立刻響應，可以在自己有空的時候查看郵件，是一個典型的異步發(fā)布/訂閱場景。而另一種典型的同步請求/回答場景，可以用接打電話的場景來類比。

創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務領(lǐng)域包括：成都網(wǎng)站設(shè)計、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的喀喇沁網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

MQTT的設(shè)計遵循以下的原則：

為了滿足不同的場景，MQTT支持三種不同級別的服務質(zhì)量（Quality of Service，QoS）為不同場景提供消息可靠性：

MQTT擁有14種不同的消息類型：

實現(xiàn)MQTT協(xié)議需要客戶端和服務器端通訊完成，在通訊過程中，MQTT協(xié)議中有三種身份：發(fā)布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務器，消息發(fā)布者可以同時是訂閱者。

MQTT傳輸?shù)南⒎譃椋褐黝}（Topic）和負載（payload）兩部分：

MQTT會構(gòu)建底層網(wǎng)絡(luò)傳輸：它將建立客戶端到服務器的連接，提供兩者之間的一個有序的、無損的、基于字節(jié)流的雙向傳輸。

當應用數(shù)據(jù)通過MQTT網(wǎng)絡(luò)發(fā)送時，MQTT會把與之相關(guān)的服務質(zhì)量（QoS）和主題名（Topic）相關(guān)連。

一個使用MQTT協(xié)議的應用程序或者設(shè)備，它總是建立到服務器的網(wǎng)絡(luò)連接。客戶端可以：

MQTT服務器以稱為"消息代理"（Broker），可以是一個應用程序或一臺設(shè)備。它是位于消息發(fā)布者和訂閱者之間，它可以：

訂閱包含主題篩選器（Topic Filter）和最大服務質(zhì)量（QoS）。訂閱會與一個會話（Session）關(guān)聯(lián)。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。

每個客戶端與服務器建立連接后就是一個會話，客戶端和服務器之間有狀態(tài)交互。會話存在于一個網(wǎng)絡(luò)之間，也可能在客戶端和服務器之間跨越多個連續(xù)的網(wǎng)絡(luò)連接。

連接到一個應用程序消息的標簽，該標簽與服務器的訂閱相匹配。服務器會將消息發(fā)送給訂閱所匹配標簽的每個客戶端。

一個對主題名通配符篩選器，在訂閱表達式中使用，表示訂閱所匹配到的多個主題。

消息訂閱者所具體接收的內(nèi)容。

MQTT協(xié)議中定義了一些方法（也被稱為動作），來于表示對確定資源所進行操作。這個資源可以代表預先存在的數(shù)據(jù)或動態(tài)生成數(shù)據(jù)，這取決于服務器的實現(xiàn)。通常來說，資源指服務器上的文件或輸出。主要方法有：

3. MQTT簡要介紹

——

[1.MQTT項目工程]()

[2.MQTT API說明文檔]()

[3.MQTT協(xié)議中文版]()

MQTT是一個客戶端服務端架構(gòu)的發(fā)布/訂閱模式的消息傳輸協(xié)議。它的設(shè)計思想是輕巧、開放、簡單、規(guī)范，易于實現(xiàn)。這些特點使得它對很多場景來說都是很好的選擇，特別是對于受限的環(huán)境如機器與機器的通信（M2M）以及物聯(lián)網(wǎng)環(huán)境（IoT）。

MQTT協(xié)議通過交換預定義的MQTT控制報文來通信。

報文格式: 固定包頭+可變包頭+payload。

固定包頭: 由兩個字節(jié)組成

byte1 高四位表示控制報文的類型，低四位表示控制報文類型的標志位。

? ? ? ? ? ? byte2表示剩余長度，包括可變報頭和負載的數(shù)據(jù)。剩余長度不包括用于編碼剩余長度字段本身的字節(jié)數(shù)。

可變包頭：

某些MQTT控制報文包含一個可變報頭部分。它在固定報頭和負載之間。可變報頭的內(nèi)容根據(jù)報文類型的不同而不同。可變報頭的報文標（Packet Identifier）字段存在于在多個類型的報文里。

有效載荷：

???對于PUBLISH來說有效載荷就是應用消息。

——1. 網(wǎng)絡(luò)建立連接后，客戶端發(fā)送的第一個報文必須是CONNECT報文

——2. 客戶端只能發(fā)送一次CONNECT 報文，發(fā)送兩次會當作協(xié)議違規(guī)處理，并斷開連接。

——3. 有效載荷包括：客戶端唯一標識符，will主題，will消息，用戶名和密碼。

——4.可變包頭：協(xié)議名（protocol name）+協(xié)議級別（protocol level）+連接標志（connect flags）+保持連接（keep alive）。

——5. 協(xié)議名： MQTT的UTF-8編碼的字符串。(MSB+LSB +MQTT 六個字節(jié))

——6. 協(xié)議級別：一個字節(jié)

——7. 連接標志：一個字節(jié)，包含一些用于指定MQTT連接行為的參數(shù)。同時還指出有效載荷中的字段是否存在。服務端必須驗證CONNECT控制報文的保留標志位（第0位）是否為0，如果不為0必須斷開客戶端連接。

——8. 清理會話：byte8 的bit1位標志。

? ? 這個二進制位指定了會話狀態(tài)的處理方式。客戶端和服務端可以保存會話狀態(tài)，以支持跨網(wǎng)絡(luò)連接的可靠消息傳輸。這個標志位用于控

? ?制會話狀態(tài)的生存時間。

? ? 標志設(shè)置為0：服務端必須基于當前會話（使用客戶端標識符識別）的狀態(tài)恢復與客戶端的通信。

? ? 標志設(shè)置為1：客戶端和服務端必須丟棄之前的任何會話并開始一個新的會話。會話僅持續(xù)和網(wǎng)絡(luò)連接同樣長的時間。

——9. 遺囑標志 WILL FLAG: byte8的bit2位標志。

遺囑標志（Will Flag）被設(shè)置為1，表示如果連接請求被接受了，遺囑（Will Message）消息必須被存儲在服務端并且與這個網(wǎng)絡(luò)連接關(guān)聯(lián)。之后網(wǎng)絡(luò)連接關(guān)閉時，服務端必須發(fā)布這個遺囑消息，除非服務端收到DISCONNECT報文時刪除了這個遺囑消息。

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

如果客戶端在合理的時間內(nèi)沒有收到服務端的CONNACK報文，客戶端應該關(guān)閉網(wǎng)絡(luò)連接。合理 的時間取決于應用的類型和通信基礎(chǔ)設(shè)施。

CONNACK報文沒有有效載荷。

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

固定包頭：

注意byte1的bit3為重發(fā)標志DUP。

如果DUP標志被設(shè)置為0，表示這是客戶端或服務端第一次請求發(fā)送這個PUBLISH報文。如果DUP標志被設(shè)置為1，表示這可能是一個早前報文請求的重發(fā)。

服務端發(fā)送PUBLISH報文給訂閱者時，收到（入站）的PUBLISH報文的DUP標志的值不會被傳播。發(fā)送（出站）的PUBLISH報文與收到（入站）的PUBLISH報文中的DUP標志是獨立設(shè)置的，它的值必須單獨的根據(jù)發(fā)送（出站）的PUBLISH報文是否是一個重發(fā)來確定。

可變包頭：

主題名 :topic name

報文標識符 ：packet identitfier。

有效載荷 ：有效載荷包含將被發(fā)布的應用消息。數(shù)據(jù)的內(nèi)容和格式是應用特定的。有效載荷的長度這樣計算：用固定報頭中的剩余長度字段的值減去可變報頭的長度。包含零長度有效載荷的PUBLISH報文是合法的。

響應：PUBLISH報文的接收者必須按照根據(jù)PUBLISH報文中的QoS等級發(fā)送響應。

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

PUBACK報文沒有有效載荷。

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

PUBREC報文沒有有效載荷。

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

PUBREL報文沒有有效載荷。

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

PUBCOMP報文沒有有效載荷。

客戶端向服務端發(fā)送 SUBSCRIBE 報文用于創(chuàng)建一個或多個訂閱。每個訂閱注冊客戶端關(guān)心的一個或多個主題。為了將應用消息轉(zhuǎn)發(fā)給與那些訂閱匹配的主題，服務端發(fā)送PUBLISH報文給客戶端。SUBSCRIBE報文也（為每個訂閱）指定了最大的QoS等級，服務端根據(jù)這個發(fā)送應用消息給客戶端。

有效載荷：

SUBSCRIBE報文的有效載荷包含了一個主題過濾器列表，它們表示客戶端想要訂閱的主題。SUBSCRIBE報文的有效載荷必須包含至少一對主題過濾器 和 QoS等級字段組合。沒有有效載荷的SUBSCRIBE報文是違反協(xié)議的。

響應：

服務端收到客戶端發(fā)送的一個SUBSCRIBE報文時，必須使用SUBACK報文響應，SUBACK報文必須和等待確認的SUBSCRIBE報文有相同的報文標識符。

服務端發(fā)送SUBACK報文給客戶端，用于確認它已收到并且正在處理SUBSCRIBE報文。SUBACK報文包含一個返回碼清單，它們指定了SUBSCRIBE請求的每個訂閱被授予的最大QoS等級。

有效載荷：

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

客戶端發(fā)送UNSUBSCRIBE報文給服務端，用于取消訂閱主題。

有效載荷 ：

UNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。

UNSUBSCRIBE報文中的主題過濾器必須是連續(xù)打包的、按照定義的UTF-8編碼字符串?

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

響應：

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

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

——它必須停止分發(fā)任何新消息給這個客戶端 []。

——它必須完成分發(fā)任何已經(jīng)開始往客戶端發(fā)送的QoS 1和QoS 2的消息 []。

——它可以繼續(xù)發(fā)送任何現(xiàn)存的準備分發(fā)給客戶端的緩存消息。

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

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

服務端發(fā)送UNSUBACK報文給客戶端用于確認收到UNSUBSCRIBE報文。

UNSUBACK報文沒有有效載荷。

客戶端發(fā)送PINGREQ報文給服務端的。用于：

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

2. 請求服務端發(fā)送 響應確認它還活著。

3. 使用網(wǎng)絡(luò)以確認網(wǎng)絡(luò)連接沒有斷開。

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

——PINGREQ報文沒有可變報頭。

——PINGREQ報文沒有有效載荷。

響應：

服務端必須發(fā)送 PINGRESP報文響應客戶端的PINGREQ報文。

服務端發(fā)送PINGRESP報文響應客戶端的PINGREQ報文。表示服務端還活著。

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

PINGRESP報文沒有可變報頭。

PINGRESP報文沒有有效載荷。

DISCONNECT報文是客戶端發(fā)給服務端的最后一個控制報文。表示客戶端正常斷開連接。

DISCONNECT報文沒有可變報頭。

DISCONNECT報文沒有有效載荷。

響應：

客戶端發(fā)送DISCONNECT報文之后：

—— 必須關(guān)閉網(wǎng)絡(luò)連接 [MQTT-3.14.4-1]。

——不能通過那個網(wǎng)絡(luò)連接再發(fā)送任何控制報文。

服務端在收到DISCONNECT報文時：

——必須丟棄任何與當前連接關(guān)聯(lián)的未發(fā)布的遺囑消息。

——應該關(guān)閉網(wǎng)絡(luò)連接，如果客戶端 還沒有這么做。

為了提供服務質(zhì)量保證，客戶端和服務端有必要存儲會話狀態(tài)。在整個會話期間，客戶端和服務端都必須存儲會話狀態(tài) 。會話必須至少持續(xù)和它的活躍網(wǎng)絡(luò)連接同樣長的時間。服務端的保留消息不是會話狀態(tài)的組成部分。服務端應該保留那種消息直到客戶端刪除它。

MQTT協(xié)議要求基礎(chǔ)傳輸層能夠提供有序的、可靠的、雙向傳輸（從客戶端到服務端 和從服務端到客戶端）的字節(jié)流。

無連接的網(wǎng)絡(luò)傳輸協(xié)議如UDP是不支持的，因為他們可能會丟失數(shù)據(jù)包或?qū)?shù)據(jù)包重排序。

MQTT按照這里定義的服務質(zhì)量 (QoS) 等級分發(fā)應用消息。分發(fā)協(xié)議是對稱的，在下面的描述中，客戶端和服務端既可以是發(fā)送者也可以是接收者。分發(fā)協(xié)議關(guān)注的是從單個發(fā)送者到單個接收者的應用消息。服務端分發(fā)應用消息給多個客戶端時，每個客戶端獨立處理。分發(fā)給客戶端的出站應用消息和入站應用消息的QoS等級可能是不同的。

qos0：最多分發(fā)一次

qos1：至少分發(fā)一次

qos2：僅分發(fā)一次

客戶端設(shè)置清理會話（CleanSession）標志為0重連時，客戶端和服務端必須使用原始的報文標識符重發(fā)任何未確認的PUBLISH報文（如果QoS0）和PUBREL報文 [MQTT-4.4.0-1]。這是唯一要求客戶端或服務端重發(fā)消息的情況。

服務端接管入站應用消息的所有權(quán)時，它必須將消息添加到訂閱匹配的客戶端的會話狀態(tài)。正常情況下，客戶端收到發(fā)送給它的訂閱的消息。客戶端也可能收到不是與它的訂閱精確匹配的消息。如果服務端自動給客戶端分配了一個訂閱，可能發(fā)生這種情況。正在處理UBSUBSCRIBE請求時也可能收到消息。客戶端必須按照可用的服務質(zhì)量（QoS）規(guī)則確認它收到的任何PUBLISH報文，不管它選擇是否處理報文包含的應用消息 。

實現(xiàn)本章定義的協(xié)議流程時，客戶端必須遵循下列規(guī)則：

重發(fā)任何之前的PUBLISH報文時，必須按原始PUBLISH報文的發(fā)送順序重發(fā)（適用于QoS 1和QoS 2消息）[MQTT-4.6.0-1]。

——必須按照對應的PUBLISH報文的順序發(fā)送PUBACK報文（QoS 1消息）。

——必須按照對應的PUBLISH報文的順序發(fā)送PUBREC報文（QoS 2消息。

——必須按照對應的PUBREC報文的順序發(fā)送PUBREL報文（QoS 2消息）。

服務端必須默認認為每個主題都是有序的。它可以提供一個管理功能或其它機制，以允許將一個或多個主題當作是無序的 。

服務端處理發(fā)送給有序主題的消息時，必須按照上面的規(guī)則將消息分發(fā)給每個訂閱者。此外，它必須按照從客戶端收到的順序發(fā)送PUBLISH報文給消費者（對相同的主題和QoS）。

斜杠（‘/’ U+002F）用于分割主題的每個層級，為主題名提供一個分層結(jié)構(gòu).

數(shù)字標志（‘#’ U+0023）是用于匹配主題中任意層級的通配符。

加號 (‘+’ U+002B) 是只能用于單個主題層級匹配的通配符。

服務端不能將 $ 字符開頭的主題名匹配通配符 (#或+) 開頭的主題過濾器.

$SYS/ 被廣泛用作包含服務器特定信息或控制接口的主題的前綴。

應用不能使用 $ 字符開頭的主題。

訂閱 “#” 的客戶端不會收到任何發(fā)布到以 “$” 開頭主題的消息。

訂閱 “+/monitor/Clients” 的客戶端不會收到任何發(fā)布到 “$SYS/monitor/Clients” 的消息。

訂閱 “$SYS/#” 的客戶端會收到發(fā)布到以 “$SYS/” 開頭主題的消息。

訂閱 “$SYS/monitor/+” 的客戶端會收到發(fā)布到 “$SYS/monitor/Clients” 主題的消息。

如果客戶端想同時接受以 “$SYS/” 開頭主題的消息和不以 $ 開頭主題的消息，它需要同

時訂閱 “#” 和 ““$SYS/#”。

除非另有說明，如果服務端或客戶端遇到了協(xié)議違規(guī)的行為，它必須關(guān)閉傳輸這個協(xié)議違規(guī)控制報文的網(wǎng)絡(luò)連接.

MQTT方案通常部署在不安全的通信環(huán)境中。在這種情況下，協(xié)議實現(xiàn)通常需要提供這些機制：

——用戶和設(shè)備身份認證

——服務端資源訪問授權(quán)

——MQTT控制報文和內(nèi)嵌應用數(shù)據(jù)的完整性校驗

——MQTT控制報文和內(nèi)嵌應用數(shù)據(jù)的隱私控制

作為傳輸層協(xié)議，MQTT僅關(guān)注消息傳輸，提供合適的安全功能是實現(xiàn)者的責任。使用TLS[RFC5246] 是比較普遍的選擇。

廣泛采用高級加密標準 [AES] 數(shù)據(jù)加密標準 [DES] 。

推薦使用為受限的低端設(shè)備特別優(yōu)化過的輕量級加密國際標準 ISO 29192 [ISO29192] 。

如果MQTT在WebSocket [RFC6455] 連接上傳輸，必須滿足下面的條件：

——MQTT控制報文必須使用WebSocket二進制數(shù)據(jù)幀發(fā)送。如果收到任何其它類型的數(shù)據(jù)幀，接收者必須關(guān)閉網(wǎng)絡(luò)連接 。

——單個WebSocket數(shù)據(jù)幀可以包含多個或者部分MQTT報文。接收者不能假設(shè)MQTT控制報文按WebSocket幀邊界對齊 。

——客戶端必須將字符串 mqtt 包含在它提供的WebSocket子協(xié)議列表里 。

——服務端選擇和返回的WebSocket子協(xié)議名必須是 ?。

——用于連接客戶端和服務器的WebSocket URI對MQTT協(xié)議沒有任何影響。

MQTT規(guī)范定義了MQTT客戶端實現(xiàn)和MQTT服務端實現(xiàn)的一致性要求

MQTT實現(xiàn)可以同時是MQTT客戶端和MQTT服務端。接受入站連接和建立到其它服務端的出站連接的服務端必須同時符合MQTT客戶端和MQTT服務端的要求 。

為了與任何其它的一致性實現(xiàn)交互操作，一致性實現(xiàn)不能要求使用在本規(guī)范之外定義的任何擴展 。

附錄：

控制報文類型

byte1：標志位flags：

Mqtt介紹一

MQTT ( 消息隊列遙測傳輸 )是ISO 標準(ISO/IEC PRF 20922)下基于發(fā)布/訂閱范式的消息協(xié)議。它工作在 TCP/IP協(xié)議族 上，是為硬件性能低下的遠程設(shè)備以及網(wǎng)絡(luò)狀況糟糕的情況下而設(shè)計的發(fā)布/訂閱型消息協(xié)議，為此，它需要一個 消息中間件 。

MQTT是一個基于客戶端-服務器的消息發(fā)布/訂閱傳輸協(xié)議。MQTT協(xié)議是輕量、簡單、開放和易于實現(xiàn)的，這些特點使它適用范圍非常廣泛。在很多情況下，包括受限的環(huán)境中，如：機器與機器（M2M）通信和物聯(lián)網(wǎng)（IoT）。其在，通過衛(wèi)星鏈路通信傳感器、偶爾撥號的醫(yī)療設(shè)備、智能家居、及一些小型化設(shè)備中已廣泛使用。

MQTT協(xié)議是為大量計算能力有限，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠程傳感器和控制設(shè)備通訊而設(shè)計的協(xié)議，它具有以下主要的幾項特性：

實現(xiàn)MQTT協(xié)議需要客戶端和服務器端通訊完成，在通訊過程中，MQTT協(xié)議中有三種身份： 發(fā)布者（Publish） 、 代理（Broker） （服務器） 、訂閱者（Subscribe） 。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務器，消息發(fā)布者可以同時是訂閱者。

MQTT傳輸?shù)南⒎譃椋?主題（Topic）和負載（payload） 兩部分：

MQTT服務器以稱為"消息代理"（Broker），可以是一個應用程序或一臺設(shè)備。它是位于消息發(fā)布者和訂閱者之間，它可以：

在MQTT協(xié)議中，一個MQTT數(shù)據(jù)包由： 固定頭（Fixed header）、可變頭（Variable header）、消息體（payload） 三部分構(gòu)成。MQTT數(shù)據(jù)包結(jié)構(gòu)如下：

（1） 固定頭（Fixed header） 。存在于所有MQTT數(shù)據(jù)包中，表示數(shù)據(jù)包類型及數(shù)據(jù)包的分組類標識。

（2） 可變頭（Variable header） 。存在于部分MQTT數(shù)據(jù)包中，數(shù)據(jù)包類型決定了可變頭是否存在及其具體內(nèi)容。

（3） 消息體（Payload） 。存在于部分MQTT數(shù)據(jù)包中，表示客戶端收到的具體內(nèi)容。

固定頭存在于所有MQTT數(shù)據(jù)包中，其結(jié)構(gòu)如下：

相于一個4位的無符號值，類型、取值及描述如下

在不使用標識位的消息類型中，標識位被作為保留位。如果收到無效的標志時，接收端必須關(guān)閉網(wǎng)絡(luò)連接：

Payload消息體位MQTT數(shù)據(jù)包的第三部分，包含CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息：

怎么將消息發(fā)送到mqtt代理服務器

通過Cocoa Pods添加MQTTKit

MQTTKit在github上鏈接，down下來。

cd到工程目錄，輸入pod install，用xcode打開工程的打開xcworkspace擴展名的文件。

如果不是MQTTKit存在更新的版本，則輸入pod update。

新建一個MQTT的服務請求

NSString *clientID = ...

MQTTClient *client = [[MQTTClient alloc] initWithClientId:clientID];

發(fā)送消息，每次發(fā)送消息包括目標host和本地MQTT消息.具體MQTT格式消息見代碼。這里Host可以是Server的IP，不需要host表解析。

// connect to the MQTT server

[self.client connectToHost:@"iot.eclipse.org"

completionHandler:^(NSUInteger code) {

if (code == ConnectionAccepted) {

// when the client is connected, send a MQTT message

[self.client publishString:@"Hello, MQTT"

toTopic:@"/MQTTKit/example"

withQos:AtMostOnce

retain:NO

completionHandler:^(int mid) {

NSLog(@"message has been delivered");

}];

}

}];

訂閱主題并接受MQTT格式的消息，這部分在viewdidload中實現(xiàn)。

// define the handler that will be called when MQTT messages are received by the client

[self.client setMessageHandler:^(MQTTMessage *message) {

NSString *text = [message.payloadString];

NSLog(@"received message %@", text);

}];

// connect the MQTT client

[self.client connectToHost:@"iot.eclipse.org"

completionHandler:^(MQTTConnectionReturnCode code) {

if (code == ConnectionAccepted) {

// when the client is connected, subscribe to the topic to receive message.

[self.client subscribe:@"/MQTTKit/example"

withCompletionHandler:nil];

}

}];

斷開連接

[self.client disconnectWithCompletionHandler:^(NSUInteger code) {

// The client is disconnected when this completion handler is called

NSLog(@"MQTT client is disconnected");

}];

整個連接建立、發(fā)送消息、接受消息、斷開連接都是通過Block的消息機制來實現(xiàn)，因此需要對block有很好地理解。

網(wǎng)站標題：go語言mqtt服務 go語言通信
URL標題：http://chinadenli.net/article8/doghhip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、品牌網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、手機網(wǎng)站建設(shè)、云服務器、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)