魏更宇+郭雨萌

摘 要：為了解決資源受限傳感器網(wǎng)絡(luò)中的CoAP協(xié)議組通信不可靠性的問題，采用基于代理服務(wù)器的方式，給出了CoAP協(xié)議可靠組通信系統(tǒng)的設(shè)計方案，并通過仿真系統(tǒng)模擬實現(xiàn)了此方案。針對接收端節(jié)點數(shù)量的不同，分別采用基于代理服務(wù)器和單播重傳的方式實現(xiàn)了該系統(tǒng)的構(gòu)建，為CoAP協(xié)議可靠組通信方案的構(gòu)建提供了理論模型和架構(gòu)基礎(chǔ)。

關(guān)鍵詞：CoAP;組通信;可靠性;代理;多播

中圖分類號：TP316 ? ? ? ? 文獻標識碼： ? ? ? ? ? ? 文章編號：2095-1302（2014）12-00-04

0 ?引 ?言

物聯(lián)網(wǎng)中包括了傳統(tǒng)的互聯(lián)網(wǎng)和主要由傳感器節(jié)點組成的資源受限網(wǎng)絡(luò)，而在互聯(lián)網(wǎng)絡(luò)中普遍使用的應(yīng)用層協(xié)議HTTP不能夠適用于受限網(wǎng)絡(luò)環(huán)境，因此就需要引入一個新的通信協(xié)議針對資源受限網(wǎng)絡(luò)進行通信。在這一背景下，互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force，IETF）成立了CoRE[1]工作組，負責定義受限網(wǎng)絡(luò)中的應(yīng)用層通信協(xié)議——CoAP協(xié)議。

CoAP協(xié)議將實現(xiàn)資源受限節(jié)點間的有效信息傳輸作為基本目標，其定義了在兩個傳感器之間以單播方式傳輸?shù)耐ㄐ趴刂茀f(xié)議，能夠?qū)崿F(xiàn)M2M的可靠消息傳遞。同時，CoAP協(xié)議也定義了針對傳感器節(jié)點之間的組通信協(xié)議。

然而，目前的CoAP組通信是基于IP組播[2]協(xié)議，其僅能實現(xiàn)不可靠的組通信。具體而言，比照OMA （OPEN MOBILE ALLIANCE， 開放移動聯(lián)盟）提出的輕量級M2M應(yīng)用的需求和架構(gòu)文檔，組通信可靠性沒有保障的CoAP協(xié)議不能夠滿足OMA針對應(yīng)用的需求。在OMA提出的應(yīng)用場景中，如果使用CoAP協(xié)議的不可靠組通信，將會對其定義的應(yīng)用場景帶來極大的隱患。

1 ?IETF 關(guān)于CoAP及其組通信的介紹

1.1 ?CoAP協(xié)議

CoAP協(xié)議是一種應(yīng)用于受限網(wǎng)絡(luò)和節(jié)點的特殊Web傳輸協(xié)議，在應(yīng)用終端間提供方法/響應(yīng)的交互模式，支持內(nèi)置的資源發(fā)現(xiàn)，包含關(guān)鍵的網(wǎng)絡(luò)概念，比如URIs和Content-type。CoAP協(xié)議類似于HTTP協(xié)議[3]，但不是簡單地對HTTP進行壓縮，而是重新實現(xiàn)了一個類似HTTP的REST子集[4]，以適應(yīng)資源受限環(huán)境[5]。

CoAP協(xié)議在資源受限網(wǎng)絡(luò)中所起的作用類似于HTTP協(xié)議[6]在互聯(lián)網(wǎng)中所起的作用。其基于UDP傳輸?shù)姆绞?，可明顯降低傳輸開銷，并可滿足CoAP請求的組通信傳遞，而組通信對于M2M應(yīng)用是最重要的需求之一。

1.2 ?CoAP組通信

CoAP協(xié)議構(gòu)建在UDP協(xié)議之上，用以減少開銷且支持組通信[5]。由于UDP協(xié)議的特性，即不保證數(shù)據(jù)傳輸?shù)目煽啃?，?dǎo)致CoAP協(xié)議雖然支持組通信，但不保證數(shù)據(jù)傳輸?shù)目煽啃院陀行蛐?。這一特性，在某些特定應(yīng)用場景中會為用戶針對設(shè)備的操作帶來隱患和非便利因素，若用戶想同時針對多個接收端進行可靠的控制，則其必須使用逐一控制的方式實現(xiàn)這一功能，否則將有可能導(dǎo)致部分接收端并未按照用戶的意愿執(zhí)行相應(yīng)的操作，這在實際應(yīng)用中是不能被接受的。

基于以上原因，本文提出了幾種用于CoAP可靠組通信設(shè)計的方案，針對不同規(guī)模的數(shù)據(jù)集使用不同的方法，解決CoAP協(xié)議的這一缺陷。

2 ?OMA的M2M應(yīng)用需求及分析

2.1 ?基于傳感器網(wǎng)絡(luò)的路燈管理系統(tǒng)應(yīng)用場景

某用戶是一個街區(qū)路燈系統(tǒng)的管理員，負責管理其所在街區(qū)的所有路燈狀態(tài)的變更及維護。為了更好、更快地實現(xiàn)針對路燈的控制，該用戶將低成本的M2M傳感器嵌入在這些路燈中，并通過一個路燈遠程控制器針對這些傳感器進行操控。

針對這一場景，需要實現(xiàn)以下幾方面的功能：用戶具備遠程開、關(guān)特定路燈的能力，包括一次操控一個路燈和一次操控多個路燈;用戶能夠?qū)崟r、準確地知道每個路燈的現(xiàn)有狀態(tài);確保這些路燈只接受授權(quán)用戶的指令，杜絕可能存在的安全隱患。

通過以上描述，可以構(gòu)建一個基于物聯(lián)網(wǎng)的路燈控制系統(tǒng)，如圖1所示。

圖 1 ?基于傳感器網(wǎng)絡(luò)的路燈管理系統(tǒng)

2.2 ?針對OMA應(yīng)用場景的需求分析

通過針對上述應(yīng)用場景的需求分析，將一次完整的針對M2M傳感器的控制操作流程概括如下：

（1）用戶通過遠程控制器接入互聯(lián)網(wǎng)，指令通過HTTP協(xié)議得以傳輸。

（2）當該指令到達終端設(shè)備組成的傳感器網(wǎng)絡(luò)時，通過HTTP協(xié)議和CoAP協(xié)議相互轉(zhuǎn)換的功能，實現(xiàn)針對指令的報文封裝和轉(zhuǎn)換，將互聯(lián)網(wǎng)中的HTTP報文[3]封裝為CoAP報文。

（3）經(jīng)過封裝轉(zhuǎn)換后的信息通過CoAP協(xié)議在傳感器網(wǎng)絡(luò)中進行傳輸，最終到達各個設(shè)備上的M2M傳感器，實現(xiàn)用戶設(shè)計的既定操作。

在這一過程中，欲實現(xiàn)用戶提出的幾項功能，需具備遠程操控特定設(shè)備的能力，而CoAP協(xié)議目前尚僅能滿足針對單播的可靠傳輸，其針對組通信傳輸尚不能保證可靠性。這一限制條件就導(dǎo)致了當用戶想要同時針對多個設(shè)備進行控制時，會面臨以下幾點問題：

（1）若想實現(xiàn)針對多個設(shè)備的可靠控制，則只能采用用戶逐一針對設(shè)備進行操控的方式，利用CoAP協(xié)議針對單播可實現(xiàn)可靠傳輸這一特性實現(xiàn)該操作。

（2）若想一次性地通過組通信實現(xiàn)針對設(shè)備的控制，則CoAP協(xié)議目前的傳輸機制將會為此操作埋下隱患，即部分設(shè)備可能會因CoAP協(xié)議組通信傳輸?shù)牟豢煽啃灾率蛊錄]有按照用戶的要求進行相應(yīng)的操作，這在OMA設(shè)定的應(yīng)用場景中是不能為用戶所接受的。

綜上所述，針對不同規(guī)模的用戶數(shù)集群數(shù)量，需實現(xiàn)的功能中皆包含針對設(shè)備的可靠單播通信和可靠組播通信。而作為傳感器網(wǎng)絡(luò)重要傳輸協(xié)議之一的CoAP協(xié)議，目前尚還只能實現(xiàn)針對單播的可靠通信，而其針對組通信不可靠傳輸?shù)倪@一問題將會在諸如以上場景的實際應(yīng)用中產(chǎn)生巨大的隱患。

3 ?CoAP可靠組通信方案設(shè)計

3.1 ?逐一單播方案

為了解決CoAP協(xié)議組通信不可靠的問題，根據(jù)接收端數(shù)量的多少，可以采用不同的傳輸方式加以解決。當控制的接收端數(shù)量小于預(yù)設(shè)值Vs時（Vs值由用戶事先根據(jù)實際情況加以設(shè)定，用以判斷接收端數(shù)量的多少，決定采用何種發(fā)送方式），考慮到實際的發(fā)送效率及運營成本，可以采用多個單播的形式實現(xiàn)組通信的功能，具體實現(xiàn)方式如下：

發(fā)送端以CoAP單播的形式向每個接收端發(fā)送命令。在接收端接收到信息后，會立即發(fā)送一個Request響應(yīng)信息到發(fā)送端。經(jīng)過一個固定延遲△t1后（△t1值根據(jù)接收端反饋信息所需花費的平均時間乘以系數(shù)m確定），未發(fā)送Request響應(yīng)的接收端，即被判定為接收失敗或是Request響應(yīng)在傳輸過程中出現(xiàn)了意外。此時，發(fā)送端針對這些被判定為接收失敗或是Request響應(yīng)在傳輸過程中出現(xiàn)問題的接收節(jié)點再次重復(fù)發(fā)送該信息。重復(fù)以上過程，直到最終所有的接收端都成功返回Request信息為止，此次組通信發(fā)送即宣告完成。

以上這種基于CoAP逐一單播的形式進行傳輸?shù)囊笫?，接收端?shù)量小于預(yù)設(shè)值Vs，如圖2所示。

圖2 ?小規(guī)模接收端數(shù)量

3.2 ?基于代理的可靠組通信實現(xiàn)方式

3.2.1 ?逐一單播方案的局限性

通過逐一單播實現(xiàn)CoAP可靠組通信的方式，其優(yōu)點是實現(xiàn)簡便，成本較低;而其缺點則是操作過程繁瑣，且僅適用于接收端數(shù)量較小時使用。

當系統(tǒng)中的接收端數(shù)量較多時，若繼續(xù)采用通過多個單播重復(fù)發(fā)送實現(xiàn)這一功能，則易導(dǎo)致出現(xiàn)以下幾個問題：

（1）接收端接收到信息的時間間隔過大。

（2）易產(chǎn)生發(fā)送端擁塞[8]問題。

（3）操作過程繁瑣。

基于以上三點原因，當接收端數(shù)量較大時，需要另一種更為高效可靠的方式解決CoAP組通信不可靠的問題。由此，本文將會介紹一種基于代理（Proxy）[9]的方式實現(xiàn)CoAP可靠組通信的方案，這一方案可以較好地同時解決上述三個問題。

圖3 ?大規(guī)模接收端數(shù)量

如圖3所示，在這種基于代理的CoAP可靠組通信傳輸系統(tǒng)中，除發(fā)送端和接收端以外，還需要引入一個代理服務(wù)器針對報文進行中轉(zhuǎn)、判定和重傳操作，以減輕發(fā)送端的擁塞[8]壓力，同時也能更好、更快地實現(xiàn)針對報文的重傳操作。

此種基于代理的可靠組通信傳輸方式[10]，具體而言可以分為以下幾個步驟。

3.2.2 ?發(fā)送過程

基于代理的CoAP可靠組通信的發(fā)送過程分為以下幾步：

（1）由發(fā)送端通過CoAP單播的形式，將消息發(fā)送給代理服務(wù)器。

（2）代理服務(wù)器將該消息報文解析后，獲取到本次發(fā)送的實際接收端的地址。

（3）代理服務(wù)器將此報文進行整理封裝，通過CoAP組通信的形式發(fā)送給上述解析出的接收端地址。

同一時間，代理服務(wù)器將這些接收端的地址加以記錄，建立一個布爾數(shù)組，用以記錄后續(xù)的接收狀態(tài)，如圖4所示。

圖4 ?代理服務(wù)器的布爾數(shù)組

3.2.3 ?接收端匹配及反饋過程

在發(fā)送過程結(jié)束后，接收端結(jié)點接收消息報文的過程可分為以下幾步：

接收端接收到由代理服務(wù)器發(fā)出的消息報文后，根據(jù)報文中的目標地址進行匹配，若匹配成功則加以接收;匹配成功的接收端針對報文中的內(nèi)容進行解析，并根據(jù)報文內(nèi)容完成對應(yīng)的操作;由完成以上兩步操作的部分接收端向代理服務(wù)器發(fā)送反饋信息，在這一過程中，為保證傳輸過程的可靠性，這一反饋消息需采用CoAP單播加以實現(xiàn)。

3.2.4 ?代理服務(wù)器處理反饋并重傳信息

完成了接收端匹配及反饋過程后，代理服務(wù)器需針對反饋信息進行分析處理，并根據(jù)需求進行重傳操作，這一過程可分為以下幾步：

代理服務(wù)器針對收到的眾多接收端發(fā)送來的反饋信息，根據(jù)眾接收端的地址和編號，針對其在發(fā)送步驟時創(chuàng)建的代表接收端狀態(tài)的布爾數(shù)組進行狀態(tài)變更。

在經(jīng)過了一個預(yù)設(shè)好的時間△t3后，代理服務(wù)器針對狀態(tài)布爾數(shù)組進行遍歷，針對其中尚未變更狀態(tài)的數(shù)組單元即代表該接收端并未成功接收到代理服務(wù)器之前所發(fā)來的信息或是發(fā)送反饋信息失敗。此時，由代理服務(wù)器將之前的信息報文再次重傳給這些被判定為接收失敗的接收端。

重傳時，需要根據(jù)本次重傳中接收端的數(shù)量進行判斷，若接收端數(shù)量小于Vs值，則采用逐一單播的形式進行發(fā)送;若接收端數(shù)量大于等于Vs值，則繼續(xù)采用組通信的形式進行發(fā)送，后續(xù)反饋過程同本次反饋過程。

狀態(tài)變更失敗或反饋信息發(fā)送失敗的接收端，在接收到由代理服務(wù)器發(fā)送來的重傳信息后，按照報文中的內(nèi)容進行相應(yīng)的操作，并將成功變更的信息反饋給代理服務(wù)器。

重復(fù)以上步驟，直到代理服務(wù)器中的狀態(tài)布爾數(shù)組全部完成變更，即本次組通信操作成功。

完成以上4步后，代理服務(wù)器需通過CoAP單播反饋給發(fā)送端一個確認信息，確認本次發(fā)送成功。

3.2.5 ?發(fā)送連貫性

在以上步驟進行的過程中，發(fā)送端可以繼續(xù)發(fā)送后續(xù)命令，由于代理服務(wù)器的處理能力相比發(fā)送端較為優(yōu)越，因此處理發(fā)送端重傳的功能由代理服務(wù)器完成，發(fā)送端在這一過程中可進行連貫發(fā)送。

3.2.6 ?基于代理的可靠組通信流程圖

基于代理的可靠組通信流程圖如圖5所示。

圖5 ?CoAP協(xié)議基于代理的可靠組通信傳輸流程圖

3.3 ?特殊狀況處理

3.3.1 ?結(jié)點睡眠

當接收端結(jié)點即將處于睡眠模式時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身狀態(tài)變更的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于睡眠狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于睡眠狀態(tài)，則需先發(fā)送一個睡眠喚醒消息，將這些結(jié)點喚醒，之后再針對該結(jié)點進行消息發(fā)送。

3.3.2 ?結(jié)點關(guān)機或供電不足

當接收端結(jié)點即將關(guān)機（供電不足或人工關(guān)機）時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身即將關(guān)機的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于關(guān)機狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于關(guān)機狀態(tài)，則暫時保留本要發(fā)送的數(shù)據(jù)。當CoAP資源目錄服務(wù)器告知代理服務(wù)器關(guān)于該結(jié)點重新開機時，代理服務(wù)器再將本要發(fā)送消息發(fā)送給該結(jié)點。

4 ?仿真實現(xiàn)CoAP可靠組通信

基于上文介紹的CoAP可靠組通信應(yīng)用方案，利用JAVA仿真構(gòu)建了一個基于代理的CoAP可靠組通信模擬系統(tǒng)，該系統(tǒng)可實現(xiàn)基于代理的模擬CoAP組通信。

圖6 ?仿真實現(xiàn)CoAP可靠組通信

該通信的規(guī)則為：由發(fā)送端將報文發(fā)送至代理服務(wù)器，代理服務(wù)器根據(jù)其中的接收端數(shù)量判定是何種方式進行重傳。經(jīng)大量實驗證明，當接收端數(shù)量大于Vs時采用CoAP組通信，當接收端數(shù)量小于等于Vs時采用CoAP單播通信如某次組通信發(fā)送后出現(xiàn)了接受失敗的節(jié)點，則會針對其進行重傳，重傳的方式同樣由接收端數(shù)量來決定。重復(fù)以上步驟，直至所有接收端節(jié)點都順利接收到該報文，此次發(fā)送結(jié)束。

5 ?結(jié) ?語

目前互聯(lián)網(wǎng)工程任務(wù)組的Core工作組給出的CoAP協(xié)議草案中尚未提出針對CoAP組通信不可靠性的有效解決辦法。而在OMA 等提出的應(yīng)用場景中，CoAP協(xié)議由于其不可靠組通信這一特性將不能勝任此類應(yīng)用場景對傳輸協(xié)議所提出的需求。

基于以上背景，本文利用CoAP協(xié)議的基本特性，構(gòu)建了針對不同規(guī)模接收端數(shù)量的兩類傳輸方式的可靠組通信理論模型，即基于代理服務(wù)器和逐一單播的形式實現(xiàn)CoAP可靠組通信。在構(gòu)建理論模型的基礎(chǔ)上，本文還進一步通過程序搭建了CoAP協(xié)議可靠組通信模擬系統(tǒng)，在該系統(tǒng)中真實模擬了CoAP組通信的全過程，清晰而直觀地將CoAP可靠組通信的實現(xiàn)方案呈現(xiàn)于該系統(tǒng)中。通過理論模型的構(gòu)建和模擬系統(tǒng)的架構(gòu)，為后續(xù)研究CoAP協(xié)議可靠組通信奠定了良好的理論基礎(chǔ)。

參考文獻

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入淺出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]劉紫青，程燕，關(guān)聯(lián)，等.CoAP 協(xié)議研究[J].電視技術(shù)，2013，37（ 7）：192-196

[6]蘇勇.深入理解HTTP協(xié)議[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000

3.2.6 ?基于代理的可靠組通信流程圖

基于代理的可靠組通信流程圖如圖5所示。

圖5 ?CoAP協(xié)議基于代理的可靠組通信傳輸流程圖

3.3 ?特殊狀況處理

3.3.1 ?結(jié)點睡眠

當接收端結(jié)點即將處于睡眠模式時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身狀態(tài)變更的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于睡眠狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于睡眠狀態(tài)，則需先發(fā)送一個睡眠喚醒消息，將這些結(jié)點喚醒，之后再針對該結(jié)點進行消息發(fā)送。

3.3.2 ?結(jié)點關(guān)機或供電不足

當接收端結(jié)點即將關(guān)機（供電不足或人工關(guān)機）時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身即將關(guān)機的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于關(guān)機狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于關(guān)機狀態(tài)，則暫時保留本要發(fā)送的數(shù)據(jù)。當CoAP資源目錄服務(wù)器告知代理服務(wù)器關(guān)于該結(jié)點重新開機時，代理服務(wù)器再將本要發(fā)送消息發(fā)送給該結(jié)點。

4 ?仿真實現(xiàn)CoAP可靠組通信

基于上文介紹的CoAP可靠組通信應(yīng)用方案，利用JAVA仿真構(gòu)建了一個基于代理的CoAP可靠組通信模擬系統(tǒng)，該系統(tǒng)可實現(xiàn)基于代理的模擬CoAP組通信。

圖6 ?仿真實現(xiàn)CoAP可靠組通信

該通信的規(guī)則為：由發(fā)送端將報文發(fā)送至代理服務(wù)器，代理服務(wù)器根據(jù)其中的接收端數(shù)量判定是何種方式進行重傳。經(jīng)大量實驗證明，當接收端數(shù)量大于Vs時采用CoAP組通信，當接收端數(shù)量小于等于Vs時采用CoAP單播通信如某次組通信發(fā)送后出現(xiàn)了接受失敗的節(jié)點，則會針對其進行重傳，重傳的方式同樣由接收端數(shù)量來決定。重復(fù)以上步驟，直至所有接收端節(jié)點都順利接收到該報文，此次發(fā)送結(jié)束。

5 ?結(jié) ?語

目前互聯(lián)網(wǎng)工程任務(wù)組的Core工作組給出的CoAP協(xié)議草案中尚未提出針對CoAP組通信不可靠性的有效解決辦法。而在OMA 等提出的應(yīng)用場景中，CoAP協(xié)議由于其不可靠組通信這一特性將不能勝任此類應(yīng)用場景對傳輸協(xié)議所提出的需求。

基于以上背景，本文利用CoAP協(xié)議的基本特性，構(gòu)建了針對不同規(guī)模接收端數(shù)量的兩類傳輸方式的可靠組通信理論模型，即基于代理服務(wù)器和逐一單播的形式實現(xiàn)CoAP可靠組通信。在構(gòu)建理論模型的基礎(chǔ)上，本文還進一步通過程序搭建了CoAP協(xié)議可靠組通信模擬系統(tǒng)，在該系統(tǒng)中真實模擬了CoAP組通信的全過程，清晰而直觀地將CoAP可靠組通信的實現(xiàn)方案呈現(xiàn)于該系統(tǒng)中。通過理論模型的構(gòu)建和模擬系統(tǒng)的架構(gòu)，為后續(xù)研究CoAP協(xié)議可靠組通信奠定了良好的理論基礎(chǔ)。

參考文獻

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入淺出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]劉紫青，程燕，關(guān)聯(lián)，等.CoAP 協(xié)議研究[J].電視技術(shù)，2013，37（ 7）：192-196

[6]蘇勇.深入理解HTTP協(xié)議[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000

3.2.6 ?基于代理的可靠組通信流程圖

基于代理的可靠組通信流程圖如圖5所示。

圖5 ?CoAP協(xié)議基于代理的可靠組通信傳輸流程圖

3.3 ?特殊狀況處理

3.3.1 ?結(jié)點睡眠

當接收端結(jié)點即將處于睡眠模式時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身狀態(tài)變更的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于睡眠狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于睡眠狀態(tài)，則需先發(fā)送一個睡眠喚醒消息，將這些結(jié)點喚醒，之后再針對該結(jié)點進行消息發(fā)送。

3.3.2 ?結(jié)點關(guān)機或供電不足

當接收端結(jié)點即將關(guān)機（供電不足或人工關(guān)機）時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身即將關(guān)機的消息;CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點處于關(guān)機狀態(tài);當代理服務(wù)器進行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點已處于關(guān)機狀態(tài)，則暫時保留本要發(fā)送的數(shù)據(jù)。當CoAP資源目錄服務(wù)器告知代理服務(wù)器關(guān)于該結(jié)點重新開機時，代理服務(wù)器再將本要發(fā)送消息發(fā)送給該結(jié)點。

4 ?仿真實現(xiàn)CoAP可靠組通信

基于上文介紹的CoAP可靠組通信應(yīng)用方案，利用JAVA仿真構(gòu)建了一個基于代理的CoAP可靠組通信模擬系統(tǒng)，該系統(tǒng)可實現(xiàn)基于代理的模擬CoAP組通信。

圖6 ?仿真實現(xiàn)CoAP可靠組通信

該通信的規(guī)則為：由發(fā)送端將報文發(fā)送至代理服務(wù)器，代理服務(wù)器根據(jù)其中的接收端數(shù)量判定是何種方式進行重傳。經(jīng)大量實驗證明，當接收端數(shù)量大于Vs時采用CoAP組通信，當接收端數(shù)量小于等于Vs時采用CoAP單播通信如某次組通信發(fā)送后出現(xiàn)了接受失敗的節(jié)點，則會針對其進行重傳，重傳的方式同樣由接收端數(shù)量來決定。重復(fù)以上步驟，直至所有接收端節(jié)點都順利接收到該報文，此次發(fā)送結(jié)束。

5 ?結(jié) ?語

目前互聯(lián)網(wǎng)工程任務(wù)組的Core工作組給出的CoAP協(xié)議草案中尚未提出針對CoAP組通信不可靠性的有效解決辦法。而在OMA 等提出的應(yīng)用場景中，CoAP協(xié)議由于其不可靠組通信這一特性將不能勝任此類應(yīng)用場景對傳輸協(xié)議所提出的需求。

基于以上背景，本文利用CoAP協(xié)議的基本特性，構(gòu)建了針對不同規(guī)模接收端數(shù)量的兩類傳輸方式的可靠組通信理論模型，即基于代理服務(wù)器和逐一單播的形式實現(xiàn)CoAP可靠組通信。在構(gòu)建理論模型的基礎(chǔ)上，本文還進一步通過程序搭建了CoAP協(xié)議可靠組通信模擬系統(tǒng)，在該系統(tǒng)中真實模擬了CoAP組通信的全過程，清晰而直觀地將CoAP可靠組通信的實現(xiàn)方案呈現(xiàn)于該系統(tǒng)中。通過理論模型的構(gòu)建和模擬系統(tǒng)的架構(gòu)，為后續(xù)研究CoAP協(xié)議可靠組通信奠定了良好的理論基礎(chǔ)。

參考文獻

[1] IETF. Constrained RESTful Environments（coRE） [EB/OL].http：//datatracker.ietf.org/wg/core/charter/，2012.

[2] Deering S.Multicast Routing in Internetworks and extended LANs[J].ACM Transaction on Computer Systems，1990， 8（2）：85-110

[3] FIELDING R，GETTYS J， MOGUL J，et al.RFC 2616 – Hypertext Transfer Protocol--HTTP/1.1[S].1999.

[4]ZTE.深入淺出REST[EB/OL].http：//www.infoq.com/cn/articles /rest-introduction /，2012.

[5]劉紫青，程燕，關(guān)聯(lián)，等.CoAP 協(xié)議研究[J].電視技術(shù)，2013，37（ 7）：192-196

[6]蘇勇.深入理解HTTP協(xié)議[EB/OL].http：//www.blogjava.net/zjusuyong/articles/304788.html，2012.

[7] CoRE Working Group. Constrained Application Protocol（CoAP draft-ietf-core-coap-13）[EB/OL].http：//download.csdn.net /detail/luoqiuzeng/5076830，2012.

[8] IETF. Congestion Control for the Constrained Application Protocol（CoAP draft-eggert-core-congestion-control-03）[EB/OL].http：//tools. ietf. org/id/draft-ietf-core-coap-03. html，2012.

[9] Lao L，Cui J H，Gerla M，et al .A Comparative Study of Multicast Protocol：Top，Bottom，or In the Middle[C]. MIEEE INFOCOM.Barcelona，2006

[10] Jannotti J， Gifford D K， Johnson K L， et al.Over cast：Reliable multicast with an overlay network[C] The 4th Usenix Symposium on Operating System Design and Implementation （OSDI）.Denver， 2000