林 滸, 張家銘,2, 楊海波

?

基于MQTT協(xié)議的即時消息業(yè)務(wù)設(shè)計(jì)與實(shí)現(xiàn)①

林 滸1, 張家銘1,2, 楊海波1

1(中國科學(xué)院沈陽計(jì)算技術(shù)研究所, 沈陽 110168)2(中國科學(xué)院大學(xué), 北京 100049)

近年來, 寬帶接入技術(shù)正以十分驚人的速度發(fā)展. 與此同時, 移動互聯(lián)網(wǎng)技術(shù)也日益成熟, 即時消息業(yè)務(wù)已成為移動互聯(lián)時代的應(yīng)用熱點(diǎn). 在互聯(lián)網(wǎng)中XMPP和SIMPLE被廣泛使用, 但其并不能很好的適用于移動互聯(lián)網(wǎng). 采用發(fā)布/訂閱模型的MQTT協(xié)議是一種輕量級的消息傳輸協(xié)議, 具有低功耗、節(jié)省流量和可擴(kuò)展性強(qiáng)的優(yōu)點(diǎn). 本文首先分析了XMPP和SIMPLE協(xié)議的不足之處, 研究了MQTT協(xié)議的消息格式以及協(xié)議的使用方式, 之后對即時消息業(yè)務(wù)進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 并在功能和性能上進(jìn)行了相關(guān)的測試和分析.

即時消息; 發(fā)布/訂閱; MQTT; 移動互聯(lián)網(wǎng)

隨著移動互聯(lián)網(wǎng)和移動智能終端的普及, 移動智能終端已經(jīng)成為網(wǎng)民接入互聯(lián)網(wǎng)的重要途徑, 即時通信迎來了前所未有的發(fā)展契機(jī). 與此同時, 由于用戶通常會隨身攜帶手機(jī), 移動消息應(yīng)用在手機(jī)客戶端上的重要性也逐漸凸顯, 移動消息中的即時消息業(yè)務(wù)成為一個炙手可熱的研究領(lǐng)域. 目前, 即時消息除了通過采用私有協(xié)議(如QQ、微信等)實(shí)現(xiàn)外, 還主要通過SIMPLE和XMPP兩大類協(xié)議. 然而, 由于移動智能終端對流量有限制, 對網(wǎng)絡(luò)的帶寬以及終端的功耗等有特殊的要求, 因此即時消息業(yè)務(wù)對即時通信協(xié)議有更高的要求. 然而上述兩種協(xié)議均不能較好的滿足移動消息的應(yīng)用場景. 本文通過對解決當(dāng)前即時消息業(yè)務(wù)的相關(guān)協(xié)議進(jìn)行研究和分析, 提出了更適合移動互聯(lián)網(wǎng)的基于MQTT協(xié)議的即時消息業(yè)務(wù)解決方案.

本文主要分為四部分, 第一部分對SIMPLE和XMPP協(xié)議進(jìn)行了相關(guān)的研究, 并分析了在移動互聯(lián)網(wǎng)下兩協(xié)議的不足之處. 第二部分提出了基于發(fā)布/訂閱的輕量級的MQTT協(xié)議, 對其進(jìn)行了簡單地分析, 并闡述了它的消息格式. 第三部分對即時消息業(yè)務(wù)的話題、payload以及消息路由進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 第四部分, 對本文設(shè)計(jì)的即時消息系統(tǒng)進(jìn)行了相關(guān)的測試和分析.

1 相關(guān)協(xié)議分析

1.1 SIMPLE協(xié)議

SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)協(xié)議簇是由IETF SIMPLE工作組制定的, 主要是擴(kuò)展SIP協(xié)議, 以使其支持IM服務(wù)[3]. SIMPLE工作組為SIMPLE協(xié)議的規(guī)范制定做了大量的工作, 并且發(fā)布了一系列RFC文檔. SIMPLE提出session模式和page模式[3]. session模式中, 即時消息被作為一種類似于音視頻的媒體, 通過SIP信令進(jìn)行交互, 即時消息協(xié)商后建立一個會話, 通過建立的會話進(jìn)行消息媒體的交互. page模式中, 通過SIP請求包裹即時消息的內(nèi)容發(fā)送消息的方式. 通過對SIP協(xié)議的擴(kuò)展, SIMPLE協(xié)議有了很大的改進(jìn). 在完成了SIP信令協(xié)商之后, 一般的多媒體會話需要使用一些其他協(xié)議來建立用戶代理之間的會話通道以此完成會話數(shù)據(jù)的交互. 基于SIMPLE協(xié)議的即時消息交互不需要建立會話通道, 消息通過SIMPLE協(xié)議的消息命令直接發(fā)送, 每個消息都由一個單獨(dú)的消息命令來傳播, 彼此獨(dú)立.

1.2 XMPP協(xié)議

XMPP由IETF于2004年完成了標(biāo)準(zhǔn)化工作, 符合RFC2778 和 RFC2779 規(guī)范. XMPP源于Jabber 協(xié)議, 它是以XML為基礎(chǔ)開放式的即時通信協(xié)議[4]. XMPP協(xié)議繼承了XML的靈活性、擴(kuò)展性, 它以TCP/IP傳輸為基礎(chǔ), 定義了客戶端、服務(wù)器和網(wǎng)關(guān)三種角色. 服務(wù)器不僅要承擔(dān)客戶端信息記錄, 還要負(fù)責(zé)連接管理和信息的路由功能. 網(wǎng)關(guān)負(fù)責(zé)各異構(gòu)即時通迅系統(tǒng)之間的通信.

1.3 XMPP、SIMPLE協(xié)議在移動互聯(lián)網(wǎng)中的不足

XMPP和SIMPLE協(xié)議均是基于字符文本進(jìn)行傳輸?shù)耐ㄐ艆f(xié)議, 字符文本協(xié)議通信的效率較低, 為了確保通信的安全, 二者采用了TLS等加密傳輸機(jī)制計(jì)算量較大, 功耗較高.

XMPP和SIMPLE協(xié)議是基于相對可靠的網(wǎng)絡(luò)上的應(yīng)用層協(xié)議, 在底層網(wǎng)絡(luò)不穩(wěn)定的情況下, 容忍機(jī)制不夠健全, 應(yīng)用在移動互聯(lián)網(wǎng)即時通信時, 網(wǎng)絡(luò)的不穩(wěn)定現(xiàn)象經(jīng)常出現(xiàn), 恢復(fù)網(wǎng)絡(luò)連接需要較多交互數(shù)據(jù)包, 浪費(fèi)用戶流量, 降低了用戶體驗(yàn).

XMPP和SIMPLE協(xié)議是基于消息體尋址的協(xié)議, 消息體中包含了消息的發(fā)送者、消息的接收者以及消息路由用的會話標(biāo)示等頭域, 這使得消息體過大, 極大的降低了帶寬的利用率.

2 基于發(fā)布/訂閱的MQTT協(xié)議

2.1發(fā)布/訂閱模型概述

發(fā)布/訂閱模型是一種消息傳播模式, 消息的發(fā)布者不直接將消息發(fā)送到消息的訂閱者, 而是根據(jù)某種特征將發(fā)布的消息進(jìn)行分類, 在這個過程中消息的發(fā)布者不需要關(guān)注消息的訂閱者. 同樣, 消息的訂閱者通過訂閱某個感興趣的消息, 不需要關(guān)注消息的發(fā)布者. 在這種機(jī)制下, 消息的若干個發(fā)布者與若干個訂閱者之間不需要直接進(jìn)行通信, 而是通過建立消息代理作為中介互相通信. 通過這種發(fā)布者與訂閱者之間的解耦合關(guān)系, 這種模式提供了更好的網(wǎng)絡(luò)擴(kuò)展性和更動態(tài)的網(wǎng)絡(luò)拓?fù)?

發(fā)布/訂閱模型中, 消息的訂閱者往往只接受消息發(fā)布者所發(fā)布消息的某個子集. 消息的過濾指的是對接受和處理的消息進(jìn)行選擇的過程. 通常有兩種過濾形式: 分別是基于主題和基于內(nèi)容的過濾, MQTT協(xié)議采用基于主題的發(fā)布／訂閱模式.

在基于主題(Topic)的發(fā)布／訂閱模型中, 消息以特定的主題名標(biāo)識被發(fā)布者發(fā)布至消息代理服務(wù)器上. 基于主題的發(fā)布／訂閱模式中, 訂閱同一主題的訂閱者將會收到相同的消息, 消息的訂閱者可以訂閱多個主題. 發(fā)布者負(fù)責(zé)定義訂閱者可以訂閱的消息類別. 消息代理負(fù)責(zé)維護(hù)消息隊(duì)列, 執(zhí)行消息的存儲轉(zhuǎn)發(fā)功能.

2.2MQTT協(xié)議簡介

MQTT(Message Queuing Telemetry Transport, 消息隊(duì)列遙測傳輸)是由IBM公司開發(fā)的即時通訊協(xié)議, 它是一個基于發(fā)布/訂閱模型、輕量級的消息傳輸協(xié)議[1]. 具有開放、易用、精簡等特點(diǎn). MQTT協(xié)議是為那些計(jì)算能力有限, 且需要工作在低帶寬、不可靠的網(wǎng)絡(luò)通訊而設(shè)計(jì)的協(xié)議[2].

MQTT主要有有以下幾個特性:

①使用基于主題的發(fā)布/訂閱消息模式, 提供一對多的消息發(fā)布, 屏蔽了應(yīng)用程序之間的耦合性;

② MQTT協(xié)議有三種級別的消息發(fā)布服務(wù)質(zhì)量[7]: “至多一次”, 發(fā)生的消息會丟失或重復(fù), 這一級別可用于一些傳感器傳輸數(shù)據(jù), 消息丟失一次對系統(tǒng)不會有嚴(yán)重影響, 因?yàn)樵诓痪弥笙到y(tǒng)還會進(jìn)行消息的第二次發(fā)送; “至少一次”, 該情況下能確保傳輸消息的準(zhǔn)確到達(dá), 但有可能會產(chǎn)生消息重復(fù)的傳輸?shù)默F(xiàn)象; “只有一次”, 確保消息只到達(dá)一次. 這一級別可用于一些計(jì)費(fèi)系統(tǒng), 使用該級別表明進(jìn)行傳輸?shù)南?nèi)容特別重要;

③ MQTT協(xié)議采用二進(jìn)制的形式表達(dá), 固定長度的頭部只有2 字節(jié), 協(xié)議交換達(dá)到最小化, 極大的降低了網(wǎng)絡(luò)帶寬的開銷.

2.3 MQTT協(xié)議的消息格式

MQTT消息體由固定報頭、可變報頭以及有效載荷三部分組成[6], 固定報頭是每個消息體都必須要包含的部分, 固定報頭部分的長度為2字節(jié). 消息格式如表1所示.

表1 MQTT協(xié)議的消息格式

消息體的固定報頭有2個字節(jié)長, 具體的格式如表2所示.

表2 固定頭域

固定報頭的高四位是消息的類型, 最多可以支持16種的消息類型. 目前, MQTT協(xié)議已經(jīng)定義了14種消息類型[5].

Dup Flag用于標(biāo)識是否第一次發(fā)送該消息. 當(dāng)Dup Flag為0時表示第一次發(fā)送該消息. 雖然Dup Flag為1表示該消息是重傳消息, 但是不能保證用戶之前收到過該消息.

QOS表明發(fā)布消息的交付質(zhì)量等級, 可選值為 0、1、2.

Retain標(biāo)識僅在發(fā)布消息中使用. 對于消息的發(fā)布者, 當(dāng)客戶端發(fā)送消息時, 如果該標(biāo)識設(shè)置為1, 則消息發(fā)送到訂閱該主題的所有訂閱者之后, 代理服務(wù)器仍然保存該消息. 對于消息的訂閱者, 當(dāng)一個主題有了新的訂閱用戶, 最后被保留的消息主題將被設(shè)置保留字段, 然后發(fā)送到新的消息訂閱者. 當(dāng)主題不存在相關(guān)的保留信息時, 則不發(fā)送.

Remaining Length是剩余長度, 包含Variable header、payload的長度, 默認(rèn)Remaining Length為1字節(jié), 最多支持?jǐn)U展4字節(jié), 因此一條MQTT可攜帶的消息最高是256MB.

3 即時消息業(yè)務(wù)的設(shè)計(jì)與實(shí)現(xiàn)

即時通信在實(shí)際的應(yīng)用場景中, 客戶端與服務(wù)器的具體交互流程如圖1所示.

圖1 IM交互流程簡圖

客戶端A、B會分別訂閱/IM/A和/IM/B主題. 客戶端A和B會向?qū)Ψ降闹黝}上發(fā)布消息, 之后會通過代理服務(wù)器進(jìn)行轉(zhuǎn)發(fā)[8]. MQTT協(xié)議中消息不攜帶路由信息和消息的內(nèi)容類型. 因此, 我們需要對payload中攜帶的消息格式根據(jù)業(yè)務(wù)的需求進(jìn)行明確的規(guī)范, 使客戶端能夠從payload中獲取消息的類別、發(fā)送者的信息以及載荷域的內(nèi)容格式等相關(guān)信息. 由此可見, 使用MQTT協(xié)議實(shí)現(xiàn)即時通信的應(yīng)用關(guān)鍵點(diǎn)在于話題的設(shè)計(jì), 消息的發(fā)布、訂閱流程以及消息路由. 下面將對即時消息的上述問題進(jìn)行設(shè)計(jì)和實(shí)現(xiàn).

3.1話題格式設(shè)計(jì)

話題格式為:/namespace/im/u/uid.

在MQTT協(xié)議中話題至少需要一個字符的長度, 話題對大小寫敏感的. 通過“/”用來區(qū)分相應(yīng)的話題層級. 規(guī)定, 以“/”開頭的話題為普通話題, 以”$”開頭的話題為系統(tǒng)話題[9]. namespace為用戶所在的組織名稱, 可以為企業(yè)或?qū)W校的標(biāo)識名. 中間部分用來表示話題類別, im表示即時消息話題. 最后的uid代表用戶的唯一標(biāo)示符.

3.2Payload設(shè)計(jì)

對于一條即時消息, 消息的接收方在接收到消息之后, 需要知道該消息的發(fā)送時間、消息的類型、消息內(nèi)容的類型、消息內(nèi)容以及該消息的發(fā)送者等信息. 因此該消息的payload的設(shè)計(jì)如表3所示.

表3 即時消息的payload設(shè)計(jì)

Sender: 發(fā)送者消息, 變長, 可為空.

TS: 發(fā)送時的時間戳, 4個字節(jié), 不可為空.

在Type中包括發(fā)送消息的類型(高4位)以及消息內(nèi)容的類型(低4位). 消息的類型, 現(xiàn)階段只用三種表示, 具體是0表示是點(diǎn)對點(diǎn)的即時消息, 1表示PC端到手機(jī)端的即時消息, 2表示的是手機(jī)到PC端的即時消息, 其余13種保留用于今后擴(kuò)展; 消息內(nèi)容的類型, 可表示16種媒體類型, 具體的示例定義如下: 0表示普通文本信息, 1表示圖片消息, 2表示音頻文件, 3表示視頻文件, 4表示PDF文檔, 5表示W(wǎng)ord文檔等. 這里需要注意的是, 在Payload中一次只攜帶一種媒體文件. 采用離線文件傳輸?shù)姆绞? 不在payload中進(jìn)行文件傳輸, 文件上傳結(jié)束后將對應(yīng)的下載鏈接地址在payload進(jìn)行傳輸. Type的詳細(xì)設(shè)計(jì)如表4.

表4 Type詳細(xì)設(shè)計(jì)

Con-len: 4 個字節(jié), 表示后面攜帶的媒體內(nèi)容的長度.

Content: 是將消息內(nèi)容按照json格式組織的字符串. 該字符串默認(rèn)情況下按照json數(shù)組的形式來組織的, 這樣就允許在消息中支持多種媒體并存, 可以構(gòu)建較為復(fù)雜的應(yīng)用時滿足對應(yīng)的需求. 對于每種媒體, 按照媒體類型不同, 提供不同的描述字段. 具體實(shí)現(xiàn)如下:

"con":[

{"ty": 0, // 0:文本,1:圖片, 2:音頻, 3:視頻, 4:文檔文件, 5:文件, 6:地圖, 14 :富媒體

" co": "url 或者文本",//媒體的內(nèi)容

**Optional**

"fn": {

“name”: “text.txt”,

“size”: “500”

}

} // 可以并列多個消息內(nèi)容

]

在上述定義中,

ty: 是媒體的類型, 目前需要考慮支持的媒體類型包括: 文本, 圖片, 音頻, 視頻, 文檔, 文件, 地圖位置, html代碼, 以及其他富媒體, 如通知、公告、輕應(yīng)用數(shù)據(jù)等.

co: 是媒體的內(nèi)容.

fn: 如果媒體涉及到文件或者文檔名字, 這里給出的是文件.

3.3 預(yù)訂閱設(shè)計(jì)和實(shí)現(xiàn)

IM是通過話題來組織的, 而話題的訂閱一般由客戶端完成. 當(dāng)所需訂閱的話題過多時, 由于客戶端訂閱數(shù)據(jù)量龐大, 必定給網(wǎng)絡(luò)帶來巨大壓力. 其次, 對于移動設(shè)備而言, 因數(shù)據(jù)流量有限, 勢必將造成不必要的浪費(fèi). 因此, 為了減輕移動客戶端壓力, 提高用戶體驗(yàn), 本文采用預(yù)訂閱設(shè)計(jì)方案, 即在服務(wù)器端構(gòu)造一個預(yù)訂閱的客戶端. 流程如圖2所示.

圖2 預(yù)訂閱序列圖

預(yù)訂閱模塊幫助用戶完成訂閱話題工作的具體流程:

1) 當(dāng)服務(wù)器檢測到客戶端是首次連接時, 就會將uid及其他相關(guān)信息推送到服務(wù)器中的某一話題.

2) 預(yù)訂閱模塊接收到服務(wù)器發(fā)送的消息后, 解析此消息, 獲得新連接用戶的uid及該用戶的預(yù)訂閱話題列表. 根據(jù)訂閱列表, 預(yù)訂閱模塊向代理服務(wù)器進(jìn)行訂閱請求.

3) 通過代理服務(wù)器的接口實(shí)現(xiàn)預(yù)訂閱模塊中話題的預(yù)訂閱和取消預(yù)訂閱. 完成訂閱后, 代理服務(wù)器向預(yù)訂閱模塊返回確認(rèn)消息.

3.4 消息路由設(shè)計(jì)實(shí)現(xiàn)

本文要求實(shí)現(xiàn)多終端IM消息同步. 對于接收方而言, 由于同時訂閱了自己的IM topic, 所以收到消息后可以實(shí)現(xiàn)各終端間的同步. 但對于發(fā)送方而言, 由于在消息發(fā)送時各終端沒有聯(lián)系, 導(dǎo)致發(fā)送方的各終端間無法同步[10]. 為此, 本文提出了一套通過在代理服務(wù)器上增加消息路由機(jī)制, 實(shí)現(xiàn)的基于消息路由規(guī)則的多終端消息同步方法.

發(fā)送到一個話題上的消息需要根據(jù)消息路由規(guī)則, 判斷是否同時復(fù)制到其他話題上. 該規(guī)則采用話題的模糊匹配, 對于匹配成功的消息, 將其轉(zhuǎn)發(fā)至特定話題上. 其中一條消息路由規(guī)則的基本組成部分為三部分, 源地址(src Topic)、消息路由動作(action)、目的地址(dest Topic). 消息路由的詳細(xì)過程如圖3所示.

圖3 消息路由示例

具體過程說明如下:

① Alice的PC端向Jim的IM topic上發(fā)送一條消息

② Broker收到消息后, 經(jīng)過路有規(guī)則查詢, 判定該消息是否有匹配的路由規(guī)則, 如果存在則繼續(xù)進(jìn)行, 否則忽略③和⑤

③ 根據(jù)規(guī)則中的消息路由動作進(jìn)行消息路由, 找到路由轉(zhuǎn)發(fā)的目的topic, 圖中為Alice的IM topic.

④ 把IM消息Pub給Jim

⑤ Alice PC端發(fā)送的消息在其他終端得到接收, 并呈現(xiàn)

⑥ 消息分發(fā)到Jim的所有終端

4 即時消息業(yè)務(wù)的測試

4.1功能測試

表5 測試環(huán)境參數(shù)

本文考慮到平臺間兼容性問題, 在該功能測試部分采用了以下環(huán)境: 1臺Android手機(jī), 1臺iphone5s手機(jī), 1臺MQTT服務(wù)器(圖4所示), 20Mbps網(wǎng)絡(luò)帶寬.

圖4 消息時序圖

IOS用戶和Android用戶之間通過MQTT服務(wù)器, 分別發(fā)送文字、語音、圖片、視頻等不同類型的媒體消息, 消息發(fā)送流程如圖4所示, 呈現(xiàn)效果如圖5所示.

圖5 IM效果圖

測試結(jié)果表明, 各種類型媒體消息發(fā)送均能即時顯示.

4.2 IM流量測試

為了測試MQTT在移動互聯(lián)網(wǎng)中的性能優(yōu)勢, 筆者在測試過程中分別對SIMPLE、XMPP、MQTT三種協(xié)議進(jìn)行了封裝, 并使用wireshark進(jìn)行了抓包, 對同網(wǎng)絡(luò)環(huán)境下三種協(xié)議所消耗的網(wǎng)絡(luò)流量進(jìn)行了對比, 結(jié)果如圖6所示.

圖6 三種協(xié)議消耗流量對比圖

從上圖可以看出, 隨著發(fā)送消息文本數(shù)據(jù)包(橫坐標(biāo))的增加, 三種協(xié)議消耗的流量(縱坐標(biāo))均在不停地增加. 其中, MQTT協(xié)議的增幅最小, XMPP協(xié)議次之, 但增幅也不大, SIMPLE協(xié)議增幅最大. 由以上試驗(yàn)數(shù)據(jù)可以看出, 在流量消耗這方面MQTT協(xié)議的性能最好.

4.3服務(wù)器性能測試

最后, 對服務(wù)器負(fù)載能力進(jìn)行測試. 在客戶端模擬大規(guī)模用戶對服務(wù)器發(fā)起連接請求, 分別模擬10000到100000個連接請求, 所有請求的連接建立完成后, 分別進(jìn)行不同數(shù)目的消息推送, 測試所用的時間以及服務(wù)器CPU的占用率, 測試結(jié)果如表6所示.

表6 服務(wù)器負(fù)載性能測試

由表中數(shù)據(jù)可以看出, 本文設(shè)計(jì)的即時消息業(yè)務(wù)基本滿足了在移動互聯(lián)領(lǐng)域上的需求, 且服務(wù)器的負(fù)載也在可以接受的范圍內(nèi).

5 結(jié)語

即時消息業(yè)務(wù)已經(jīng)發(fā)展成為人們?nèi)粘贤ǖ闹匾?方式之一, 現(xiàn)有的即時通信協(xié)議不能很好地滿足移動互聯(lián)網(wǎng)環(huán)境下的網(wǎng)絡(luò)不穩(wěn)定、流量花費(fèi)高以及移動設(shè)備的低功耗等特點(diǎn). 采用基于發(fā)布/訂閱模型的輕量級消息傳輸?shù)腗QTT協(xié)議, 具有低功耗和移動互聯(lián)網(wǎng)帶寬利用率高的特點(diǎn). 本文在分析了相關(guān)私有協(xié)議的基礎(chǔ)上闡釋了MQTT協(xié)議在移動互聯(lián)網(wǎng)即時消息業(yè)務(wù)中的優(yōu)勢, 研究分析了MQTT協(xié)議的消息格式, 并對即時消息的話題格式、預(yù)訂閱以及消息路由進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 最后對實(shí)現(xiàn)的即時消息業(yè)務(wù)進(jìn)行了相關(guān)的測試和分析.

1 Banks A, Gupta R. OASIS Standard MQTT Version 3.1.1. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. [2014-10-29].

2 Tang K, Wang Y, Liu H, et al. Design and implementation of push notification system based on the MQTT protocol. Proc. International Conference on Informationence& Computer Applications. 2013. 92. 116–119.

3 Day M, Rosenberg J, Sugano H. A model for presence and instant messaging. IETF, 2000, 2: RFC2778.

4 Extensible Messaging and Presence Protocol http://xmpp.org/.

5 IBM. MQTT Telemetry Transport. http://msqq.org. [2013-06-05].

6 IBM, Eurotech. MQTT3.1Protocol Specification. http//public. dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3rl.html. [2010-08-24].

7 Lee S, Kim H, Hong D, Ju H. Correlation analysis of MQTT loss and delay according to Qos level. Information Networking (ICOIN). Bangkok. 2013.

8 馬躍,孫翱,賈軍營,孫建偉,于碧輝,楊雪華.MQTT協(xié)議在移動互聯(lián)網(wǎng)即時通信中的應(yīng)用.計(jì)算機(jī)系統(tǒng)應(yīng)用,2016,25(3): 170–176.

9 楊海波,王默涵,賈正鋒,卜立平.面向移動互聯(lián)網(wǎng)的Presence/IM機(jī)制研究.小型微型計(jì)算機(jī)系統(tǒng),2015,36(11). 2549–2553.

10 任亨.基于MQTT協(xié)議的消息推送服務(wù)器.計(jì)算機(jī)系統(tǒng)應(yīng)用,2014,23(3):77–82.

Design and Implementation of Instant Messaging Business Based on the MQTT Protocol

LIN Hu1, ZHANG Jia-Ming1,2, YANG Hai-Bo1

1(Shenyang Institute of Computing Technology, Chinese Academy of Sciences, Shenyang 110168, China)2(University of Chinese Academy of Sciences, Beijing 100049, China)

In recent years, broadband access is developing with astonishing speed. At the same time, the mobile Internet technology is also increasingly mature, instant messaging business have become a hot point of the era of mobile Internet applications. XMPP and SIMPLE are widely used in the Internet, but they are not suited to the mobile Internet. The MQTT is a publish/subscribe model based and lightweight messaging protocol, which has the advantages of reducing power consumption, decreasing flow and has strong flexibility. Firstly, this article analyzes the shortcomings of XMPP and SIMPLE protocol. Secondly, it introduces the message format and the usage of the MQTT protocol. After the design and implementation of the instant messaging business, the related testing and analysis are carried on the function and performance.

instant messaging; Pub/Sub; MQTT; mobile Internet

教育部-中國移動科研基金(2015)(MCM20150103)

2016-06-30;

2016-08-18

[10.15888/j.cnki.csa.005678]