本發(fā)明涉及工業(yè)領(lǐng)域，尤其涉及一種通訊方法。

背景技術(shù)：

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展，在工業(yè)領(lǐng)域也越來越多的應用物聯(lián)網(wǎng)技術(shù)，越來越多的工業(yè)應用轉(zhuǎn)移到云端，通過互聯(lián)網(wǎng)和物聯(lián)網(wǎng)進行工業(yè)應用數(shù)據(jù)的傳輸變得日趨重要。在傳統(tǒng)的工業(yè)自動化系統(tǒng)應用中，應用數(shù)據(jù)的傳輸都在局域網(wǎng)或者專用廣域網(wǎng)內(nèi)，網(wǎng)絡本身已經(jīng)在很大程度上保障了數(shù)據(jù)傳輸?shù)臅r效和安全。在典型互聯(lián)網(wǎng)應用中，更側(cè)重于客戶端對服務端的數(shù)據(jù)訪問，以及通過服務端提供的服務對數(shù)據(jù)庫等服務端資源的修改，往往需要承受大量的并發(fā)訪問壓力。而工業(yè)物聯(lián)網(wǎng)應用與其二者均有不同之處，工業(yè)物聯(lián)網(wǎng)的應用數(shù)據(jù)將不再局限于局域網(wǎng)或?qū)Ｓ镁W(wǎng)，而是要經(jīng)過物聯(lián)網(wǎng)和互聯(lián)網(wǎng)進入云端應用；對于客戶端的并發(fā)訪問壓力相對較小，但對與處于物聯(lián)網(wǎng)中的智能設(shè)備具有大量的控制需求，并且區(qū)別于民用領(lǐng)域，對于安全性要求更高。

技術(shù)實現(xiàn)要素：

本發(fā)明實施例提供一種通訊方法，以解決工業(yè)物聯(lián)網(wǎng)應用使用傳統(tǒng)工業(yè)現(xiàn)場通訊協(xié)議和普通互聯(lián)網(wǎng)通訊協(xié)議不適用于工業(yè)應用在物聯(lián)網(wǎng)和互聯(lián)網(wǎng)環(huán)境傳輸數(shù)據(jù)和遠程控制的問題。

本發(fā)明實施例采用如下技術(shù)方案：

一種通訊方法，包括：

發(fā)布終端與訂閱終端分別與云端服務器建立通信連接；

所述訂閱終端通過所述云端服務器向所述發(fā)布終端訂閱主題；

所述發(fā)布終端通過所述云端服務器向所述訂閱終端推送所述訂閱主題的消息。

基于上述技術(shù)方案的通訊方法，發(fā)布終端與訂閱終端分別與云端服務器建立通信連接；訂閱終端通過云端服務器向發(fā)布終端訂閱主題；發(fā)布終端通過所述云端服務器向訂閱終端推送訂閱主題的消息。

應當理解的是，以上的一般描述和后文的細節(jié)描述僅是示例性和解釋性的，并不能限制本公開。

附圖說明

此處的附圖被并入說明書中并構(gòu)成本說明書的一部分，示出了符合本發(fā)明的實施例，并與說明書一起用于解釋本發(fā)明的原理。

圖1為本發(fā)明實施例示出的一種通訊方法的流程圖。

圖2-圖34為本發(fā)明實施例示出的一種消息結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在未做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

實施例1

如圖1所示，本發(fā)明實施例提供一種通訊方法，包括：

11、發(fā)布終端與訂閱終端分別與云端服務器建立通信連接；

12、所述訂閱終端通過所述云端服務器向所述發(fā)布終端訂閱主題；

13、所述發(fā)布終端通過所述云端服務器向所述訂閱終端推送所述訂閱主題的消息。

本發(fā)明實施例中，，發(fā)布終端、訂閱終端和與服務器之間通過以下幾種流程實現(xiàn)通訊：1、發(fā)布者或訂閱者(客戶端)與代理(服務器)之間的的連接和認證流程。2、發(fā)布者或訂閱者(客戶端)與代理(服務器)的鏈路測試流程。3、發(fā)布者、代理與訂閱者之間的主題配置流程(包括主題注冊、主題刪除和主題通知)。4、訂閱者與代理之間的主題訂閱流程(包括訂閱和取消訂閱)。5、發(fā)布者與代理之間的主題發(fā)布流程。6、代理與訂閱者之間的主題推送流程。7、訂閱者、代理與發(fā)布者之間的主題設(shè)置流程。流程示意圖如圖2所示。

本發(fā)明實施例中為了實現(xiàn)一種用于工業(yè)物聯(lián)網(wǎng)的基于代理的訂閱/發(fā)布式消息傳輸和遠程控制的方法，上述流程中，使用了28種消息類型，這些不同類型的消息擁有類似的消息結(jié)構(gòu)，即整個消息由兩部分組成，消息頭部和消息主體。其中，消息頭部固定為2個字節(jié)，包含5bits的消息類型，11bits的消息主體長度，如圖3所示。本發(fā)明實施例中不同的消息類型，消息主體的格式不盡相同，具體格式在流程中詳述。消息類型的取值在前文表格中已經(jīng)給出。消息長度的取值為0～2047，單位是字節(jié)。為了盡量減少網(wǎng)絡開銷，消息長度一般小于1400字節(jié)。

本發(fā)明實施例中，訂閱終端(subscriber)與云端服務器(broker)之間的主題訂閱流程。具體如下：

SUBSCRIBE，subscriber通過向broker發(fā)送主題訂閱消息告知broker其希望接收的主題消息，當相應的主題消息被發(fā)布終端(publisher)發(fā)布后，broker會盡快向subscriber進行主動推送。向broker訂閱主題的消息格式具體如圖4所示。

其中，主題配置信息為json字符串，是否加密取決于CONNECT時的配置。

Json對象的每個屬性都是一個publisher的訂閱關(guān)鍵詞的集合數(shù)組，屬性名使用publisher在broker注冊的用戶名稱。

Broker通過查詢每個訂閱關(guān)鍵詞實現(xiàn)訂閱記錄。訂閱關(guān)鍵詞支持一下幾種匹配模式：主題標識精確匹配，即訂閱關(guān)鍵詞與主題標識完全相同。主題標識模糊匹配，即訂閱關(guān)鍵詞與主題標識的部分相同。訂閱組精確匹配，即訂閱關(guān)鍵詞與某個訂閱組名稱完全相同。訂閱組模糊匹配，即訂閱關(guān)鍵詞與訂閱組名稱部分相同。其中模糊匹配時，支持通配符，星號(*)和問號(？)。星號(*)代表0個或多個字符。問號(？)代表0個或1個字符。能夠符合匹配條件的主題被加入subscriber的訂閱集合中。

SUBACK，broker解析SUBSCRIBE消息的訂閱關(guān)鍵詞后，查詢每個訂閱關(guān)鍵詞并將符合條件的主題加入到該subscriber的訂閱集合中。訂閱集合可以通過配置文件或數(shù)據(jù)庫表或數(shù)據(jù)庫文檔(例如mongodb)實現(xiàn)，例如，使用數(shù)據(jù)庫表SUBSET(ID，TOPICID，SUBSCRIBERID)來記錄訂閱關(guān)系，ID為無意義整數(shù)ID用于避免記錄重復，TOPICID為主題標識，SUBSCRIBERID為訂閱者ID。記錄完成后，broker向subscriber發(fā)送確認消息(SUBACK)，具體如圖5所示。

UNSUBSCRIBE，當subscriber不再需要訂閱某個或某些主題時，通過UNSUBSCRIBE消息向broker取消訂閱主題。具體格式如圖6所示。

其中，取消訂閱關(guān)鍵詞是UTF-8編碼格式的json字符串，所有取消訂閱的關(guān)鍵詞作為unsubscribe數(shù)組的元素，具體格式如圖6所示。

UNSUBACK，broker解析UNSUBSCRIBE消息的取消訂閱關(guān)鍵詞后，查詢每個取消訂閱關(guān)鍵詞并將符合條件的主題從該subscriber的訂閱集合中刪除。訂閱集合可以通過配置文件或數(shù)據(jù)庫表或數(shù)據(jù)庫文檔(例如mongodb)實現(xiàn)，例如，使用數(shù)據(jù)庫表SUBSET(ID，TOPICID，SUBSCRIBERID)來記錄訂閱關(guān)系，ID為無意義整數(shù)ID用于避免記錄重復，TOPICID為主題標識，SUBSCRIBERID為訂閱者ID。

符合條件的記錄刪除完成后，broker向subscriber發(fā)送確認消息(UNSUBACK)，具體如圖7所示。

本發(fā)明實施例中，publisher與broker之間的主題發(fā)布流程，具體如下：

PUBLISH，用于有新的消息(或數(shù)據(jù))產(chǎn)生時，publisher向broker發(fā)布主題消息，具體消息格式如圖8所示。其中，前7字節(jié)為固定格式，后面為可變格式。

固定格式包括以下幾項內(nèi)容：消息序列號，位置Byte2～Byte3，2字節(jié)，高字節(jié)在前，低字節(jié)在后。表示同一主題的不同時刻的消息發(fā)送的順序，該消息序列號由publisher維護，從0開始，每發(fā)送一次消息，消息序列號自增1，達到最大值65535后，重新從0開始計數(shù)。消息序列號的增加(變化)，表示有新的消息產(chǎn)生。功能標志位，位置Byte 4，1字節(jié)。加密消息，位置bit7，0表示當前消息不加密，1表示當前消息加密。PUBLISH消息的數(shù)據(jù)加密開關(guān)不使用CONNECT消息中的設(shè)置，而是由每個消息中的加密標志位決定，如果加密，則對從Byte7開始的可變格式內(nèi)容進行加密，加密算法等相關(guān)參數(shù)使用CONNECT消息的設(shè)置。需要確認，位置bit6，0表示當前PUBLISH消息被broker接收到后，不需要任何確認；1表示當前PUBLISH消息被broker接收到后，需要使用PUBACK消息進行確認。重發(fā)消息，位置bit5，0表示正常發(fā)送，1表示該消息為重發(fā)消息。當超時時間內(nèi)沒有收到broker的確認消息(使用CONNECT消息中設(shè)置的消息超時時間)，publisher向broker重發(fā)PUBLISH消息，并且將重發(fā)標志位置為1，最多重發(fā)3次，如果仍然失敗，則表示鏈路出現(xiàn)問題，需要重連。重發(fā)時，即重發(fā)標志位為1時，消息序列號不變。時間戳，位置bit 4，1表示消息包含時間戳，0表示消息不含時間戳。主題數(shù)據(jù)類型(格式)，位置Byte 5，表示該消息內(nèi)主題數(shù)據(jù)的數(shù)據(jù)類型或者格式，以便于broker或subscriber進行解析，0：RAW，原始字節(jié)流，應用格式由publisher和subscriber雙方約定，1：UINT8，無符號8位整型，1字節(jié)，2：INT8，有符號8位整型，1字節(jié)，3：UINT16，無符號16位整型，2字節(jié)，4：INT16，有符號16位整型，2字節(jié)，5：UINT32，無符號32位整型，4字節(jié)，6：INT32，有符號32位整型，4字節(jié)，7：UINT64，無符號64位整型，8字節(jié)，8：INT64，有符號64位整型，8字節(jié)，9：float，有符號單精度浮點型，4字節(jié)，10：double，有符號雙精度浮點型，8字節(jié)，11：bool，布爾型，1字節(jié)，0x00表示false，0xFF表示true，12：UTF8string，UTF-8字符流，不含字符串結(jié)束標記，13：ASCII string，ASCII碼字符流，不含字符串結(jié)束標記，14～127：保留，128～255：未定義，由publisher和subscriber雙方約定自定義擴展，當“單元數(shù)據(jù)類型”為0、12～15，傳送非數(shù)值類型主題數(shù)據(jù)時，每個消息只能傳送一個主題數(shù)據(jù)單元。字符串類型消息，采用UTF-8格式字符串，N字節(jié)，必須小于消息最大長度(1400)“單元數(shù)據(jù)類型”決定了“主題數(shù)據(jù)單元”中“數(shù)據(jù)”的字節(jié)長度。主題地址，位置Byte 6～Byte 7，占用2個字節(jié)，高字節(jié)在前，低字節(jié)在后，有效范圍0～65535。主題地址是主題標識(主題ID)在publisher內(nèi)部的表示形式，代替冗長的字符主題標識，能夠有效的降低網(wǎng)絡開銷，節(jié)約流量。

可變格式包括以下幾項內(nèi)容：時間戳，如果在“時間戳”功能標志位啟用了時間戳功能，“主題地址”后面將緊跟9個字節(jié)的時間戳。其格式為9個字節(jié)的日歷時間，如圖9。

主題數(shù)據(jù)，如果在“時間戳”功能標志位未啟用時間戳功能，“主題地址”后面將緊跟主題數(shù)據(jù)內(nèi)容，反之，主題數(shù)據(jù)在時間戳之后，即從Byte 16開始。主題數(shù)據(jù)的具體格式由“主題數(shù)據(jù)類型(格式)”決定。

PUBACK，用于broker對PUBLISH消息的確認。不是所有的PUBLISH消息都需要回復確認，只有當PUBLISH消息中的“需要確認”標志位被置為1時，該消息必須使用PUBACK消息回復確認?；貜蚉UBACK前，必須完成對PUBLISH消息中主題數(shù)據(jù)的解析和緩存。

消息格式如圖10所示。其中，“消息序列號”必須與確認的PUBLISH消息的“消息序列號”相同，表示對該序列號的消息已經(jīng)解析并緩存成功，對其進行確認。Broker不對“消息序列號”做任何處理，只在確認時，將其從PUBLISH消息拷貝值PUBACK消息，消息序列號由publisher進行維護。

在一個實施例中，所述發(fā)布終端與訂閱終端分別與云端服務器建立通信連接包括：所述發(fā)布終端及所述訂閱終端在每次連接到所述云端服務器前，通過審核方式進行身份的注冊和認證。

以下詳細介紹本發(fā)明實施例publisher、subscriber與broker之間的連接和認證流程。其中，publisher和subscriber都是客戶端(client，在連接與認證流程中，使用client指代publisher和subscriber)，broker是云服務端(server)。

在每個client首次連接到服務器并認證前，需通過人工審核方式進行身份的注冊和認證(例如：使用安全的WEB服務站點完成注冊和密鑰的交換)，具體步驟如下：

Server制作自身的私鑰與公鑰。Server使用openssl命令行工具生成一對1024位PKCS#8格式的密鑰對，即公鑰和私鑰。具體的實現(xiàn)中，可以由服務器提供的openssl工具定期更新server密鑰對。然后使用特殊的主題主動向各個客戶端推送server公鑰。具體在后文中詳述(PUSH消息)。

Client制作自身的私鑰月公鑰。Client使用與server約定的加密方法制作自身的私鑰與公鑰。Client同樣使用openssl命令行工具生成一對1024位PKCS#8格式的密鑰對，即公鑰和私鑰。

注冊用戶。Client在server上注冊用戶，并設(shè)置相應的密碼，server為client分配唯一的clientID(例如：在client表中新增一條記錄，其ID為1，)，ClientID格式為32位的無符號整數(shù)(占用4個字節(jié))。Client從Server下載ClientID，并將其妥善保存。

交換密鑰。Client將自己的公鑰上傳至Server，Server將其進行存儲(具體存儲方式不限，數(shù)據(jù)庫、文件或其它均可，例如：存儲在client表的pubkey字段中)。同時，Client從Server處下載Server的公鑰文件(broker.pubkey)，并妥善保存。

自動執(zhí)行的流程。正常通訊時，按照下面步驟(通過程序自動完成)進行，具體如下：

CONNECT，client向server發(fā)送連接請求消息，消息主體攜帶使用server公鑰加密的clientID。首先由發(fā)布者或者訂閱者向代理CONNECT消息，建立通訊鏈路，具體消息格式如圖11所示。CONNECT消息中包含了協(xié)議版本號、消息超時時間、及消息加密方式等相關(guān)信息。

協(xié)議版本。版本格式為V主版本號.子版本號，例如：V1.0。主版本號代表了協(xié)議內(nèi)容的較大變動，并不一定保證向下兼容，子版本號則是較小的改動，在同一主版本號時，不同子版本之間的程序也能互相兼容。Byte1是協(xié)議主版本號，Byte2是協(xié)議子版本號。

消息超時時間。該時間用于鏈路測試，即在該時間段內(nèi)沒有收到對方的任意合法消息，則認定通訊中斷。

消息加密方式。前文提到的RSA公鑰和私鑰是用于發(fā)布者和訂閱者的身份認證，在消息傳輸過程中，使用這種非對稱加密方式則會大大降低消息傳輸?shù)膶崟r性，而對稱加密速度快，故在進行實際的消息數(shù)據(jù)傳輸時，選擇使用對稱加密算法，如AES、Blowfish，Byte6中設(shè)定的有關(guān)加密的信息決定了當前連接建立后，進行數(shù)據(jù)傳輸時的加密方式。

消息加密算法。0：不加密，1：Blowfish，2：AES，這里的加密算法選擇，決定了在CONNACK時，代理(服務器)生成的隨即密碼長度，而隨機密碼即在本次連接有效期(連接斷開前)內(nèi)進行數(shù)據(jù)加密傳輸時的密鑰。選擇不加密時，隨機密碼僅用于身份認證，長度一般為32。選擇Blowfish時，隨機密碼長度為2～56(16bits～448bits)，一般為32。選擇AES時，隨機密碼長度為16(128bits)、24(196bits)或32(256bits)，一般為32。

消息加密模式。0：不加密，1：ECB，2：CBC，3：CTR，4：OFB，5：CFB。

消息加密模式。0：不加密，1：zeropadding，2：pkcs5padding，3：pkcs7padding，4：iso10126，5：ansix923。具體關(guān)于加密算法相關(guān)概念請自行查找資料閱讀，在此不再贅述。

圖12是按照舉例數(shù)據(jù)填充消息的例子：

CONNACK，server使用私鑰解密出clientID，并查找出對應的client公鑰和私鑰。例如：使用server的私鑰解密(使用openssl工具)后，clientID為1，然后在client表中查找ID為1的記錄，找到后從記錄中讀取其字段pubkye的值，即clientID對應的公鑰。

server向client發(fā)送確認連接消息，如果連接成功，則Server生成25位長的隨機密碼(例如：7lr5BR7aV！L2TYkNR3J9i！5zS)，消息主體攜帶使用server私鑰加密后的隨機密碼。

這里的隨機密碼位數(shù)與CONNECT時設(shè)定的加密算法有關(guān)。具體長度詳見CONNECT中的說明。消息結(jié)構(gòu)如圖13所示。

其中：連接返回狀態(tài)碼是Server根據(jù)返回給Client的連接結(jié)果。取值的意義如下：0：連接成功，1：連接失敗，原因是使用server私鑰對ClientID密文解密失敗。2：連接失敗，原因是ClientID不存在。圖14是按照舉例數(shù)據(jù)填充消息的例子。

AUTHEN，client使用server公鑰解密出隨機密碼。RSA密鑰對(公鑰和私鑰)中，使用其中一個密鑰加密的密文，必然能夠使用另一個密鑰解密，所以使用server的私鑰加密的隨機密碼，只能夠使用server的公鑰來解密。

如果解密失敗，則說明server身份可疑，不再向server發(fā)送任何消息。如果解密成功，client向server發(fā)送認證消息，消息主體攜帶使用client私鑰加密的隨機密碼。

消息結(jié)構(gòu)如圖15所示。圖16是按照舉例數(shù)據(jù)填充消息的例子。

AUTHACK，server使用client公鑰解密隨機密碼，并對比是否一致，將認證結(jié)果返回client，告知其原因。消息結(jié)構(gòu)如圖17所示。其中：認證結(jié)果狀態(tài)碼是Server返回給Client的認證結(jié)果。取值的意義如下：0：認證成功，1：認證失敗，原因是使用server私鑰對ClientID密文解密失敗。2：連接失敗，原因是隨即密碼錯誤，則說明client身份可疑。圖18是認證成功時填充消息的例子：

DISCONN，當需要從server斷開時，client主動向server發(fā)送DISCONN消息。消息結(jié)構(gòu)如圖19所示。

在一個實施例中，所述發(fā)布終端與訂閱終端分別與云端服務器建立通信連接之后還包括：所述發(fā)布終端與所述云端服務器進行鏈路測試，所述訂閱終端與所述云端服務器進行鏈路測試。

本發(fā)明實施例中publisher、subscriber與broker之間的鏈路測試流程。其中，publisher和subscriber都是客戶端(client)，broker是服務端(server)。鏈路測試用于client和server之間達到預先設(shè)定的超時時間(通過CONNECT消息設(shè)定)時，測試鏈路是否正常。超時計時由client端和server端分別進行，并且從接收到任意一個消息之后開始。即client端在超時時間內(nèi)未收到server端任何消息，則判定自身與server的連接斷開，并嘗試進行重連；server端為每個client都分配一個超時計時器，server端在超時時間內(nèi)未收到某個client端任何消息，則判定該client與server的連接斷開，并清除當前連接內(nèi)的設(shè)置(CONNECT消息設(shè)定的信息)。

進行鏈路測試的具體流程如下：

LINKTEST，client向server發(fā)送鏈路測試消息。消息格式如圖20所示。

LINKACK，server向client發(fā)送鏈路確認消息。消息格式如圖21所示。

在一個實施例中，所述發(fā)布終端與訂閱終端分別與云端服務器建立通信連接包括：所述發(fā)布終端向所述云端服務器注冊，所述訂閱終端向所述云端服務器注冊。

本發(fā)明實施例中還包括主題配置(注冊、刪除和通知)，發(fā)布者、代理與訂閱者之間的主題配置流程(包括主題注冊、主題刪除和主題通知)。具體如下：

REGIST，publisher向broker發(fā)送主題注冊消息，消息主體攜帶主題配置信息，主題配置信息(需要提供其格式)包括：主題標識(UTF8字符串)、主題消息服務質(zhì)量級別(最多一次、最少一次、只有一次到達subscriber)等。

主題配置信息為UTF-8格式的json字符串。具體格式如下：

{

“ID”:”1#車間_2#流水線_3#設(shè)備_模擬量1”,

“dest”:“”,

“addr”:1,

“type”:”INT32”,

“group”:[“訂閱組1”,“訂閱組2”],

“cacheNum”:100,

“setting”:{

“guardTime”:5000,

“needApproval”:1

},

“retain”:true,

“deleted”:false

}

其中，”ID”是主題標識，值為字符串類型，可以使用UTF-8編碼中的字母、數(shù)字、_(下劃線)、#、$、@及漢字。其中”_”下劃線用于自然分組，這在訂閱時可以用于自動訂閱具有相同前綴的主題，此部分將在主題訂閱流程中詳細描述。“desc”是主題描述，值為字符串類型，任意UTF-8字符均可使用?！癮ddr”是該主題的內(nèi)部地址，是在發(fā)布者內(nèi)部的地址表示，不同的發(fā)布者可以有相同的內(nèi)部地址。最大值為65535，即每個發(fā)布者最多支持65535個主題?！皌ype”是主題消息數(shù)據(jù)類型，值為枚舉字符串，有效值如下：UINT8，INT8，UINT16，INT16，UINT32，INT32，UINT64，INT64，F(xiàn)loat，Double，bool：布爾類型。

string：字符串類型。“group”是主題分組，值為字符串數(shù)組。每個主題可以加入多個分組，當分組被訂閱時，分組所述的主題都被訂閱。group數(shù)組為空時表示根據(jù)ID自動分配分組，數(shù)組中每個元素表示一個分組。缺少該項設(shè)置時，默認值為[]。

“cacheNum”是緩存條數(shù)，值為整數(shù)，范圍0～1000。cacheNum的大小決定了代理(服務器)緩存該主題的消息條數(shù)。缺少該項設(shè)置時，默認值為100。

“setting”對象關(guān)于主題設(shè)置的配置。值為null表示該主題不允許被設(shè)置，即只讀主題。值為對象且包含“guardTime”和“needApproval”時，表示該主題允許被設(shè)置，即是可讀寫主題。

guardTime

保護時間，單位為秒。范圍：0～3600。最大保護時間不超過1小時。當同一個主題執(zhí)行了一個設(shè)置請求(SETREQ消息)后，在guardTime毫秒內(nèi)，不再執(zhí)行新的設(shè)置請求。guardTime等于0時，表示不需要保護時間，可以立即執(zhí)行新的設(shè)置請求。缺少該項設(shè)置時，默認值為0。

needApproval，需要審批，布爾值。true需要審批，即該主題收到“SETREQ”請求后，需要更高權(quán)限級別的訂閱者的審批同意后，才能被執(zhí)行。審批人需要在“SETREQ”中指定。false不需要審批，表示不需要其他訂閱者同意，可以直接被執(zhí)行。缺少該項設(shè)置時，默認值為false。

“retain”是配置保留標志，值為布爾類型。true表示該主題配置保留在代理(服務器)上，即使當前連接斷開后仍然保留主題配置。false表示不保留主題配置，即當連接斷開后，該主題配置被清空。缺少該項設(shè)置時，默認值為true。

“deleted”是“已刪除”標志。表示此主題已在代理服務器中刪除。該屬性僅用于代理向訂閱者通知(REGNOTICE)主題已被刪除時使用，在注冊主題(REGIST)時可以省略。通知(REGNOTICE)主題被刪除時，”ID”和”deleted”之外的屬性均可被省略。

如果在CONNECT時，設(shè)定了數(shù)據(jù)傳輸?shù)募用芩惴?，則將上述主題配置的json字符串加密使用配置的加密算法和密鑰(隨機密碼)進行加密后再填充。

REGACK，broker收到publisher的REGIST消息后，根據(jù)CONNECT消息設(shè)定的數(shù)據(jù)加密方式，解析出主題配置信息，并驗證配置信息的有效性。如果有效則在服務器中存儲該主題配置，存儲方式可以根據(jù)實際情況選擇，如使用配置文件、數(shù)據(jù)庫表等。例如，使用數(shù)據(jù)庫表TOPIC(ID,dest,publisherID,addr,Qos,type,group,cacheNum,setEnable,retain,deleted)來存儲主題配置，表中字段意義與REGIST中主題配置json對象屬性一致，不同的是增加了publisherID，已表明該主題配置屬于哪個publisher。

如果主題配置信息無效，則使用REGACK消息發(fā)送至publisher，告知其失敗原因。

REGACK消息格式如圖22所示。注冊結(jié)果的有效值如下：0：注冊成功，1：注冊失敗，原因是主題標識(ID)已存在，2：注冊失敗，原因是主題標識(ID)無效，3：注冊失敗，原因是Qos無效，4：注冊失敗，原因是type無效，5：注冊失敗，原因是group無效，6：注冊失敗，原因是cacheNum無效，7：注冊失敗，原因是setEnable無效，8：注冊失敗，原因是retain無效。

注冊失敗后，publisher應記錄失敗的主題配置信息及原因，以供維護人員查看。

REGCOMP，當所有需要注冊的主題注冊完成后，publisher向broker發(fā)送REGCOMP消息，表示主題注冊完成。消息格式如圖23所示。

REGNOTICE，主題配置通知有兩種情況。

其一，在有新的subscriber連接到broker之后，將已有的主題配置通知到新的subscriber。此時，將broker當前所有主題配置形成一個統(tǒng)一的json字符串通過REGNOTICE通知給新的subscriber。如果json字符串長度超出最大長度，則將字符串分割，通過多個消息發(fā)送，具體詳見消息格式。

其二，當broker收到了publisher的REGCOMP消息后，說明publisher的主題注冊已經(jīng)完成，這時broker開始向所有subscriber依次通知新注冊成功的主題配置。與上一種情況相同，主題配置將使用json字符串形式包裝到消息中，如果超出消息最大長度，則分為多個消息發(fā)送。消息格式如圖24所示。

其中，

結(jié)束標志：表示該消息是否為REGNOTICE的最后一個消息。如果REGNOTICE消息只需要一個，即主題配置json字符串在單個消息允許的最大長度(1400字節(jié))以內(nèi)，則結(jié)束標志位直接置為1。如果需要多個消息，則只在發(fā)送最后一個消息時，將結(jié)束標志置1，其它則置0。

重發(fā)標志：表示該消息是否為重發(fā)消息。每個REGNOTICE消息都需要REGNOTICEACK消息的確認，當在規(guī)定的超時時間內(nèi)(在CONNECT消息中設(shè)定的超時時間)沒有收到確認，broker可以進行重發(fā)REGNOTICE消息，每個消息最多允許重發(fā)3次，重發(fā)3次后，仍沒有收到REGNOTICEACK確認消息的，將斷開broker與subscriber的連接。

主題配置通知序列號：占用15bits，無符號數(shù)整數(shù)。

用于發(fā)送多個REGNOTICE消息時，表示消息的順序，以用于在broker接收到素有REGNOTICE消息后，將主題配置json字符串還原。

該序列號由broker維護，當收到subscriber的REGNOTICEACK確認消息，并且是對結(jié)束標志為1的REGNOTICE消息的確認時，broker將該序列號歸零，以備下次通知配置時使用。

主題配置信息：與REGIST消息中的主題配置信息格式類似。不同之處在于，REGIST消息中，主題配置是單個配置對象(這里指的是json對象，即一對{}中的內(nèi)容)。REGNOTICE中的主題配置信息則是由多個publisher的主題配置組成，所以頂層對象的每個屬性都是一個publisher的主題配置，其屬性名稱即publisher的ID(在broker服務器上注冊用戶時，分配的ClientID)或名稱(在broker服務器上注冊的用戶名)，其類型為json數(shù)組，每個publisher的配置數(shù)組中的每個數(shù)組元素都是一個主題配置對象(即REGIST消息中的主題配置信息)。

例如，由兩個publisher的配置數(shù)組組成的配置。需要注意的是，數(shù)組中最后一個對象后面不能有逗號”,”，具體請參考json規(guī)則，這里不再贅述。

關(guān)于加密。如果在CONNECT時設(shè)置了數(shù)據(jù)加密算法，并且主題配置信息將分為多個消息發(fā)送，則首先分割主題配置信息json字符串，在每個消息中分別加密。

REGNOTICEACK，主題配置通知確認。subscriber接收到每個REGNOTICE消息都需要使用REGNOTICEACK消息進行確認。確認時，結(jié)束標志、重發(fā)標志和主題配置通知序列號與所確認的REGNOTICE消息相同。當接收到“結(jié)束標志”為1的REGNOTICE消息后，subscriber將已收到的所有REGNOTICE消息中攜帶的主題配置信息片段，按照消息序列號的順序重新組合，并解析其中的主題配置信息，將主題配置信息進行存儲(例如：將主題配置信息直接保存到文件中，或者存到數(shù)據(jù)庫表中)，以備向broker訂閱消息時使用。

具體消息格式如圖25所示。

DELETE，刪除主題配置。當publisher不再提供某個或者某些主題的消息更新時，可以向broker發(fā)送主題刪除消息，表示希望從broker刪除相關(guān)的主題配置。具體消息格式如圖26所示。

其中，主題標識數(shù)組為希望刪除的主題標識的集合，集合中使用主題地址(主題地址是主題標識在publisher內(nèi)部的表示形式，具體詳見PUBLISH消息中的描述)。

DELACK，確認刪除主題配置。Broker向publisher確認主題主題刪除的結(jié)果，已刪除或刪除失敗。具體消息格式如圖27所示。

其中，刪除結(jié)果：0：刪除成功，1：刪除失敗。通過REGIST、REGACK、REGCOMP、REGNOTICE、REGNOTICEACK、DELETE和DELACK消息實現(xiàn)的主題配置流程可選流程。當系統(tǒng)的運行無需人工參與，并且在系統(tǒng)上線前已經(jīng)對主題標識的字符串形式和數(shù)字ID形式的映射以及主題的配置進行了約定，publisher、subscriber和broker都已經(jīng)對此完全已知，則該流程無需在系統(tǒng)中實現(xiàn)，只需要根據(jù)約定做好配置文件(通過工具生成，或者手工制作)，讓publisher、subscriber和broker都能夠自動讀到一致的配置信息即可。

在一個實施例中，還包括：所述發(fā)布終端與所述云端服務器之間按預設(shè)流程推送所述訂閱主題的消息。

在一個實施例中，所述云端服務器與所述訂閱終端之間按預設(shè)流程推送所述訂閱主題的消息。

在一個實施例中，所述云端服務器與所述訂閱終端之間按預設(shè)流程確定所述訂閱主題。

在一個實施例中，所述云端服務器與所述訂閱終端之間按預設(shè)流程設(shè)置所述訂閱主題。

本發(fā)明實施例中broker與subscriber之間的主題推送流程具體如下：

PUSH，PUSH消息用于broker向subscriber推送publisher發(fā)布的主題數(shù)據(jù)。PUSH消息與PUBLISH消息，除了消息類型不同，其余格式完全相同。具體格式不再贅述，詳細參見PUBLISH，注意需要將使用的消息類型由PUBLISH(19)改為PUSH(21)。

另外，其中的消息序列號，與PUBLISH中的內(nèi)容不同。PUSH中的序列號由broker為每個subscriber維護，即在broker中，應為每個subscriber都保留一個PUSH序列號，以用于保證在向每個subscriber推送主題數(shù)據(jù)過程中的順序。

PUSHACK，PUSHACK消息用于確認PUSH消息，作用與PUBACK類似。不同的是，PUSHACK是由subscriber發(fā)送至broker的消息。具體格式不再贅述，詳細參見PUBACK，注意需要將使用的消息類型由PUBACK(20)改為PUSHACK(22)。

本發(fā)明實施例中broker與subscriber之間的主題設(shè)置流程具體如下：

SETREQ，SETREQ消息用于subscriber向broker請求對某個主題進行設(shè)置操作，即用于請求改變主題的狀態(tài)、屬性，進而使得publisher執(zhí)行某些操作或動作。具體格式如圖28所示：

消息序列號，位置Byte2～Byte3，取值范圍0～65535，消息序列號由subscriber維護，每發(fā)送一個SETREQ消息，消息序列號增1，達到最大值后，重新從0開始。

加密消息，位置Byte4 bit 7。值為1時，表示該消息需要加密，加密范圍從Byte5至最后。值為0時，不加密。

審批模式，位置Byte4 bit4，值為1表示需要全部審批人同意才能執(zhí)行設(shè)置請求。值為0表示需要任意一個審批人同意即可執(zhí)行設(shè)置請求。

審批人數(shù)量，位置Byte4 bit 3～bit 0。值等于0時，不需要審批。值大于0時，需要對該設(shè)置請求進行審批的訂閱者數(shù)量。需要與被設(shè)置主題在REGIST中的配置保持一致。

發(fā)布者ClientID，位置Byte5～Byte8，32位無符號整數(shù)。發(fā)布者ClientID告訴broker，該消息設(shè)置的主題隸屬于哪個發(fā)布者。

審批人ClientID，位置Byte 9～Byte 9+4*A-1，A是審批人數(shù)量。每個審批人ClientID都是32位無符號整數(shù)。審批人是指需要對當前SETREQ消息中的設(shè)置請求進行審批的訂閱者，審批人可以有多個。

主題數(shù)據(jù)類型(格式)，位置Byte 9+(4*A)，表示該消息內(nèi)主題數(shù)據(jù)的數(shù)據(jù)類型或者格式，以便于broker或subscriber進行解析，詳細描述參見PUBLISH消息。

主題地址，位置Byte8～Byte9，取值范圍0～65535。該消息需要設(shè)置的主題的地址。與發(fā)布者ClientID一起保證了需要設(shè)置主題的唯一性。

設(shè)置數(shù)據(jù)，具體的長度和值根據(jù)所設(shè)置的主題地址確定，不同的主題類型占用的長度和格式不同，具體參考PUBLISH消息中相關(guān)的描述。

SETREQACK，SETREQACK消息用于確認SETREQ消息。具體消息格式圖29所示。

必須確認，每個SETREQ消息都需要使用SETREQACK進行確認回復，SETREQACK中的序列號與該消息確認的SETREQ消息中的序列號相同。

順序發(fā)送，消息序列號用于唯一的標識一個SETREQ消息，并保證消息的順序，必須等待收到broker的SETREQACK消息后，才可以發(fā)送下一個SETREQ消息。

重發(fā)，當在超時時間內(nèi)沒有收到SETREQACK消息的確認后，進行重發(fā)，最多重發(fā)3次。重發(fā)3次仍然無法收到回復，則認為連接斷開。

確認結(jié)果，0：請求提交成功，1：請求提交失敗，發(fā)布者不存在，2：請求提交失敗，主題地址不存在，3：請求提交失敗，主題只讀，不允許被設(shè)置，4：請求提交失敗，所有審批人均不存在，5：請求提交失敗，所有審批人均未訂閱該主題。

SETREQCHK，SETREQCHK消息用于broker向?qū)徟宿D(zhuǎn)發(fā)請求者的主題請求信息。如果SETREQ中的審批人數(shù)量為0，則不需要使用SETREQCHK向?qū)徟税l(fā)送審批請求。消息格式如圖30所示。

消息序列號，位置Byte2～Byte3，取值范圍0～65535，消息序列號由broker維護，每發(fā)送一個SETREQCHK消息，消息序列號增1，達到最大值后，重新從0開始。

加密消息，位置Byte4 bit 7。值為1時，表示該消息需要加密，加密范圍從Byte5至最后。值為0時，不加密。

審批模式，位置Byte4 bit4，值為1表示需要全部審批人同意才能執(zhí)行設(shè)置請求。值為0表示需要任意一個審批人同意即可執(zhí)行設(shè)置請求。

審批人數(shù)量，位置Byte4 bit 3～bit 0。值等于0時，不需要審批。值大于0時，需要對該設(shè)置請求進行審批的訂閱者數(shù)量。需要與被設(shè)置主題在REGIST中的配置保持一致。

請求者ClientID，位置Byte5～Byte8，32位無符號整數(shù)。請求者ClientID告訴審批人，該主題設(shè)置請求是由誰發(fā)出的。

發(fā)布者ClientID，位置Byte 9～Byte 12，32位無符號整數(shù)。發(fā)布者ClientID告訴審批人，該主題設(shè)置請求設(shè)置的是哪個發(fā)布者的主題。

主題數(shù)據(jù)類型(格式)，位置Byte 13，表示該消息內(nèi)主題數(shù)據(jù)的數(shù)據(jù)類型或者格式，以便于broker或subscriber進行解析，詳細描述參見PUBLISH消息。

主題地址，位置Byte8～Byte9，取值范圍0～65535。該消息需要設(shè)置的主題的地址。與發(fā)布者ClientID一起保證了需要設(shè)置主題的唯一性。

設(shè)置數(shù)據(jù)，具體的長度和值根據(jù)所設(shè)置的主題地址確定，不同的主題類型占用的長度和格式不同，具體參考PUBLISH消息中相關(guān)的描述。

SETREQCHKACK，SETREQCHKACK消息用于確認SETREQCHK消息，返回審批結(jié)果。消息格式如圖31所示。

消息序列號，復制SETREQCHK的消息序列號，對哪個消息進行確認，消息序列號就與之相同。

審批結(jié)果，255：通過，即同意執(zhí)行該請求，0：拒絕，即不同意執(zhí)行該請求。

SET，SET消息用于broker向publisher轉(zhuǎn)發(fā)subscriber的SETREQ消息。當SETREQ消息被審批人審核通過后，broker將該主題設(shè)置請求使用SET消息轉(zhuǎn)發(fā)至publisher。具體消息格式如圖32所示。消息中的屬性與SETREQ、SETREQCHK中相同，這里不再贅述。

SETACK，SETACK消息用于確認SET消息。具體格式如圖33所示。

消息序列號，復制SET的消息序列號，對哪個消息進行確認，消息序列號就與之相同。審批結(jié)果，0：設(shè)置成功，1～255：設(shè)置失敗，具體原因由應用中具體來約定。

SETCOMP，SETCOMP消息用于結(jié)束一個主題設(shè)置請求。一個完成的主題設(shè)置過程，從SETREQ開始，首先發(fā)出請求，再由SETREQCHK完成審批，審批后使用SET進行主題設(shè)置。每個步驟都需要對應的ACK消息進行確認。當最終SETACK返回broker后，無論設(shè)置成功還是失敗，都需要把設(shè)置結(jié)果返回給請求者。具體消息格式如圖34所示。大部分消息屬性與其它主題設(shè)置消息格式中的意義一致，再次不再贅述。

不同的部分有：擴展區(qū)，位置Byte4 bit6。1表示使用擴展區(qū)，0表示不使用擴展區(qū)。設(shè)置結(jié)果，復制SETACK消息中的設(shè)置結(jié)果。擴展區(qū)，用于一些自定義主題數(shù)據(jù)類型(格式)。如果預定義的設(shè)置結(jié)果無法滿足要求，可以事先約定使用擴展區(qū)來描述設(shè)置結(jié)果。

本發(fā)明實施例的通訊方法，發(fā)布終端與訂閱終端分別與云端服務器建立通信連接；訂閱終端通過云端服務器向發(fā)布終端訂閱主題；發(fā)布終端通過所述云端服務器向訂閱終端推送訂閱主題的消息。

以上已經(jīng)描述了本發(fā)明的各實施例，上述說明是示例性的，并非窮盡性的，并且也不限于所披露的各實施例。在不偏離所說明的各實施例的范圍和精神的情況下，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說許多修改和變更都是顯而易見的。本文中所用術(shù)語的選擇，旨在最好地解釋各實施例的原理、實際應用或?qū)κ袌鲋械募夹g(shù)的改進，或者使本技術(shù)領(lǐng)域的其它普通技術(shù)人員能理解本文披露的各實施例。

本領(lǐng)域技術(shù)人員在考慮說明書及實踐這里公開的公開后，將容易想到本公開的其它實施方案。本申請旨在涵蓋本公開的任何變型、用途或者適應性變化，這些變型、用途或者適應性變化遵循本公開的一般性原理并包括本公開未公開的本技術(shù)領(lǐng)域中的公知常識或慣用技術(shù)手段。