基于消息隊列遙測傳輸?shù)耐扑拖到y(tǒng)

姜 妮，張 宇，趙志軍

(1．中國科學(xué)院聲學(xué)研究所高性能網(wǎng)絡(luò)實驗室，北京100190;2．中國科學(xué)院大學(xué)，北京100049)

1 概述

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展和移動終端的普及，人們希望能夠隨時隨地方便地獲取信息和服務(wù)。用戶獲取信息的途徑主要有拉取(Pull)和推送(Push)2種，相比于Pull不斷輪詢查看是否有新數(shù)據(jù)，需要付出大量的網(wǎng)絡(luò)流量和系統(tǒng)資源，Push由服務(wù)器主動將不定時產(chǎn)生的新消息推送給用戶，更加及時、高效、省流量、省資源。考慮到移動終端內(nèi)存有限、CPU計算能力弱、電池容量小、網(wǎng)絡(luò)流量資費昂貴等多方面因素，移動終端需要更加輕量、優(yōu)化、智能的推送技術(shù)［1］。

雖然目前的消息推送方案很多，但均存在大大小小的問題，比如服務(wù)受限、需要收費、安全漏洞、個性化智能推送不足等。其中，安全漏洞和個性化智能推送不足的問題較為明顯。安全問題體現(xiàn)在:有些系統(tǒng)任何人知道消息服務(wù)器IP和端口就可以連接運行，進(jìn)而攔截消息，惡意攻擊篡改;有些系統(tǒng)雖然加入了用戶名、密碼等身份認(rèn)證，但這些信息很容易被攻克，無法有效保證消息不被篡改。對于分布式應(yīng)用來說，發(fā)布或者訂閱的消息是否能夠安全及時地到達(dá)，并且在傳輸過程中使消息不丟失、不重復(fù)，保證消息的完整性和可靠性，對通信雙方都具有非常重要的作用［2-3］。個性化智能推送不足體現(xiàn)在:系統(tǒng)不會根據(jù)具體的性能要求和用戶需求的不同而采取合適的處理方法。例如無法根據(jù)消息的類型，用戶訂閱情況，傳輸?shù)目煽啃?、及時性和高效性等要求的不同［4］，來智能選擇不同的通信模式，如點對點、發(fā)布/訂閱;無法根據(jù)不同用戶的個性化需求智能選擇不同的發(fā)送方式，如軟件、郵箱等。

本文提出一種安全智能的基于消息隊列遙測傳輸(Message Queuing Telemetry Transport，MQTT)的消息推送系統(tǒng)。MQTT由IBM開發(fā)，是一種開放、精簡、輕量級和容易實現(xiàn)的協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。IBM和St．Jude醫(yī)療中心通過MQTT開發(fā)了一套Merlin系統(tǒng)，用于遠(yuǎn)程醫(yī)療項目，F(xiàn)acebook發(fā)布的IOS應(yīng)用，采用MQTT更新通知、消息和書簽等。此外，國內(nèi)很多企業(yè)，諸如 Sohu，Cmstop均有使用MQTT作為Android手機(jī)客戶端與服務(wù)器端推送消息的協(xié)議。本文系統(tǒng)采用MQTT消息傳輸協(xié)議，該協(xié)議采用小型傳輸，耗電量小，大幅降低網(wǎng)絡(luò)流量，特別適合代價昂貴、計算和處理能力受限的移動終端上的應(yīng)用［5-8］;安全方面加入安全認(rèn)證機(jī)制，可以有效保證系統(tǒng)安全;個性化智能推送方面加入多樣化智能推送，滿足用戶的個性化需求和消息傳遞性能要求。

2 現(xiàn)有推送方案

2．1 谷歌Android云通訊

谷歌Android云通訊Google Cloud Messaging(GCM)for Android)［9］是 Google 為 Android 提供的推送服務(wù)，第三方應(yīng)用服務(wù)器可利用該服務(wù)向自己的Android客戶端推送消息?？蛻舳耸紫葘⑹褂肎CM功能的賬戶和程序名稱發(fā)送給GCM服務(wù)器來獲取注冊ID，并把注冊ID告訴自己的服務(wù)器，應(yīng)用服務(wù)器通過訪問Google相關(guān)網(wǎng)站獲取Auth Token，并通過該Auth Token進(jìn)行推送功能［10-11］。

但經(jīng)過調(diào)研發(fā)現(xiàn)，這個服務(wù)存在很大的問題，推送服務(wù)受到版本限制(必須大于2．2版本)，該服務(wù)在國內(nèi)不夠穩(wěn)定，經(jīng)常不可用，需要用戶綁定Google賬號，受限于Google。

2．2 蘋果推送通知服務(wù)

蘋果推送通知服務(wù)(Apple Push Notification Service，APNS)是蘋果公司在2009年發(fā)布 IOS 3．0時加入的新功能，該服務(wù)可以讓蘋果移動終端與其推送服務(wù)器建立一個認(rèn)證，并保持一個IP的長連接［11］。蘋果服務(wù)器接收來自第三方的應(yīng)用服務(wù)器的消息，并將消息推送到用戶的終端上，即使用戶的程序處于關(guān)閉狀態(tài)，蘋果終端也可以用 Apple Notification的方式(程序圖標(biāo)、信息彈窗、聲音提示等)提示用戶［11］，與GCM類似，服務(wù)同樣受到限制。

2．3 黑莓郵件推送

黑莓Push Mail推送服務(wù)雖然很好，但是門檻高，需與移動運營商合作，尤其對于個人用戶，手續(xù)相當(dāng)復(fù)雜，黑莓代理商不提供個人用戶的郵件服務(wù)器，需要與一家開通黑莓業(yè)務(wù)的企業(yè)掛靠，然后向移動申請開通郵件推送服務(wù)，耗時較長，并且價錢對于普通用戶高［12］。

2．4 第三方平臺

目前國內(nèi)、國外有一些推送平臺可供使用，但是涉及到收費、保密、服務(wù)質(zhì)量、擴(kuò)展等問題，市場占有率并不高。

3 本文解決方案

3．1 安全設(shè)計

系統(tǒng)中加入安全認(rèn)證機(jī)制，解決現(xiàn)有的消息推送系統(tǒng)存在安全漏洞這一問題。該機(jī)制主要分為兩步，即IP驗證模塊和數(shù)字簽名認(rèn)證模塊。通過設(shè)置IP白名單來驗證用戶的合法性，可以阻擋絕大部分非法請求;通過數(shù)字簽名認(rèn)證可以進(jìn)一步保證系統(tǒng)信息的安全，防止信息在傳輸過程中遭到篡改以及非法的攻擊等。

在消息發(fā)布客戶端向消息服務(wù)器發(fā)起連接發(fā)布請求時，消息服務(wù)器需要對其進(jìn)行安全認(rèn)證，以決定是否接收該客戶端的連接請求，通過安全認(rèn)證機(jī)制之后，才能使用消息推送服務(wù)，從而保證了消息推送系統(tǒng)的安全性，安全認(rèn)證機(jī)制流程如圖1所示。

圖1 安全認(rèn)證機(jī)制流程

安全認(rèn)證步驟如下:

(1)發(fā)布者客戶端請求消息發(fā)送服務(wù)之前，先調(diào)用服務(wù)器提供的數(shù)字簽名認(rèn)證服務(wù)生成密鑰對;

(2)發(fā)布者使用生成的私鑰加密生成數(shù)字簽名，并將公鑰、簽名以及數(shù)據(jù)發(fā)送給消息服務(wù)器，請求消息發(fā)布服務(wù);

(3)消息服務(wù)器在接收到發(fā)布者客戶端的消息發(fā)布請求服務(wù)之后，先通過IP驗證模塊，判斷發(fā)布者是否合法，驗證通過則進(jìn)行下一步，否則返回錯誤提示給消息發(fā)布者;

(4)消息服務(wù)器使用公鑰、簽名對數(shù)據(jù)驗證，驗證成功則進(jìn)行后續(xù)的消息服務(wù)，并返回成功提示給消息發(fā)布者，否則返回錯誤提示給消息發(fā)布者。

3．2 個性化智能推送

系統(tǒng)中加入多樣化智能選擇機(jī)制，解決現(xiàn)有的消息推送系統(tǒng)缺乏個性化智能推送的問題，該機(jī)制包括智能選擇發(fā)送方式模塊和智能選擇通信模式模塊。通過智能選擇發(fā)送方式模塊，系統(tǒng)可以根據(jù)用戶的個性化需求智能選擇用戶需要的通信方式，如軟件、郵箱、短信等。通過智能選擇通信模式模塊，系統(tǒng)可以根據(jù)傳遞消息的類型、用戶訂閱情況等來判斷使用合適的通信模式，如點對點模式、發(fā)布/訂閱模式。

在消息發(fā)送前，需要對要發(fā)送的消息進(jìn)行智能選擇，根據(jù)用戶的需求、消息的類型和消息的訂閱情況來智能選擇應(yīng)用合適的消息發(fā)送方式和消息通信模式，多樣化智能推送機(jī)制判斷的依據(jù)包括消息是否標(biāo)記過、接收端是否多、特定用戶是否指定、消息是否多等。多樣化智能選擇機(jī)制的流程如圖2所示。

圖2 多樣化智能推送機(jī)制流程

多樣化智能選擇步驟如下:

(1)當(dāng)收到需要傳遞的消息時，先要進(jìn)行智能選擇發(fā)送方式的判斷;

(2)看是否有標(biāo)記發(fā)送方式，如果消息發(fā)送方已經(jīng)標(biāo)記了用何種發(fā)送方式，比如MQTT推送、郵件推送、短信推送等，消息服務(wù)器就按照發(fā)送方標(biāo)識的發(fā)送方式進(jìn)行發(fā)送;如果沒有標(biāo)識以何種方式發(fā)送就默認(rèn)MQTT推送;

(3)進(jìn)行智能選擇通信模式的判斷;

(4)查看是否有標(biāo)記通信模式，如果消息發(fā)布方已經(jīng)標(biāo)識采用什么樣的通信模式，那么消息服務(wù)器就按照發(fā)送方標(biāo)識的通信模式進(jìn)行傳遞;如果沒有標(biāo)識通信模式，則繼續(xù)執(zhí)行下一步;

(5)判斷是否是給特定用戶發(fā)送消息，如果是就采用PTP通信模式，并且將其在消息屬性中進(jìn)行標(biāo)記，以便下次再轉(zhuǎn)發(fā)消息時方便快捷;

(6)如果不是就繼續(xù)判斷消息是否多，消息的多少由用戶自己設(shè)定一個閾值，如果消息超過這個閾值，就將消息先存入待發(fā)送的消息隊列;如果消息較少沒有超過設(shè)定的閾值，就選擇用Pub/Sub通信模式進(jìn)行消息推送并標(biāo)記。

3．3 消息管理機(jī)制

消息管理機(jī)制包括消息隊列管理模塊、訂閱表管理模塊、消息匹配轉(zhuǎn)發(fā)模塊，通過這些模塊的配合實現(xiàn)消息的處理存儲轉(zhuǎn)發(fā)功能。

3．3．1 消息隊列管理模塊

實現(xiàn)異步通信的核心本質(zhì)是隊列化，消息通過隊列進(jìn)行存儲轉(zhuǎn)發(fā)的機(jī)制稱作隊列管理機(jī)制。隊列管理機(jī)制是消息隊列模式的具體實現(xiàn)，主要有發(fā)送隊列、接收隊列、延遲隊列的管理。發(fā)送隊列接收消息發(fā)布者發(fā)送的消息，指定消息源地址，以便根據(jù)需要回復(fù)該消息時使用;接收隊列是訂閱者的消息接收隊列，指定了消息發(fā)往的目的地，消息服務(wù)器根據(jù)該信息決定發(fā)往哪個訂閱者;延遲隊列的作用是，當(dāng)消息無法發(fā)送出去時先保存到延遲發(fā)送隊列中，當(dāng)與客戶端連接成功后再發(fā)送。

3．3．2 訂閱表管理模塊

該模塊負(fù)責(zé)管理和維護(hù)訂閱表信息，訂閱表記錄了訂閱主題及對應(yīng)的客戶端訂閱信息［13-14］。

訂閱表管理模塊處理客戶端訂閱消息的算法流程如圖3所示。

圖3 訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對于客戶端的訂閱消息，首先在訂閱表中查詢是否已經(jīng)存在該訂閱主題，如果不存在該主題，則創(chuàng)建該主題，并創(chuàng)建該客戶端訂閱者信息節(jié)點，否則進(jìn)行步驟(2);

(2)查詢該客戶是否已經(jīng)訂閱了該主題的消息，如果已經(jīng)訂閱該主題消息，則對訂閱者信息節(jié)點更新修改，否則增加該訂閱者信息節(jié)點。

訂閱表管理模塊處理客戶端取消訂閱消息的算法流程如圖4所示。

圖4 取消訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對于客戶端取消訂閱消息，首先在訂閱表中查詢是否存在該訂閱主題，如果不存在則結(jié)束，否則進(jìn)行步驟(2);

(2)查詢該客戶是否訂閱了此主題的消息，如果訂閱了，則刪除該客戶端訂閱節(jié)點，繼續(xù)進(jìn)行步驟(3);

(3)如果刪除該客戶端訂閱節(jié)點后，該訂閱主題對應(yīng)的客戶端訂閱節(jié)點為空，則刪除該訂閱主題。

3．3．3 消息匹配轉(zhuǎn)發(fā)模塊

系統(tǒng)通過該模塊接收消息發(fā)布者發(fā)布的消息，消息訂閱者的訂閱消息、取消訂閱消息，通過消息主題的交互匹配，將收到的消息正確地轉(zhuǎn)發(fā)給相應(yīng)的訂閱者。

4 系統(tǒng)實現(xiàn)

4．1 系統(tǒng)架構(gòu)設(shè)計

消息推送系統(tǒng)架構(gòu)設(shè)計如圖5所示，主要包括3個部分:消息發(fā)布者，消息服務(wù)器，消息訂閱者。

圖5 系統(tǒng)架構(gòu)

4．1．1 消息發(fā)布者

消息發(fā)布者相當(dāng)于消息的生產(chǎn)者，應(yīng)用程序每生產(chǎn)一條消息并不是直接交給消息接收者，而是交給消息服務(wù)器，由服務(wù)器決定將消息發(fā)送給哪些接收者。

4．1．2 消息訂閱者

消息訂閱者相當(dāng)于消息的消費者，應(yīng)用程序從收到消息開始，根據(jù)消息中的內(nèi)容做出響應(yīng)，并根據(jù)需要決定是否將結(jié)果反饋給消息服務(wù)器。消息的發(fā)布者與接收者的角色并不是固定的，基于異步通信機(jī)制的應(yīng)用程序通常既是消息的發(fā)布者，又是消息的訂閱者。

4．1．3 消息服務(wù)器

消息服務(wù)器是整個消息推送系統(tǒng)的核心，也是整個系統(tǒng)的創(chuàng)新設(shè)計所在，主要包括安全認(rèn)證機(jī)制、多樣化智能選擇機(jī)制和消息管理機(jī)制。安全認(rèn)證機(jī)制能夠避免非法連接，防止信息在傳輸過程中遭到篡改以及非法的攻擊，有效保證系統(tǒng)安全;多樣化智能選擇機(jī)制包括智能選擇發(fā)送方式和智能選擇通信模式，分別用來智能選擇用戶需要的發(fā)送查看方式和消息傳遞需要的通信模式;消息管理機(jī)制主要負(fù)責(zé)消息隊列管理、訂閱表管理、消息主題匹配、消息存儲轉(zhuǎn)發(fā)等。

4．2 系統(tǒng)工作流程

上述系統(tǒng)架構(gòu)的詳細(xì)工作流程如下:

(1)消息訂閱者連接到消息服務(wù)器，訂閱/取消自己的主題，按照訂閱主題監(jiān)聽自己的消息隊列;

(2)消息發(fā)布者將要發(fā)送的數(shù)據(jù)打包成消息的形式發(fā)送給消息服務(wù)器，并給該消息設(shè)定一個主題;

(3)消息服務(wù)器通過安全認(rèn)證機(jī)制驗證消息發(fā)布者的合法性，驗證通過進(jìn)入下一步，否則消息推送服務(wù)停止;

(4)消息服務(wù)器通過多樣化智能選擇機(jī)制，選取合適的發(fā)送方式和通信模式;

(5)消息代理服務(wù)器通過消息管理機(jī)制進(jìn)行主題匹配，并將相應(yīng)主題的消息推送到訂閱了該主題的移動終端的消息隊列;

(6)消息訂閱者監(jiān)聽的消息隊列有新消息，接收推送過來的新消息，并查看新消息。

5 測試結(jié)果與分析

5．1 測試環(huán)境

基于農(nóng)業(yè)物聯(lián)網(wǎng)平臺的手機(jī)App軟件，是所在物聯(lián)網(wǎng)項目組開發(fā)的一款集農(nóng)業(yè)物聯(lián)網(wǎng)平臺數(shù)據(jù)監(jiān)測、反向控制、消息推送接收等功能于一體的手機(jī)應(yīng)用，將它作為功能測試的終端，功能測試示意圖如圖6所示。采用的PC服務(wù)器配置情況為Windows 7操作系統(tǒng)，4核處理器，CPU為AMD Athlon(tm)II X4 645 Processor，內(nèi)存 2 GB，硬盤容量 450 GB。

圖6 功能測試示意圖

5．2 功能測試

5．2．1 安全認(rèn)證機(jī)制功能測試

選取未經(jīng)消息服務(wù)器許可的PC客戶端訪問消息服務(wù)器，測試結(jié)果如圖7所示。選取PC的IP為192．168．64．102，雖然該 PC 客戶端知道消息服務(wù)器的 IP 為 192．168．64．131，端口號為 9095，但由于沒有通過消息服務(wù)器的安全認(rèn)證機(jī)制，得到了服務(wù)器返回的“Permission denied”錯誤提示，因此該PC無法使用消息推送服務(wù)，從而證明安全認(rèn)證機(jī)制能夠正常工作。

圖7 安全認(rèn)證失敗

5．2．2 多樣化智能選擇機(jī)制功能測試

物聯(lián)網(wǎng)平臺發(fā)布三類消息，分別進(jìn)行智能測試。

(1)群發(fā)消息:發(fā)送通知公告，界面如圖8所示，7月9日周三下午7:39手機(jī)終端收到了物聯(lián)網(wǎng)平臺推送過來的消息，消息主題“通知公告”，消息內(nèi)容“來自物聯(lián)網(wǎng)平臺的農(nóng)業(yè)資訊”。

圖8 通知公告消息

消息服務(wù)器上的部分?jǐn)?shù)據(jù)結(jié)果如圖9所示，訂閱主題“通知公告”，消息內(nèi)容:“來自物聯(lián)網(wǎng)平臺的農(nóng)業(yè)資訊”，消息級別 QoS為1，“false”表明是實時發(fā)出的消息，消息服務(wù)器 IP 為192．168．64．131。

圖9 消息服務(wù)器上的部分?jǐn)?shù)據(jù)

(2)特定用戶消息:分別給User1和User2 2個用戶發(fā)送不同的消息，界面如圖10、圖11所示，User1收到了“User 1的報警信息”;User 2收到了“User 2的報警信息”。

圖10 User1用戶消息

圖11 User2用戶消息

(3)其他發(fā)送方式:郵箱發(fā)送，郵箱界面如圖12所示，郵件的發(fā)件人為“消息服務(wù)管理系統(tǒng)”，收件人為本文作者的QQ郵箱，用戶名為“Jenny”，消息內(nèi)容為“您好!這是一封來自農(nóng)業(yè)物聯(lián)網(wǎng)平臺的郵件，請查收?！?/p>

圖12 郵件詳情信息

通過上述3類消息的測試結(jié)果，可以看出該消息推送系統(tǒng)能夠很好地按照消息的不同類型和用戶的個性化需求，智能選擇合適的消息通信模式和消息發(fā)送方式。

5．3 性能測試

為了確保消息服務(wù)器在負(fù)載逐漸增加情況下的性能，需要進(jìn)行性能測試。通過在PC端實現(xiàn)客戶端程序，模擬大量用戶對服務(wù)器發(fā)起連接請求，鑒于服務(wù)器配置條件和時延需求，連接數(shù)分別為100，200，400，600，800，1 000，并在不同連接數(shù)情況下發(fā)送不同數(shù)量的消息，消息數(shù)分別為 10，100，200，300，400，500，推送成功率及服務(wù)器發(fā)送時間、接收時間結(jié)果如表1所示。

表1 消息推送性能測試結(jié)果

從表1中可以看到，在發(fā)送消息數(shù)一定的情況下，隨著連接數(shù)的增多，消息發(fā)送時間和接收時間略有增加，變化幅度不太明顯，可見連接數(shù)對系統(tǒng)性能影響較小;在連接數(shù)一定的情況下，隨著發(fā)送消息數(shù)量的增多，消息發(fā)送時間和接收時間不斷增加，尤其是發(fā)送時間增加幅度較大，可見消息數(shù)對系統(tǒng)性能影響較大，面對大數(shù)據(jù)交互時易造成服務(wù)器性能瓶頸。從總體來看，在局域網(wǎng)環(huán)境下，所有推送的成功率都達(dá)到了100%，當(dāng)連接數(shù)為1 000，發(fā)送消息數(shù)為500時，發(fā)送時間和接收時間都在可接受范圍內(nèi)，系統(tǒng)性能良好。

6 結(jié)束語

本文論述了一種基于MQTT安全智能的消息推送系統(tǒng)，通過與客戶端聯(lián)合，對不同平臺上的用戶進(jìn)行高效、準(zhǔn)確的消息推送，目前已應(yīng)用于實際項目中，經(jīng)過測試，系統(tǒng)運行良好，滿足大部分企業(yè)級應(yīng)用的消息推送需求。

隨著物聯(lián)網(wǎng)系統(tǒng)的數(shù)據(jù)規(guī)模爆發(fā)式增長，大數(shù)據(jù)交互時消息服務(wù)器的性能瓶頸和單點失效的局限性越發(fā)明顯，嚴(yán)重影響了系統(tǒng)可用性［15］。因此，可以通過建立服務(wù)器集群，以加強(qiáng)服務(wù)器的穩(wěn)定性和可靠性，并且支持更多的用戶;也可以通過構(gòu)建高性能低功耗的云計算平臺，依托云計算和智能虛擬化等技術(shù)，實現(xiàn)靈活高效的計算資源調(diào)度，充分利用計算資源，從而改善服務(wù)器性能，增強(qiáng)系統(tǒng)可靠性，為最終用戶提供更加動態(tài)，高效和可靠的網(wǎng)絡(luò)體驗。對于企業(yè)中龐大的系統(tǒng)，當(dāng)系統(tǒng)出現(xiàn)故障時，系統(tǒng)的恢復(fù)能力十分重要?？紤]在消息推送系統(tǒng)中加入消息緩存機(jī)制，以確保系統(tǒng)出現(xiàn)突發(fā)故障或者非正常退出時，消息依然能夠安全可靠地傳送到目的地，并且不會重復(fù)傳送。

［1］ 顧正敏．一種面向Android平臺的輕量級推送技術(shù)研究與應(yīng)用［D］．北京:北京大學(xué)，2013．

［2］ 姜夢蘭．基于消息中間件服務(wù)可靠性保障方案的研究與實現(xiàn)［D］．成都:電子科技大學(xué)，2010．

［3］ 馬 ?。谙⒅虚g件的Web Services的研究和實現(xiàn)［D］．大連:大連海事大學(xué)，2007．

［4］ 王廣澤．基于 Pub/Sub模式的智能消息中間件研究［J］．信息技術(shù)，2009，(5):171-173．

［5］ Lee S，Kim H，Hong Dong-kweon，et al．Correlation Analysis of MQTT Loss and Delay According to Qos Level［C］//Proceedings of International Conference on Information Networking．Washington D．C．，USA:IEEE Press，2013:714-717．

［6］ Behnel S，F(xiàn)iege L，Muehl G，et al．On Quality of Service and Publish Subscribe［C］//Proceedings of the 26th IEEE International Conference on Distributed Computing Systems．Washington D．C．，USA:IEEE Press，2006:20．

［7］ Hunkeler U，Truong H L，Clark A S．MQTT-S-A Publish/Subscribe Protocol for Wireless Sensor Networks［C］//Proceedings of Conference on Communication Systems Software and Middleware．Washington D．C．，USA:IEEE Press，2008:791-798．

［8］ Collina M，Corazza G E，Vanelli-Coralli A．Introducing the QEST Broker:Scaling the IoT by Bridging MQTT and REST［C］//Proceedings of the 3rd International Symposium on PersonalIndoorand Mobile Radio Communications．Washington D．C．，USA:IEEE Press，2012:36-41．

［9］ Hansen J，Gronli T M，Ghinea G．Cloud to Device Push Messaging on Android:A Case Study［C］//Proceedings of International Conference on Advanced Information Networking and Applications Workshops．Washington D．C．，USA:IEEE Press，2012:1298-1303．

［10］ 張長學(xué)，張 偉，董智明．移動推送技術(shù)面面觀［J］．移動通信，2011，35(5):21-27．

［11］ 王克峰．基于Android的信息推送管理系統(tǒng)的設(shè)計和實現(xiàn)［D］．大連:大連理工大學(xué)，2012．

［12］ 游思佳，趙久成，伏京生．黑莓推送機(jī)制和聯(lián)通黑莓業(yè)務(wù)發(fā)展分析［J］．信息通信技術(shù)，2011，(6):75-79．

［13］ 杜 蕊．智能消息中間件的研究與應(yīng)用［D］．哈爾濱:哈爾濱理工大學(xué)，2012．

［14］ 潘國偉，宋 瑋，王相南，等．發(fā)布/訂閱模式消息中間件在 SCADA系統(tǒng)中的應(yīng)用［J］．電網(wǎng)技術(shù)，2008，32(18):77-80．

［15］ Bernstein P，Philip A．Middleware:A Model for Distributed Services［J］．Communications of the ACM，1996，39(2):86-97．