《CoAP观察者机制详解》由会员分享，可在线阅读，更多相关《CoAP观察者机制详解（37页珍藏版）》请在金锄头文库上搜索。
1、CoAP观察者机制详解 Jade2016 12 目录 概述新增的OptionClient侧的实现Server侧的实现OthersExamples 概述 RFC7252定义的CoAP为受限网络中的受限节点了提供了一种RESTfull服务 CoAPServer对Resource的Representation负责 CoAPClient对自身感兴趣的资源的状态发起Request CoAPServer通过Response返回资源的当前状态如果Client持续一段时间内都要获取Resource的Presentation时 CoAP现有机制不太适用 HTTP那种周期重复查询的方式不太适合受限环境 基于此 R
2、FC7641在CoAP上定义了一种扩展机制 CoAPClient观察CoAPServer上资源 Client向Server 订阅 资源 只要资源状态发生变化 Server则会通知Client资源的新的状态本规范并未解决所有现有HTTP已有解决方案的问题 也并不是替代RFC5989定义的解决类似更通用问题的publish subscribe机制 观察者模式 观察者模式 发布 订阅模式 是经典的设计模式之一 订阅 发布 本规范借鉴了该模式 观察者 Observer 指的是CoAPClient 对象 Subject 是Server上的Resource CoAP的观察者机制 返回给Client的Not
3、ification中Observe会携带序号 便于Client对收到的Notification进行排序Registration和Notification通过token匹配 Registration Client通过携带ObserveOption向Server完成资源的订阅 Server将该Client加入该Resource的订阅者列表中Notification 当Server发现Resource发生变化时 向该Resource的订阅者发布通知 CoAPServer通过携带ObserveOption的Response将Resource的Presentation发送给ClientServer维护对
4、Resource的订阅者列表 直到Client对该Resource不再感兴趣 Client显式地解除注册关系Client拒绝Notification 回复Reset CON的Notification发送超时 一致性模型概述 导致Client和Server侧对于被观察对象的状态不一致的原因资源状态在Server侧发生改变到Client收到Notification 必然有一定的时延Notification通过CONMessage发送给Client 可能会丢失 此时Client仍然使用的是资源的旧状态 直到其收到新状态的NotificationServer错误的认为Client对Resource不敢
5、兴趣 从而不再向其发送Notification 直到Client再次注册收到新的Notification应对措施在资源变化时 协议将尽力将当前的Representation发送给Client client将在状态变化时尽可能快的收到通知 并且观察到尽可能多的状态变化 但是受限于CoAP的拥塞控制机制 不可保证Client可以观察到Resource的所有状态变化本规范对于Notification会提供标签 Max Age 超过该标签的Notification表示其携带的Resource状态已与实际状态失步 已不可用本规范依据最终一致性原则设计 协议保证如果资源不经历状态的新的改变 则最终所有注册
6、的观察者将具有最新资源状态的当前表示 可观察资源 CoAPserver决定了满足什么的条件 才能判定为Resource的状态发生了变化 实际由应用的设计者决定 CoAPServer执行 本协议不提供通用的状态变化的门限或者触发器 但是应用的设计者可以通过指定不同URI 参数化参数 决定在满足何种条件时 才认为是状态发生变化举例 表示温度发生变化即触发Notification 可以表示温度超过一定门限 返回Notification warm 或者低于一定门限返回 cold 可以表示温度超过42返回warning或者低于42时返回OK 可以用任意复杂的表达式判定是否触发状态变化 目录 概述新增的O
7、ptionClient侧的实现Server侧的实现OthersExamples ObserveOption Observe出现在Request中不但表示检索targetResource的Representation 而且表示订阅或解除订阅 Observe取值为0 表示订阅 register Observe取值为1 表示取消订阅 deregister 当Server返回的Response不携带ObserveOption 表示其不能或者不愿意接受这个订阅ObserveOption不是一个Cache Key 但是携带Option的Response是可缓存的Observe出现在Response中表示这
8、是一个Notification 同时暗示Server已经将该客户端加入了对指定Resource的订阅者列表 目录 概述新增的OptionClient侧的需求Server侧的需求OthersExamples Client的需求 RequestClient通过携带Observer取值为0发起注册 Server返回携带Observer的2 xx的Response表明Server同意注册和Fresh的Response可以被同样的Request请求复用避免访问Server一样 对被观察对象的通知也可以复用 前提是Request中的Option和Response中的Cache Key取值保持一致Clien
9、t必须聚合这类请求 且不能重复的发起注册NotificationNotification是对创建订阅关系的GETRequest的附加响应 通过token匹配 和正常的Response的区别在于 Notification中携带了ObserveOptionNotification的典型Response是2 05Content 携带的ObserveOption中包含通知的序号如果Request中包含一个或多个ETag Notification也可以是返回2 03ValidResponse 此Response中会包含ObserveOption 但是没有payload当发生某种情况 比如资源被删除 导致
10、Server对该Resource的GETrequest返回一个非2 xxResponse时 Server返回一个合适的Response 比如4 04NotFound 并解除订阅关系 非2 xx不会携带ObserveOption Client的需求 支持CoAP规范定义的Freshnessmodel和Validationmodel RFC72525 6章节 FreshnessofCachingClient可以考虑缓存普通Response一样缓存Notification 当Notification足够fresh时 不必联系ServerNotification的新鲜度和Response一样通过Max
11、 Age确定Server会尽力保证Client获取的Resource的状态与实际状态一致 但是Client不能依赖于可以观察到被观察对象所有经历的状态 比如由于Resource状态变化较为频繁 Server不能保证将状态的每次变化都同步到Client 服务器使用Max Age选项来指示观察状态和实际状态不一致的可接受时间范围 如果Client侧缓存的最新的Notification超过Max Age指示的时间 Client不能假定缓存的Notification中的状态反映了被观察对象的实际状态Client为了确认其有实际状态或者为了重注册 可以发起一个新的GETrequest 其中token和第
12、一次注册请求的token一致 除了ETag外的其他Option必须和注册请求中Option保持一致 推荐Client在其有新鲜的Response和Notification 不要发起这样的Request 此外Client需要在Max Age超时后的5 15秒随机时间内 发起这样的请求 Client的需求 Validationofcaching当Client有被观察对象的一个或多个Notification 缓存的 它可以采用携带ETag的Request给Server一个选择其缓存的Notification的机会Client可以在Request中携带其保存的所有Notification的ETag 当
13、被观察对象的状态与某一个Etag对应的Representation一致时 Server返回2 03Valid携带匹配的ETag给ClientClient需要保存所有候选的Response 直到观察者对被观察对象不再感兴趣或者Client携带一组新的ETag发起重注册 Client的需求 ReorderingtheNotificationNotification中的Observe携带了编号 用于Client判断哪一个Notification是最新鲜的 不能完全依赖于其到达的顺序 比较准则 Client的需求 TransmissionNotification可以通过CON或NONmessage发送
14、 和确认初始注册的Notification的Messagetype以及前一个Notification的type无关如果Client收到一个CONNotification 但是无法识别其token 必须返回RestMessage 对于NONNotification 是否返回Reset是可选的Client对于ServerCONNotification的Ack 标明Client是Alive并且对希望继续接收后续的Notification 如果Server未收到对CONNotification的ACK应答 Server可以假定该Client对该Resource已不敢兴趣 解除其注册关系 Client的
15、需求 Cancellation取消注册的方式Client不想接收Notification时 可以 forget 这个注册 当Server发送notification时 直接返回Reset 因为Client不识别notification中的token Client显式地通过GET携带ObserveOption 取值为1 发起去注册 让Server尽快释放该Resource占用的资源 目录 概述新增的OptionClient侧的实现Server侧的实现OthersExamples Server的需求 RequestClient通过携带Observer取值为0发起注册 Server返回携带Obser
16、ver的2 xx的包含Resource当前Representation的Response表明Server同意注册 同时Server将该Client以Endpoint token为key将该client加入该资源的订阅者列表 如果该Client已存在 要避免重复增加只要该Client在列表中 当Resource发生变化时 Server发送Notification给Client如果Server不愿或不能将该Client加入该Resource的订阅者列表 处理同不携带Observe的Request一样 Response中不能包含ObserveOptionClient通过携带Observer取值为1发起去注册 Server将该Client从指定Resource的订阅者列表中删除 随后的处理同正常Request一样 返回的Response中不能携带ObserveOption Server的需求 NotificationNotification是对创建订阅关系的GETRequest的附加响应 通过token匹配 和正常的Response的区别在于 Notification中携带了ObserveOp
