無線物聯網中CoAP協議的研究與實現(一)

　　（5）支持資源發現：為了自主的發現和使用資源，它支持內置的資源發現格式，用于發現設備上的資源列表，或者用于設備向服務目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用/.well—known/core的路徑表示資源描述。

　　（6）支持緩存：CoAP協議支持資源描述的緩存以優化其性能。

　　（7）訂閱機制：CoAP使用異步通信方式，用訂閱機制實現從服務器到客戶端的消息推送。實現CoAP的發布，訂閱機制，它是請求成功后自動注冊的一種資源后處理程序。是由默認的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理程序用 EST.notify_subscri bers（）函數來發布。

　　2.1 CoAP協議棧圖3是CoAP協議棧。CoAP協議的傳輸層使用UDP協議。由于UDP傳輸的不可靠性，CoAP協議采用了雙層結構，定義了帶有重傳的事務處理機制，并且提供資源發現和資源描述等功能。CoAP采用盡可能小的載荷，從而限制了分片。

　　事務層（Transaction layer）用于處理節點之間的信息交換，同時提供組播和擁塞控制等功能。請求/響應層（Request/Responselayer）用于傳輸對資源進行操作的請求和響應信息。CoAP協議的REST構架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協議，也可以提供可靠的傳輸機制。利用默認的定時器和指數增長的重傳間隔時間實現CON（Confirmable）消息的重傳，直到接收方發出確認消息。另外，CoAP的雙層處理方式支持異步通信，這是物聯網和M2M應用的關鍵需求之一。

　　2.2 CoAP的訂閱機制HTTP的請求/響應機制是假設事務都是由客戶端發起的，通常叫做拉模型。這導致客戶端不能高效的知統中，設備都是無線低功耗的，這些設備大部分時間是休眠狀態，因此不能響應輪詢請求。而CoRE認為支持本地的推送模型是一個重要的需求，也就是由服務器初始化事務到客戶端。推送模型需要一個訂閱接口，用來請求響應關于特定資源的改變。而由于UDP的傳輸是異步的，所以不需要特殊的通知消息。訂閱機制如圖4所示。

　　2.3 CoAP的交互模型CoAP使用類似于HTTP的請求/響應模型：CoAP終端節點作為客戶端向服務器發送一個或多個請求，服務器端回復客戶端的CoAP 請求。不同于HTTP，CoAP的請求和響應在發送之前不需要事先建立連接，而是通過CoAP信息來進行異步信息交換。CoAP協議使用UDP進行傳輸。這是通過信息層選項的可靠性來實現的。CoAP定義了四種類型的信息：可證實的CON（Confirmable）信息，不可證實的NON（Non- Confirmable）信息，可確認的ACK（Acknowledgement）信息和重置信息RST（Reset）。方法代碼和響應代碼包含在這些信息中，實現請求和響應功能。這四種類型信息對于請求/響應的交互來說是透明的。

　　CoAP的請求/響應語義包含在CoAP信息中，其中分別包含方法代碼和響應代碼。CoAP選項中包含可選的（或默認的）請求和響應信息，例如URI和負載內容類型。令牌選項用于獨立匹配底層的請求到響應信息。

　　請求/響應模型：請求包含在可證實的或不可證實的信息中，如果服務器端是立即可用的，它對請求的應答包含在可證實的確認信息中來進行應答。圖5是基本的 GET請求和響應模式，其中圖5（a）表示成功發送請求和收到ACK確認信息，圖5（b）表示重傳了請求信息，然后才收到ACK確認信息。

　　雖然CoAP協議目前還在制定當中，但Contiki和TinyOS嵌入式操作系統已經支持CoAP協議。Contiki是一個多任務操作系統，并帶有 uIPv6協議棧，適用于嵌入式系統和無線傳感器網絡，它占用系統資源小，適用于資源受限的網絡和設備。目前，火狐瀏覽器已經集成了Copper插件，從而實現了CoAP協議。但是這種方式只能讀取傳感器節點上的實時數據，而不能查看各種歷史數據。為此，在Contiki系統的基礎上，基于 uIPv6START KIT無線網絡開發套件，用自己編寫的客戶端程序實現了和數據庫的交互，把歷史數據