張笑非 段先華 王長寶 王艷

摘要：CoAP是M2M的核心技術(shù)之一，其觀察者模式是一種軟件設(shè)計模式。IETF RFC 7641定義的CoAP資源觀察機制正是基于該模式，是CoAP教學和實驗內(nèi)容的重要組成部分。將CoAP中資源觀察消息的傳遞過程與通知的傳輸控制、時效性模型結(jié)合進行課程教學內(nèi)容設(shè)計，通過Eclipse開源項目Californium中提供的API設(shè)計相應(yīng)實驗，并利用JUnit框架設(shè)計CoAP資源觀察的測試用例，測試結(jié)果驗證了相應(yīng)資源觀察過程。將該設(shè)計運用到實際教學活動中，學生對CoAP的內(nèi)涵理解及編程能力都有提高。

關(guān)鍵詞：觀察者模式;資源觀察通知;傳輸控制;時效性模型;受限節(jié)點/網(wǎng)絡(luò)

DOI：10.11907/rjdk.191316

中圖分類號：G434 文獻標識碼：A 文章編號：1672-7800（2019）012-0199-05

0引言

CoAP是一種應(yīng)用于受限節(jié)點，網(wǎng)絡(luò)的應(yīng)用層傳輸協(xié)議…，是物聯(lián)網(wǎng)等相關(guān)專業(yè)教學的重要內(nèi)容。RFC 7641中定義的CoAP資源觀察機制就是基于觀察者模式，該模式是GoF提出的23種軟件設(shè)計模型之一，被稱為觀察者（Observer）的組件向其感興趣的、稱為被察者（subjeet）的服務(wù)端進行注冊。此后，被察者狀態(tài)變化信息都會主動通知在冊的觀察者。觀察者模式作為一種設(shè)計模型，涉及軟件、物聯(lián)網(wǎng)、通信等領(lǐng)域應(yīng)用，文獻[4]提出了基于并行的觀察者改進模式，以滿足實時系統(tǒng)中大量數(shù)據(jù)的更新;文獻[5]提出了基于觀察者的動態(tài)演化模型，以提高軟件系統(tǒng)的動態(tài)演化效率;文獻[6]提出了基于觀察者模式的復雜實時系統(tǒng)驗證方法;文獻[7]采用了觀察者模式對氣象衛(wèi)星數(shù)據(jù)接收與預處理調(diào)度機制進行研究;文獻[8]將該模式應(yīng)用于電信管理網(wǎng)絡(luò);文獻[9]通過對觀察者模式改進并應(yīng)用到分布式開發(fā)中;文獻[10]給出了在Observer模式中應(yīng)用c#中的委托方法;文獻[11]一[12]將該模式應(yīng)用于軟件設(shè)計;文獻[13]利用CoAP對已存在的軟件架構(gòu)進行改進。同樣，研究如何將CoAP及觀察者模式應(yīng)用到物聯(lián)網(wǎng)環(huán)境，以及研究觀察者模式在CoAP課程中的教學和實驗設(shè)計，對于提高學生實際應(yīng)用觀察者模式能力有重要意義。

1COAP教學設(shè)計

本文利用文獻[14]-[15]中基于RFC文檔進行教學的設(shè)計思路，以RFC 7641中的CoAP資源觀察機制為基礎(chǔ)，講解受限節(jié)點/網(wǎng)絡(luò)環(huán)境中CoAP資源觀察通知的傳輸方法與時效性模型?；谶@兩個機制設(shè)計教學案例，幫助學生理解在受限節(jié)點，網(wǎng)絡(luò)環(huán)境和常規(guī)互聯(lián)網(wǎng)環(huán)境下，由于需求差異導致CoAP/UDP與HTTPfFCP在消息傳遞及傳輸控制上的區(qū)別。

1.1教學內(nèi)容設(shè)計

1.1.1資源觀察通知傳輸方法

CoAP資源觀察關(guān)系建立后，資源更新通知主要依靠扮演被察者的CoAP服務(wù)端進行傳輸控制。傳輸控制包含兩個主要要素：①消息傳輸?shù)目煽繖C制，包括需確認（cON，confirmable）或免確認（NON，non-confirmable）傳輸;②消息傳輸?shù)目刂茩C制，包括停止等待（stop-and-wait）或?qū)崟r方式。如表l所示，這兩個要素可以組合出3種資源觀察通知傳輸方法，其中免確認的CoAP消息與停止等待方式無法結(jié)合。

若關(guān)注被察者與觀察者對于某資源狀態(tài)的同步效率，則實時方式通知更加適合。圖l中示例需確認實時資源觀察通知，被察資源（interested resource）第二次發(fā)生變化時，將該變化observe（2）以MID（消息標識符）為3100的確認消息發(fā)送給觀察者。在未收到相應(yīng)的ACK消息時，被察資源發(fā)生第3次變化observe（3），于是就直接將該變化再次發(fā)送出去。由于需確認消息在未收到相應(yīng)ACK消息時其MID不會增加，所以攜帶observe（2）與observe（3）的消息MID是一樣的。實時方式下需確認通知與免確認通知區(qū)別在于，前者中的被察者會收到重復的ACK消息。

類似地，圖2中示例的免確認實時資源觀察通知，被觀察者資源第二次發(fā)生變化時，將該變化observe（2）以MID為3100免確認消息發(fā)送給觀察者。被察資源發(fā)生了第三次變化observe（3）時，也直接將該變化再次發(fā)送出去，并沒有考慮頻繁的通知可能會造成受限網(wǎng)絡(luò)的擁塞。另外，由于是免確認方式，所以兩次消息的MID產(chǎn)生了變化。

突發(fā)性資源狀態(tài)變化會產(chǎn)生過多通知，這對于受限網(wǎng)絡(luò)的承載能力和受限節(jié)點處理能力都是極大挑戰(zhàn)。圖3中的示例需確認資源觀察通知，被察者在MID為3100的消息中將資源變化observe（2）通知給觀察者，雖然之后資源狀態(tài)經(jīng)歷了observe（3）、observe（4）、observe（5）的變化，但未直接生成相應(yīng)通知。直到接收到相應(yīng)的ACK消息后，被察者才將最新的狀態(tài)observe（5）通過MID為3101的需確認消息通知給觀察者。由于承載observe（2）的需確認消息已經(jīng)被確認，所以承載observe（5）的需確認消息的MID數(shù)值增加了1。

1.1.2資源觀察通知時效性模型

通過表1可知，免確認的消息只能與實時方式結(jié)合，當被察資源異常頻變時，必然不適合受限結(jié)點，網(wǎng)絡(luò)場景。教學設(shè)計中針對這一問題在RFC 7641中對資源觀察通知的時效性模型進行設(shè)計。時效性模型一方面會省略被察資源的一些中間狀態(tài)，但又不會導致兩端信息同步收斂過于緩慢，時效性模型只能滿足最終一致性（eventual con-sistency），即被察者狀態(tài)穩(wěn)定時，觀察者終究會獲得這個最新的狀態(tài)信息。

時效性模型充分考慮到受限節(jié)點，網(wǎng)絡(luò)限制。為保證資源觀察兩端信息同步效率可接受，引人Max-Age（資源狀態(tài)時效期）這一參數(shù)，即被察者相鄰兩次通知的發(fā)送時間間隔不能超過Max-Age。如圖4所示，發(fā)送完MID為3100的通知后Max-Age便開始計時。在未過期前發(fā)送了MID為3101的通知，中間的資源狀態(tài)變化3和4都被跳過，即使這個期間被察資源沒有發(fā)生任何變化，被察者也會在Max-Age超時前發(fā)送一次攜帶observe（2）的通知，告知觀察者被察資源狀態(tài)無變化。時效性模型同樣可以傳輸需確認的消息，以及結(jié)合實時通知傳輸。

1.2教學案例設(shè)計

1.2.1簡單資源觀察過程

CoAP資源觀察中的觀察者，首先會通過一個攜帶ob-serve選項的GET消息與被察者建立資源觀察關(guān)系。由于該請求消息是GET操作，所以被察者會先返回一個ob-serve（0）作為對GET操作的返回結(jié)果，后續(xù)狀態(tài)變化通知會通過observe（i），i=1，2，3，…返回。

圖5是CoAP觀察者向被察者發(fā)起一個MID為7001的免確認GET操作，對資源/obs進行觀察。被察者一方面基于token等參數(shù)將該觀察者加入注冊列表，另一方面要對GET操作進行處理，于是向觀察者返回了一個MID為3098的免確認消息，消息中攜帶資源/obs的當前信息ob-serve（0）。觀察者在接收到該消息后，一方面獲得了當前被察者資源lobs的狀態(tài)，同時也確認了與被察者觀察關(guān)系的建立。之后，被察者資源/obs發(fā)生3次變化，即observe（1）、observe（2）和observe（3），并被封裝成獨立的CoAP消息，即MID分別以3099、3100、3101的通知返還給觀察者。其中MID為3100的消息需確認，目的是被察者測試一下與觀察者的連通性，若不連通則需要將該觀察者從注冊列表里刪除，以撤銷相應(yīng)的觀察關(guān)系。最后，觀察者通過向被察者發(fā)送一個RST，即復位消息用來撤銷觀察關(guān)系，被察者在收到該消息后，會根據(jù)token等參數(shù)將該觀察者從其注冊列表中刪除。

1.2.2多因素驅(qū)動通知生成

被察者何時生成新的通知并向觀察者發(fā)送有多種驅(qū)動因素。就目前RFC 7252和RFC 7641中的機制，這些因素包括GET操作、ACK確認、ACK超時（ACK_TIMEOUT）、Max-Age、資源狀態(tài)更新等5種。圖5的案例包含了GET操作、ACK確認及資源狀態(tài)更新這3種因素。為了包含ACK_TIMEOUT因素，通過丟棄所有需確認的通知而導致相應(yīng)消息在ACK_TIMEOUT規(guī)定的時間內(nèi)沒有被確認而重新發(fā)送。除此以外，該案例設(shè)計還考慮了時效性模型中的Max-Age，介紹如何觸發(fā)通知的生成與發(fā)送。

如圖6所示，被察者一共生成并發(fā)送6次狀態(tài)信息。其中通知observe（0）是由GET操作觸發(fā)的，observe（1）、ob-serve（2）、observe（3）的第一次是由資源狀態(tài)變化觸發(fā)的，observe（1）和observe（3）的第二次是由ACK_TIMEOUT觸發(fā)的。這個案例的一個設(shè)計重點在于區(qū)分同屬超時機制的ACK_TIMEOUT和Max-Age究竟哪一個在發(fā)揮作用。注意MID為39551的通知都是需確認的，如果是免確認的就不會出現(xiàn)ACK_TIMEOUT觸發(fā)的情況。

RFC 7252中需確認消息的超時機制使用二進制指數(shù)退避算法，參數(shù)ACK_TIMEOUT缺省是2秒、ACK_RAN-DOM_FACTOR缺省是1.5、MAX_RETRANSMIT缺省是4次，即每兩次重傳之間的時間間隙分別是3、6、12、24秒。同一個MID需確認的消息從第一次嘗試發(fā)送到最后一次嘗試發(fā)送的間隔稱為MAX_TRANSMIT_SPAN，缺省值為45秒。而RFC 7641中時效性模型定義的Max-Age缺省值是60秒。因此，Max-Age還未觸發(fā)時，該消息重傳次數(shù)就已經(jīng)達到最大次數(shù)?？紤]到案例中MID為3955l的通知有兩次是狀態(tài)更新觸發(fā)的，因此MAX_TRANSMIT_SPAN的實際值小于45秒。被察者唯一通過Max-Age觸發(fā)通知的可能就是MAX_TRANSMIT_WAIT不小于60秒，否則被察者就會將觀察者從注冊列表中刪除。

Max-Age不僅可在被察者端觸發(fā)通知的生成，也可在觀察者端觸發(fā)GET操作，間接向被察者查詢資源狀態(tài)。圖6中，觀察者在接收到MID為7001的通知時，其中的ob-serve選項可以攜帶被察者設(shè)置的Max-Age值，以告知資源時效性的最大間隔。也就是說，觀察者在此刻開始的Max-Age時間間隔內(nèi)，認為observe（0）是具有時效性的。若超過這個時間間隔，說明observe（0）已經(jīng)無效，考慮到受限網(wǎng)絡(luò)可能存在擁塞，可以通過攜帶observe選項的GET操作重新與被察者建立觀察關(guān)系。

2COAP實驗設(shè)計

本文采用Eclipse開源項目Californium E171作為基于觀察者模式的CoAP實驗環(huán)境，該開源項目提供了CoAP所有特性所需的后臺服務(wù)，能夠很好地與IoT設(shè)備進行交互。實驗設(shè)計利用文獻[18]中將JUnit應(yīng)用到課程教學中的方法，通過在Californium中編寫JUnit測試單元測試并驗證每個實驗設(shè)計。

2.1案例測試框架設(shè)計

除了之前設(shè)計的兩個教學案例，CoAP教學還設(shè)計了Max-Age動態(tài)調(diào)整的資源觀察過程、資源觀察通知塊級傳輸過程等案例。因此，為了提高測試代碼重用性，在實驗設(shè)計上采用文獻[19]提到的案例分解與重構(gòu)思路，采用JUnit4的標注機制定義案例的通用模塊和獨立模塊。如圖7所示，用@BeforeClass定義CoAP網(wǎng)絡(luò)參數(shù)初始化函數(shù)start（），用@Before定義CoAP觀察者和被察者的創(chuàng)建函數(shù)setupServer（），用@After定義CoAP觀察者和被察者的銷毀函數(shù)shutdownServer（），用@Test分別定義資源觀察過程函數(shù)simpleResourcesObserving（）、muhipleFactorsDrivenNo-tification（）、observingWithDynamicMaxage（）、observingWith-BlockwiseTransfer（）等。

2.2測試通用模塊設(shè)計

鎖步（Lockstep）是一種容錯技術(shù)，通過顯式指令完成同步控制。實驗設(shè)計將CoAP觀察者和被察者分別運行在鎖步模式和正常模式，利用鎖步模式控制觀察者的每一次消息發(fā)送和接收，從而重現(xiàn)教學案例中設(shè)計的資源觀察過程。因此，首先定義測試用例的靜態(tài)初始化函數(shù)start（），在其中設(shè)定CoAP被察者的網(wǎng)絡(luò)參數(shù)初始值：

2.3測試獨立模塊設(shè)計

實驗設(shè)計中，工作在鎖步模式的client通過函數(shù)send-Request和expectResponse分別完成消息的發(fā)送和接收。此外，測試用例通過函數(shù)testObsResources.change（）實現(xiàn)被察資源/obs的更新，通過函數(shù)serverInterceptor.log（）模擬CoAP消息的丟失。以案例“多因素驅(qū)動的通知生成”為例，為了完成圖6中的資源觀察過程，通過函數(shù)generater-andomPayload為CoAP觀察者生成指定長度的GET操作載荷。另外，CoAP觀察者還要創(chuàng)建token作為在被察者端注冊的主要參數(shù)及path指定被察資源路徑。

2.4測試結(jié)果

將通用模塊和該案例的獨立模塊組合作為JUnit單元測試，圖8中的運行結(jié)果驗證了案例“多因素驅(qū)動的通知生成”在教學設(shè)計上的資源觀察過程。

3結(jié)語

觀察者模式應(yīng)用于物聯(lián)網(wǎng)、通信、軟件等技術(shù)中，基于它進行課程內(nèi)容講解可幫助學生觸類旁通，提高學習效率和再創(chuàng)造能力。本文結(jié)合RFC標準和開源項目，對CoAP課程的教學和實驗內(nèi)容進行設(shè)計，在理論內(nèi)容上緊跟業(yè)界發(fā)展趨勢，在實踐環(huán)節(jié)上具有應(yīng)用價值。這種結(jié)合業(yè)界標準和開源項目進行課程設(shè)計的方法，同樣可以應(yīng)用到相關(guān)專業(yè)其它課程中，對提高課程內(nèi)容的內(nèi)涵和市場接納度具有積極意義。