張笑非，劉 鎮(zhèn) ，滕 瑋

（1.江蘇科技大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 鎮(zhèn)江 212003；2. 北京工業(yè)大學(xué) 信息學(xué)部，北京 100124 ）

基于CoAP的M2M課程教學(xué)及實(shí)驗(yàn)設(shè)計(jì)

張笑非1,2，劉 鎮(zhèn)1，滕 瑋1

（1.江蘇科技大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 鎮(zhèn)江 212003；2. 北京工業(yè)大學(xué) 信息學(xué)部，北京 100124 ）

闡述以IETF CoAP協(xié)議擴(kuò)展標(biāo)準(zhǔn)RFC 7959 “CoAP塊級(jí)傳輸”中的案例作為M2M課程教學(xué)內(nèi)容，提出通過(guò)Eclipse開(kāi)源項(xiàng)目Californium中提供的API對(duì)實(shí)驗(yàn)內(nèi)容進(jìn)行設(shè)計(jì)并利用JUnit框架設(shè)計(jì)CoAP塊級(jí)傳輸案例的測(cè)試用例，測(cè)試結(jié)果驗(yàn)證了相應(yīng)的塊級(jí)傳輸流程。

CoAP; 塊級(jí)傳輸；請(qǐng)求/應(yīng)答對(duì)；Californium項(xiàng)目

0 引 言

當(dāng)前，全國(guó)眾多高校的物聯(lián)網(wǎng)專業(yè)都開(kāi)設(shè)了M2M通信技術(shù)課程，由于涉及的理論和技術(shù)框架還在發(fā)展中，教學(xué)及實(shí)驗(yàn)內(nèi)容也在不斷建設(shè)和完善中。CoAP是一種應(yīng)用于受限節(jié)點(diǎn)和受限網(wǎng)絡(luò)的Web傳輸協(xié)議，類似HTTP但又不是盲目地在HTTP的技術(shù)上進(jìn)行縮減，而是針對(duì)M2M應(yīng)用進(jìn)行優(yōu)化，實(shí)現(xiàn)REST架構(gòu)風(fēng)格的一個(gè)子集[1]。在物聯(lián)網(wǎng)應(yīng)用中，CoAP成為HTTP的替代者而實(shí)現(xiàn)智能硬件到Web的接入[2]。CoAP的標(biāo)準(zhǔn)已在IETF RFC 7252中給出，文獻(xiàn)[3]提出將RFC標(biāo)準(zhǔn)文檔應(yīng)用于計(jì)算機(jī)網(wǎng)絡(luò)教學(xué)中。MIT、Apache等機(jī)構(gòu)也都給出了多種編程語(yǔ)言版本的CoAP實(shí)現(xiàn)，且文獻(xiàn)[4-6]也提出網(wǎng)絡(luò)編程在提高教學(xué)和實(shí)驗(yàn)效果方面的作用，文獻(xiàn)[7]分別就案例分解和重構(gòu)在網(wǎng)絡(luò)編程教學(xué)中的應(yīng)用與改革進(jìn)行了說(shuō)明。這些都為在物聯(lián)網(wǎng)專業(yè)的M2M通信技術(shù)課程中準(zhǔn)備了充足的教學(xué)和實(shí)驗(yàn)素材。

1 CoAP教學(xué)設(shè)計(jì)

本教學(xué)設(shè)計(jì)使用IETF RFC 7959[8]作為M2M通信技術(shù)課程中CoAP的教學(xué)內(nèi)容。RFC 7959是對(duì)RFC 7252的更新，是對(duì)CoAP塊級(jí)傳輸方式的定義。CoAP消息的基本傳輸方式是在客戶端和服務(wù)端之間，通過(guò)一次請(qǐng)求/應(yīng)答對(duì)完成，可以滿足從傳感器讀取數(shù)據(jù)，或向執(zhí)行器發(fā)送指令等小型載荷需求，但面對(duì)固件更新這種需要承載大型載荷的M2M應(yīng)用時(shí)，就需要對(duì)這些載荷進(jìn)行分割。由于CoAP使用的傳輸層協(xié)議是UDP或DTLS，因此不能像TCP對(duì)HTTP消息一樣進(jìn)行分割和重新排列。RFC 7959在不考慮使用IP碎片機(jī)制的情況下，通過(guò)對(duì)CoAP協(xié)議增加一對(duì)Block選項(xiàng)的方式，對(duì)單個(gè)大型載荷進(jìn)行分塊、并通過(guò)多次請(qǐng)求/應(yīng)答對(duì)完成傳輸。

教學(xué)設(shè)計(jì)中之所以選擇RFC 7959定義的CoAP塊級(jí)傳輸作為教學(xué)內(nèi)容，是因?yàn)閷?duì)于協(xié)議三要素（語(yǔ)法、語(yǔ)義、時(shí)序）而言，RFC 7252中介紹的單次請(qǐng)求/應(yīng)答對(duì)作為時(shí)序部分較為簡(jiǎn)單。而基于塊級(jí)傳輸?shù)亩啻握?qǐng)求/應(yīng)答過(guò)程，能夠幫助學(xué)生更好地理解CoAP消息在客戶端/服務(wù)端之間的交換過(guò)程；同時(shí)也可以對(duì)比受限網(wǎng)絡(luò)環(huán)境和常規(guī)互聯(lián)網(wǎng)環(huán)境下，由于需求差異導(dǎo)致協(xié)議棧的每一層功能和策略存在的差別。

1.1 教學(xué)內(nèi)容

CoAP塊級(jí)傳輸中需要利用塊選項(xiàng)（Block Option），塊選項(xiàng)分為Block1和Block2。CoAP中的請(qǐng)求/應(yīng)答對(duì)，其中請(qǐng)求消息由客戶端發(fā)送給服務(wù)端，應(yīng)答消息由服務(wù)端返還給客戶端。若需進(jìn)行分塊的載荷來(lái)自客戶端，如PUT和POST操作，則塊選項(xiàng)為Block1。若需進(jìn)行分塊的載荷來(lái)自服務(wù)端，如接收到GET操作，則塊選項(xiàng)為Block2。塊選項(xiàng)是變長(zhǎng)的，可以是1個(gè)或2個(gè)或3個(gè)字節(jié)。塊選項(xiàng)包含3個(gè)字段，即NUM、M和SZX，其中NUM的長(zhǎng)度可以是4bit或12bit或20bit，是當(dāng)前塊在所屬載荷分割出的多個(gè)塊中的序列號(hào)；M占1bit，1表示還有后續(xù)塊，0表示本塊是最后一個(gè)；SZX占3bit，是當(dāng)前塊尺寸的指數(shù)，2^(SZX+4)就是當(dāng)前塊的字節(jié)數(shù)。為了便于講解，后面的例子中會(huì)將塊選項(xiàng)寫(xiě)成4個(gè)部分，即“塊選項(xiàng)類型:NUM/M/2**(SZX+4)”，例如：2:2/0/32表示一個(gè)Block2塊選項(xiàng)，塊序號(hào)為2、沒(méi)有后續(xù)塊、當(dāng)前塊的長(zhǎng)度是32字節(jié)；1:3/1/128表示一個(gè)Block1塊選項(xiàng)，塊序號(hào)為3，還有后續(xù)塊，當(dāng)前塊的長(zhǎng)度是128字節(jié)。

1.2 教學(xué)案例

RFC 7959的第3節(jié)給出4類案例，每類案例中包含若干具體案例，見(jiàn)表1。這些案例涵蓋了塊級(jí)GET、塊級(jí)PUT/POST的消息交換過(guò)程，其中塊級(jí)PUT與塊級(jí)POST的消息交換過(guò)程是一樣的，它們的區(qū)別在于對(duì)原子性和冪等性上的要求不一樣。這些案例演示了基本的塊級(jí)轉(zhuǎn)發(fā)流程、存在重傳的塊級(jí)轉(zhuǎn)發(fā)流程，存在塊尺寸協(xié)商的塊級(jí)轉(zhuǎn)發(fā)流程。

表1 CoAP塊級(jí)傳輸案例

1.2.1 簡(jiǎn)單塊級(jí)GET案例

如圖1，該案例給出一個(gè)GET請(qǐng)求被分解為三次請(qǐng)求/應(yīng)答對(duì)，客戶端在第一次向服務(wù)端發(fā)起CoAP GET消息時(shí)，并不知道服務(wù)端將要返回的載荷大小。服務(wù)端在第一次應(yīng)答中建議的塊尺寸是128字節(jié)，并且M標(biāo)志位為1，說(shuō)明還有后續(xù)的塊。于是客戶端繼續(xù)向服務(wù)端發(fā)送GET請(qǐng)求，直到接收到的來(lái)自服務(wù)端的第3個(gè)應(yīng)答時(shí)，由于M標(biāo)志位為0，說(shuō)明整個(gè)載荷接收完畢。本案例中由于來(lái)自服務(wù)端的載荷被分割成3個(gè)塊，所以塊選項(xiàng)類型是Block2，3個(gè)塊的NUM依次為0、1、2，每個(gè)塊的尺寸都是128字節(jié)，而實(shí)際情況中，第3個(gè)塊的長(zhǎng)度只需滿足不小于1個(gè)字節(jié)、且不大于128字節(jié)。

圖1 簡(jiǎn)單塊級(jí)GET的消息交換過(guò)程

1.2.2 存在CON消息丟失的后期協(xié)商塊級(jí)GET案例

如圖2，教學(xué)設(shè)計(jì)中利用該案例闡述了CoAP塊級(jí)傳輸中的兩個(gè)要素，一個(gè)是塊尺寸的后期協(xié)商，另一個(gè)是重傳機(jī)制。案例中CoAP消息過(guò)程包含5個(gè)請(qǐng)求/應(yīng)答對(duì)，這可以通過(guò)MID的值或塊選項(xiàng)字段NUM看出。MID是CoAP首部中的消息標(biāo)示符，該例中MID從1234到1238共5個(gè)；同樣，NUM字段在5次請(qǐng)求/應(yīng)答對(duì)中分別是0、2、3、4、5共5個(gè)，而沒(méi)有1，這正是后期協(xié)商造成的。

圖2 存在CON消息丟失的后期協(xié)商塊級(jí)GET的消息交換過(guò)程

客戶端和服務(wù)端可以在消息交換中的多次修改塊尺寸，提供類似TCP的擁塞控制功能[9]。在教學(xué)設(shè)計(jì)中，首先要講解什么是早期協(xié)商，即在第一次請(qǐng)求/應(yīng)答對(duì)的請(qǐng)求消息中，如果塊選項(xiàng)的SZX被設(shè)置了值，那這個(gè)值就是客戶端期望服務(wù)端在后續(xù)應(yīng)答時(shí)設(shè)置的塊尺寸指數(shù)，反之則說(shuō)明客戶端沒(méi)有進(jìn)行早期協(xié)商。第一次請(qǐng)求/應(yīng)答對(duì)中的應(yīng)答消息到達(dá)客戶端后，客戶端對(duì)服務(wù)端設(shè)置的塊尺寸128字節(jié)并不滿意，因此在第二次的請(qǐng)求/應(yīng)答對(duì)的請(qǐng)求消息將塊尺寸設(shè)置為64字節(jié)。由于第一次應(yīng)答，服務(wù)端已經(jīng)返回了128字節(jié)，而這時(shí)客戶端設(shè)置的塊尺寸為64字節(jié)，因此相當(dāng)于之前已經(jīng)發(fā)送了兩個(gè)64字節(jié)的塊，第二次應(yīng)答消息中的塊相當(dāng)于是第3個(gè)64字節(jié)了，這就是為什么轉(zhuǎn)發(fā)過(guò)程中沒(méi)有出現(xiàn)NUM為1的情況。

其次，在這個(gè)案例中，還需要對(duì)CoAP的重傳機(jī)制作講解。CoAP請(qǐng)求/應(yīng)答對(duì)的可靠性是通過(guò)設(shè)置請(qǐng)求消息中的Type字段為“需確認(rèn)”、即CON，客戶端會(huì)通過(guò)計(jì)時(shí)器判斷在規(guī)定時(shí)間內(nèi)是否收到與請(qǐng)求消息MID相同的應(yīng)答消息，否則會(huì)重新發(fā)送同樣的請(qǐng)求消息。該案例中模擬了第二次請(qǐng)求/應(yīng)答對(duì)的請(qǐng)求消息丟失的情況，若是應(yīng)答消息丟失則仍由客戶端重新發(fā)送請(qǐng)求，服務(wù)端并不設(shè)置超時(shí)機(jī)制。

1.2.3 原子性塊級(jí)POST/塊級(jí)應(yīng)答組合案例

如圖3，教學(xué)設(shè)計(jì)中利用該案例闡述了CoAP塊級(jí)傳輸中的兩個(gè)要素，一個(gè)是原子性塊級(jí)傳輸，另一個(gè)是Block1和Block2塊選項(xiàng)的組合。整個(gè)CoAP消息過(guò)程包含6個(gè)請(qǐng)求/應(yīng)答對(duì)，即該例中MID從1234到1239；過(guò)程的前半部分是客戶端通過(guò)Block1塊選項(xiàng)把發(fā)送給服務(wù)端的數(shù)據(jù)分成了3個(gè)塊依次傳輸，過(guò)程的后半部分是服務(wù)端通過(guò)Block2塊選項(xiàng)把返回給客戶端的結(jié)果分成了4個(gè)塊依次傳輸。由于在第3次請(qǐng)求/應(yīng)答對(duì)中通過(guò)雙工的方式同時(shí)完成了最后一個(gè)Block1塊和第一個(gè)Block2塊，所以雙方交換7個(gè)塊通過(guò)6次請(qǐng)求/應(yīng)答對(duì)便完成了。

圖3 原子性塊級(jí)POST/塊級(jí)應(yīng)答組合的消息交換過(guò)程

在教學(xué)設(shè)計(jì)中，首先要講解原子性塊級(jí)傳輸?shù)臋C(jī)制，與之相對(duì)的是無(wú)狀態(tài)塊級(jí)傳輸。它們的區(qū)別在于在服務(wù)端通過(guò)應(yīng)答消息的M字段，以表示塊級(jí)傳輸過(guò)程中的所有請(qǐng)求/應(yīng)答對(duì)構(gòu)成一個(gè)原子性操作，還是說(shuō)每個(gè)請(qǐng)求/應(yīng)答對(duì)構(gòu)成獨(dú)立的操作。從本案例塊級(jí)傳輸?shù)拿恳淮螒?yīng)答消息可以看到，除了最后一次應(yīng)答消息，之前應(yīng)答消息的M字段均為1，說(shuō)明服務(wù)端預(yù)期來(lái)自客戶端更多的請(qǐng)求消息，直到最后一次應(yīng)答消息M字段為0，表示服務(wù)端認(rèn)為之前接收到的所有請(qǐng)求/應(yīng)答對(duì)成了一次原子性的塊級(jí)傳輸過(guò)程。而在無(wú)狀態(tài)塊級(jí)傳輸中，即使客戶端發(fā)送的請(qǐng)求消息中通過(guò)M字段置1、以告知服務(wù)端本次請(qǐng)求/應(yīng)答對(duì)后還有更多的請(qǐng)求/應(yīng)答對(duì)，但服務(wù)端每次向客戶端發(fā)送的應(yīng)答消息的M字段都為0，以表示服務(wù)端可以獨(dú)立處理這些被分割的塊，每一個(gè)請(qǐng)求/應(yīng)答對(duì)是獨(dú)立的。

其次，在這個(gè)案例中，還需要對(duì)CoAP的Block1和Block2塊選項(xiàng)組合機(jī)制作講解。整個(gè)塊級(jí)傳輸過(guò)程共包含6次請(qǐng)求/應(yīng)答對(duì)，其中第3次請(qǐng)求/應(yīng)答對(duì)的應(yīng)答消息中同時(shí)包含了Block1和Block2塊選項(xiàng)。這是因?yàn)榭蛻舳送ㄟ^(guò)前三次請(qǐng)求將輸入數(shù)據(jù)提交給了服務(wù)端，而服務(wù)端則在第三次應(yīng)答中通過(guò)Block1塊選項(xiàng)M字段為0表示數(shù)據(jù)接收完成、同時(shí)還通過(guò)Block2塊選項(xiàng)開(kāi)始向客戶端返回結(jié)果，直到第6次應(yīng)答通過(guò)Block2塊選項(xiàng)M字段置0告知客戶端結(jié)果返回完畢。

2 CoAP實(shí)驗(yàn)設(shè)計(jì)

本實(shí)驗(yàn)設(shè)計(jì)使用Eclipse開(kāi)源項(xiàng)目Californium[10]作為CoAP的實(shí)驗(yàn)環(huán)境。Californium是一個(gè)面向后臺(tái)服務(wù)和強(qiáng)勁IoT設(shè)備的CoAP框架，其為RESTful Web服務(wù)提供的API支持CoAP的所有特性。實(shí)驗(yàn)設(shè)計(jì)在Californium中將每個(gè)案例編寫(xiě)成JUnit測(cè)試單元來(lái)驗(yàn)證，文獻(xiàn)[11]就如何將JUnit應(yīng)用到課程教學(xué)中做了探討。

2.1 案例的測(cè)試框架設(shè)計(jì)

由于每一個(gè)CoAP案例的測(cè)試設(shè)計(jì)都包含通用模塊和獨(dú)立模塊，因此在設(shè)計(jì)上利用JUnit4的標(biāo)注機(jī)制。如圖4所示，用@BeforeClass定義CoAP網(wǎng)絡(luò)參數(shù)初始化函數(shù)init( )，用@Before定義CoAP客戶端實(shí)例和服務(wù)端實(shí)例的創(chuàng)建函數(shù)setupEndpoints( )，用@After定義CoAP客戶端實(shí)例和服務(wù)端實(shí)例的銷毀函數(shù)shutdownEndpoints( )，用@Test分別定義三個(gè)塊級(jí)傳輸過(guò)程函數(shù)testGET()、testGETLateNegotionalLostACK()、testAtomicBlo ckwisePOSTWithBlockwiseResponse()。

圖4 實(shí)驗(yàn)測(cè)試流程

2.2 測(cè)試的通用模塊設(shè)計(jì)

鎖步（Lockstep）也稱為時(shí)鐘同步，是一種容錯(cuò)技術(shù)[12]。為了能夠重現(xiàn)教學(xué)案例中的場(chǎng)景，我們將服務(wù)端運(yùn)行在正常模式，而將客戶端運(yùn)行在鎖步模式，即客戶端每次發(fā)送和等待接收，都是通過(guò)明確的命令來(lái)控制。因此，首先定義測(cè)試用例的靜態(tài)初始化函數(shù)init( )，在其中為CoAP服務(wù)端定義運(yùn)行時(shí)的網(wǎng)絡(luò)參數(shù)：

接著就需要定義每次Test實(shí)例的初始化函數(shù)setupEndpoints( )，其中需要?jiǎng)?chuàng)建并啟動(dòng)運(yùn)行在正常模式的CoAP服務(wù)端實(shí)例，以及運(yùn)行在鎖步模式的CoAP客戶端實(shí)例：

最后定義每次Test實(shí)例運(yùn)行完畢時(shí)執(zhí)行的銷毀函數(shù)shutdownEndpoints( )：

2.3 測(cè)試的獨(dú)立模塊設(shè)計(jì)

教學(xué)設(shè)計(jì)中的3個(gè)案例，可以通過(guò)CoAP客戶端的鎖步模式完成相應(yīng)的塊級(jí)傳輸流程。其中，客戶端client通過(guò)函數(shù)sendRequest完成請(qǐng)求消息的發(fā)送、通過(guò)函數(shù)expectResponse確認(rèn)應(yīng)答消息的接收。以案例3為例，為了完成圖3中的塊級(jí)傳輸流程，先通過(guò)函數(shù)generateRandomPayload為CoAP兩端生成指定長(zhǎng)度的隨機(jī)載荷；另外，CoAP客戶端需要指定token作為區(qū)分并發(fā)請(qǐng)求消息的標(biāo)識(shí)符，以及path作為POST請(qǐng)求創(chuàng)建資源的路徑。

案例3中的6次請(qǐng)求/應(yīng)答對(duì)，每一次請(qǐng)求/應(yīng)答對(duì)在CoAP客戶端鎖步模式下、通過(guò)執(zhí)行一對(duì)sendRequest和expectResponse函數(shù)來(lái)完成測(cè)試。

2.4 測(cè)試結(jié)果

將通用模塊和案例3獨(dú)立模塊的組合作為JUnit單元測(cè)試，圖5中的運(yùn)行結(jié)果正確驗(yàn)證了案例3在教學(xué)設(shè)計(jì)上的塊級(jí)傳輸流程。

圖5 案例3的JUnit單元測(cè)試結(jié)果

3 結(jié) 語(yǔ)

該設(shè)計(jì)方法可以被用到M2M課程其他知識(shí)點(diǎn)，或者其他課程的教學(xué)和實(shí)驗(yàn)設(shè)計(jì)當(dāng)中去，特別是目前一些涉及新技術(shù)的物聯(lián)網(wǎng)專業(yè)課程，在實(shí)際的教學(xué)過(guò)程中讓學(xué)生掌握先進(jìn)技術(shù)的原理和開(kāi)發(fā)方法，以提高他們的專業(yè)素質(zhì)和能力。

[1] Shelby K S, Hartke C B.The Constrained Application Protocol (CoAP), IETF RFC 7252, June 2014[EB/OL]. [2017-06-16].https://tools.ietf.org/pdf/rfc7252.pdf.

[2] Lev? T, Mazhelis O, Suomi H. Comparing the cost-efficiency of CoAP and HTTP in Web of Things applications[J]. Decision Support Systems, 2014, 63(3): 23-38.

[3] 王盛邦, 田海博. RFC在網(wǎng)絡(luò)協(xié)議教學(xué)中的應(yīng)用[J]. 現(xiàn)代計(jì)算機(jī)(專業(yè)版), 2013(23): 35-39.

[4] 張曉明, 杜天蒼, 秦彩云. 計(jì)算機(jī)網(wǎng)絡(luò)編程課程的教學(xué)改革與實(shí)踐[J]. 實(shí)驗(yàn)技術(shù)與管理, 2010(2): 4-7.

[5] 胡靜, 趙雷, 羅宜元, 等. 網(wǎng)絡(luò)工程專業(yè)的網(wǎng)絡(luò)編程課程教學(xué)與改革[J]. 計(jì)算機(jī)教育, 2014(18): 35-38.

[6] 戚平, 石樂(lè)義. 原始套接字編程在網(wǎng)絡(luò)實(shí)驗(yàn)教學(xué)中的應(yīng)用[J]. 實(shí)驗(yàn)室研究與探索, 2012(7): 325-327.

[7] 吳杰, 梁妍. 基于實(shí)驗(yàn)案例分解和重構(gòu)的Android網(wǎng)絡(luò)編程教學(xué)改革探索[J]. 信息技術(shù)與信息化, 2016(5): 103-110.

[8] Borman C. Shelby Z.Block-Wise Transfers in the Constrained Application Protocol (CoAP), IETF RFC 7959, August 2016[EB/OL].[2017-06-16]. https://tools.ietf.org/pdf/rfc7959.pdf.

[9] Castellani A P, Rossi M, Zorzi M. Back pressure congestion control for CoAP/6LoWPAN networks[J]. Ad Hoc Networks, 2014,18(1):71-84.

[10] Kovatsch M, Lanter M, Shelby Z. Californium: Scalable cloud services for the Internet of Things with CoAP[C]// Internet of Things. IEEE, 2014: 1-6.

[11] 朱冬玲. JUnit在軟件測(cè)試課程教學(xué)中的應(yīng)用[J]. 福建電腦, 2013(10): 56-57.

[12] 付愛(ài)英,周晶晶. 基于Lockstep的容錯(cuò)技術(shù)的研究[J]. 科技廣場(chǎng), 2012(7): 70-73.

1672-5913(2017)11-0150-05

G642

江蘇科技大學(xué)2016高教研究立項(xiàng)課題（GJKTY201625）；江蘇省教育科學(xué)“十二五”規(guī)劃2015年度立項(xiàng)課題（D/2015/01/78）；江蘇科技大學(xué)2015年學(xué)校重點(diǎn)教改課題“計(jì)算機(jī)類專業(yè)通用課程優(yōu)質(zhì)教學(xué)資源建設(shè)的研究與實(shí)踐”。

張笑非，男，講師，研究方向?yàn)橥ㄐ偶夹g(shù)研究與教學(xué)工作，julychang@just.edu.cn。

（編輯：郭田珍）