基于觀察者模式的COAP課程教學與實驗設計

張笑非 段先華 王長寶 王艷

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

關鍵詞：觀察者模式;資源觀察通知;傳輸控制;時效性模型;受限節點/網絡

DOI：10.11907/rjdk.191316

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

0引言

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

1COAP教學設計

本文利用文獻[14]-[15]中基于RFC文檔進行教學的設計思路，以RFC 7641中的CoAP資源觀察機制為基礎，講解受限節點/網絡環境中CoAP資源觀察通知的傳輸方法與時效性模型。基于這兩個機制設計教學案例，幫助學生理解在受限節點，網絡環境和常規互聯網環境下，由于需求差異導致CoAP/UDP與HTTPfFCP在消息傳遞及傳輸控制上的區別。

1.1教學內容設計

1.1.1資源觀察通知傳輸方法

CoAP資源觀察關系建立后，資源更新通知主要依靠扮演被察者的CoAP服務端進行傳輸控制。傳輸控制包含兩個主要要素：①消息傳輸的可靠機制，包括需確認（cON，confirmable）或免確認（NON，non-confirmable）傳輸;②消息傳輸的控制機制，包括停止等待（stop-and-wait）或實時方式。如表l所示，這兩個要素可以組合出3種資源觀察通知傳輸方法，其中免確認的CoAP消息與停止等待方式無法結合。

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

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

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

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

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

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

1.2教學案例設計

1.2.1簡單資源觀察過程

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

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

1.2.2多因素驅動通知生成

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

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

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

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

2COAP實驗設計

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

2.1案例測試框架設計

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

2.2測試通用模塊設計

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

2.3測試獨立模塊設計

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

2.4測試結果

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

3結語

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