CoAP观察者机制.ppt

* * * * * * * * * * * * Client-Server Example 1 暂略 Client-Server Example 2 Client-Server Example 3 Client-Server Example 4 Proxy Example 1 Proxy Example 2 * 如有疑问欢迎讨论 * * * * * * * * * * * * * * * * * * * * * * * * CoAP观察者机制详解 Jade 2016/12 目录 概述 新增的Option Client侧的实现 Server侧的实现 Others Examples 概述 RFC7252定义的CoAP为受限网络中的受限节点了提供了一种RESTfull服务，CoAP Server对Resource的Representation负责，CoAP Client对自身感兴趣的资源的状态发起Request，CoAP Server通过Response返回资源的当前状态 如果Client持续一段时间内都要获取Resource的Presentation时，CoAP现有机制不太适用（HTTP那种周期重复查询的方式不太适合受限环境） 基于此，RFC7641在CoAP上定义了一种扩展机制：CoAP Client观察CoAP Server上资源，Client向Server“订阅”资源，只要资源状态发生变化，Server则会通知Client资源的新的状态 本规范并未解决所有现有HTTP已有解决方案的问题，也并不是替代RFC5989定义的解决类似更通用问题的publish/subscribe机制 观察者模式 观察者模式（发布-订阅模式）是经典的设计模式之一 订阅 发布 本规范借鉴了该模式，观察者(Observer)指的是CoAP Client，对象(Subject)是Server上的Resource; CoAP的观察者机制 返回给Client的Notification中Observe会携带序号，便于Client对收到的Notification进行排序 Registration和Notification通过token匹配 Registration：Client通过携带Observe Option向Server完成资源的订阅，Server将该Client加入该Resource的订阅者列表中 Notification：当Server发现Resource发生变化时，向该Resource的订阅者发布通知，CoAP Server通过携带Observe Option的Response将Resource的Presentation发送给Client Server维护对Resource的订阅者列表，直到Client对该Resource不再感兴趣： Client显式地解除注册关系 Client拒绝Notification(回复Reset) CON的Notification发送超时 一致性模型概述 导致Client和Server侧对于被观察对象的状态不一致的原因 资源状态在Server侧发生改变到Client收到Notification，必然有一定的时延 Notification通过CON Message发送给Client，可能会丢失，此时Client仍然使用的是资源的旧状态，直到其收到新状态的Notification Server错误的认为Client对Resource不敢兴趣，从而不再向其发送Notification，直到Client再次注册收到新的Notification 应对措施 在资源变化时，协议将尽力将当前的Representation发送给Client：client将在状态变化时尽可能快的收到通知，并且观察到尽可能多的状态变化，但是受限于CoAP的拥塞控制机制，不可保证Client可以观察到Resource的所有状态变化 本规范对于Notification会提供标签(Max-Age)，超过该标签的Notification表示其携带的Resource状态已与实际状态失步，已不可用 本规范依据最终一致性原则设计：协议保证如果资源不经历状态的新的改变，则最终所有注册的观察者将具有必威体育精装版资源状态的当前表示 可观察资源 CoAP server决定了满足什么的条件，才能判定为Resource的状态发生了变化(实际由应用的设计者决定，CoAP Server执行) 本协议不提供通用的状态变化的门限或者触发器，但是应用的设计者可以通过指定不同URI(参数化参数)，决定在满足何种条件时，才认为是状态发生变化 举例： coap://server/temperature，表示温度发生变化即触