基于CoAP協(xié)議可靠組通信系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn)

魏更宇+郭雨萌

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

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

中圖分類號(hào)：TP316 ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼： ? ? ? ? ? ? 文章編號(hào)：2095-1302（2014）12-00-04

0 ?引 ?言

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

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

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

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

1.1 ?CoAP協(xié)議

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

CoAP協(xié)議在資源受限網(wǎng)絡(luò)中所起的作用類似于HTTP協(xié)議[6]在互聯(lián)網(wǎng)中所起的作用。其基于UDP傳輸?shù)姆绞?，可明顯降低傳輸開銷，并可滿足CoAP請(qǐng)求的組通信傳遞，而組通信對(duì)于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)用場景中會(huì)為用戶針對(duì)設(shè)備的操作帶來隱患和非便利因素，若用戶想同時(shí)針對(duì)多個(gè)接收端進(jìn)行可靠的控制，則其必須使用逐一控制的方式實(shí)現(xiàn)這一功能，否則將有可能導(dǎo)致部分接收端并未按照用戶的意愿執(zhí)行相應(yīng)的操作，這在實(shí)際應(yīng)用中是不能被接受的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 ?逐一單播方案

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

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

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

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

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

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

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

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

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

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

（3）操作過程繁瑣。

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

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

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

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

3.2.2 ?發(fā)送過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.5 ?發(fā)送連貫性

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

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

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

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

3.3 ?特殊狀況處理

3.3.1 ?結(jié)點(diǎn)睡眠

當(dāng)接收端結(jié)點(diǎn)即將處于睡眠模式時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

當(dāng)接收端結(jié)點(diǎn)即將關(guān)機(jī)（供電不足或人工關(guān)機(jī)）時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

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

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

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

5 ?結(jié) ?語

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

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

參考文獻(xiàn)

[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é)點(diǎn)睡眠

當(dāng)接收端結(jié)點(diǎn)即將處于睡眠模式時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

當(dāng)接收端結(jié)點(diǎn)即將關(guān)機(jī)（供電不足或人工關(guān)機(jī)）時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

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

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

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

5 ?結(jié) ?語

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

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

參考文獻(xiàn)

[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é)點(diǎn)睡眠

當(dāng)接收端結(jié)點(diǎn)即將處于睡眠模式時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

當(dāng)接收端結(jié)點(diǎn)即將關(guān)機(jī)（供電不足或人工關(guān)機(jī)）時(shí)，需要進(jìn)行以下幾個(gè)步驟的操作：

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

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

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

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

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

5 ?結(jié) ?語

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

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

參考文獻(xiàn)

[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