胡浩

【摘 要】DNS服務發(fā)現和COAP的資源發(fā)現是IOT自動配置的重要方法，本文根據幾個性能指標比較分析基于coap和dns的服務發(fā)現協議，這些指標包括協議開銷和發(fā)現功能。

【關鍵詞】服務發(fā)現;資源發(fā)現;協議開銷;發(fā)現功能

1.協議開銷

1.1 coap的協議開銷比較

假設在星型網絡中具有兩個CoAP服務器和一個CoAP客戶端，COAP服務器的服務路徑為/light/5/on，資源類型為rt=philips.light.on，分別比較分布式和集中式CoAP資源發(fā)現機制的協議開銷，對于集中式COAP，因為每個設備都必須獨立的發(fā)現RD并注冊于RD。協議開銷與設備數量成正比。對于具有大量設備的網絡來說，RD發(fā)現過程非常低效，因為相同的RD發(fā)現信息必須獨立地傳輸多次。而RD查找開銷主要與查找響應相關，響應中包括所有注冊設備資源的完整的路徑，例如;rt=philips.light.on，。;rt=philips.light.on，兩個URI中的許多信息是重復的，只有IP地址發(fā)生了改變（從2002：50到2002：51），如果RD能減少這種冗余開銷，則協議開銷會大幅減少。

另一方面，對于COAP分布式發(fā)現，節(jié)點不進行RD發(fā)現和注冊。查找是由不可靠的多播（Mulighticast Lookup）執(zhí)行的。從總體上看，分布式優(yōu)于集中式。此外，分布式查找開銷較低，因為只傳輸資源的路徑而不是完整的URI，例如;RT=“philips.light.on”，IP地址可以從數據包源地址推斷出來。

然而，分布式多播使用了一個ttl值，表示組播數據包可以遍歷的跳數。若ttl=1，多播請求只能由客戶端發(fā)送，而不能由任何服務器轉發(fā)，可以保證較低的協議開銷，而多跳網絡中ttl>1，多播包就會被轉發(fā)多次，此時無法保證較低的協議開銷。此外，在遠程客戶端上，將無法執(zhí)行多播發(fā)現。因此，多播方法更適合于在小型低功率網絡中執(zhí)行查找，這種網絡無需遠程客戶端的發(fā)現?；蛘逺D可以作為客戶端使用多播查找來填充其目錄。這樣RD既可以主動發(fā)現服務器資源，又可以為遠程客戶端提供資源發(fā)現。

2.DNS-SD協議開銷比較

本節(jié)分析與DNS-SD協議相關聯的服務發(fā)現協議開銷。對發(fā)現過程的不同階段進行了分析。即發(fā)布（public）、本地和全球的瀏覽（browse），本地和全球解析（resolution）。此外，分析了兩個不同的DNS-SD開源實現的開銷：Avahi[1]和輕量級多播DNS（LmDNS）[2]。Avahi是DNS-SD 基于Linux操作系統(tǒng)的mdns免費實現，而lmDNS是一種輕量級的mdns實現，用于使用Contiki操作系統(tǒng)開發(fā)的支持IP的智能對象。

假設星型網絡由兩個服務器和一個客戶端組成?？梢钥吹?，Avahi實現在發(fā)布的開銷很多。因為它將發(fā)布分成探測消息和通告消息。探測消息最多發(fā)送三條消息來查詢服務實例名稱是否已經被其他設備使用，當檢測到服務實例名稱沖突時，必須選擇新的服務實例名稱。如果沒有沖突，則發(fā)送通告消息，這導致相同的信息被發(fā)送了四次：探測消息最多發(fā)送三次TXT和SVR記錄，通告發(fā)送TXT、SVR和PTR。lmDNS探測消息只發(fā)一條消息。無沖突就發(fā)通告。lmDNS減小了開銷。

在瀏覽和解析方面，lmDNS在開銷方面再次優(yōu)于Avahi。這是因為Avahi在響應中包含了所有可用的記錄，而lmdns只包含了必要的信息。對于本地或全局（單播）瀏覽兩者開銷基本相當，綜合來看，Avahi只適合于邊界路由器而不適合于低功耗網絡。

3.DNS-SD與CoAP資源發(fā)現協議開銷比較

對比lmDNS與分布式CoAP的開銷，COAP的效率要高得多。在分布式情況下，由CoAP只執(zhí)行多播或單播查找，服務器網絡的開銷約為100-150字節(jié)。而mDNS在通告、瀏覽和解析階段，消息傳輸的總開銷約為700字節(jié)。因此，lmdns是分布式CoAP七倍的開銷。因此，取決于網絡變化的頻率，由于連接性、移動性、節(jié)點死亡等方面的變化，lmdns的較高開銷將增加設備的能耗并減少設備的壽命。總之，CoAP發(fā)現協議在開銷方面比DNS發(fā)現協議表現出更好的性能。只有在與現有域名系統(tǒng)快速集成時才考慮DNS服務發(fā)現，一般可在后端（back-end）使用DNS-SD，現場使用CoAP，以減少開銷。

4.發(fā)現功能

CoAP使用？Key=Value一次查詢就能發(fā)現不同類型的資源。例如，為了查找具有兩種類型的資源的設備，可以將查詢編寫為：？rt=philips.light.on&RT=philips.light.dimmer，用于查找兼具光開關和調光功能的設備資源。另一方面，DNS一次只能查詢一種類型。

CoAP允許使用通配符模式，例如：？RT=core.rd*，以便獲取任何匹配core.rd的資源。DNS不支持通配符。

在發(fā)出發(fā)現請求后，CoAP直接提供資源URI。dns-sd發(fā)現提供服務實例。然后通過服務實例解析為IP地址或主機名。

總之，基于CoAP的資源發(fā)現允許一組更高效、更豐富的機制來執(zhí)行查找。任何實現CoAP的設備能夠執(zhí)行CoAP資源發(fā)現，無需引入其他請求方法。對COAP-RD，end-point幾乎不需要額外的功能就能在RD中注冊或執(zhí)行查找。另一方面，dns-sd已經是非嵌入式設備發(fā)現的事實標準，使用DNS-sd允許中心化的服務發(fā)現，也可以使用單播DNS方法執(zhí)行發(fā)現。由于dns-sd使用標準的dns數據包格式查詢，使用dns-sd的LoWPAN網絡將更易于與外部的dns快速集成，相較于mdns，mdns則需要額外的客戶端內存來存儲從服務器接收到的服務發(fā)現信息。

【參考文獻】

[1] Avahi實現 http：//avahi.org/

[2] A. J. Jara， P. Martinez-Julia， A. Skarmeta. Light-Weight Mulighticast DNS and DNS-SD （lmDNS-SD）： IPv6-Based Resource and Service Discovery for the Web of Things. Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing （IMIS）， 2012.