CoA协议详解图文.ppt

发现机制（ Discovery ） ? Service Discovery ：发现 Server 的方式： ? 通过 Server 的 URI 发现 Server ? 通过组播方式 (IPv4) 发现 Server ? 通过 All CoAP Nodes 组播地址 (IPv6) 发现 Server ? Server 默认在端口 5683 或 5684 提供 CoAP 服务 ? Resource Discovery: 将受限 Web 服务器托管的资源，其属性和其他资源关系的发现称 为 CoRE 资源发现。 ? 在 M2M 应用场景，由于没有人工接口， CoAP Endpoint 建议支持 RFC6690 定义的 可发现资源的 CoRE Link Format ，用于资源发现 ? CoAP 为应用 RFC6690 定义一个新的 Web Linking （ RFC5988 ）‘ ct Attribute 用 于指示返回的 Resource 的 Content-Format 目录 概述 Message Model Request/Response Model Options Response 的缓存机制 CoAP 组播 CoAP 代理 Securing CoAP Proxying ? Proxy 是一种在 CoAP Clients 驱动下代表它们执行 Request 的 Endpoint ? Proxy 按照功能分类 ? Forward-proxy ：被 Client 显示指定，并转发 Client request 到 Server 或 下一个 proxy ，必要时可以直接从本地 cache 中查询 response 直接返回 Client ? Reverse-proxy ：代表 Server 执行 Client 的 Request ， Reverse-Proxy 背 后一般隐藏着多个 origin Server ， Reverse-Proxy 根据 request-URI 和其 配置策略，决定将 Request 发往哪一个 origin Server 执行 Request ，必 要时也可以从本地 cache 中查询 response 直接返回 client ? Proxy 按照协议转换分类 ? CoAP-to-CoAP proxy ? cross proxy Proxy 的一般行为 ? 代理通常需要一种方式来基于其从客户端接收到的请求来确定其放置到目的地的请 求的潜在请求参数 ? 支持 Freshness model 和 Validation model 缓存 Response ? 对于 Request 可以识别的 Option ，知道该 option 是否应该作为 cache-key ：比如 URI- Path 必然是 cache-key ，而 Token 不可以作为 cache-key ? 对于 Request 中不识别的 Option ，知道根据 Option 中的 Unsafe 和 NoCacheKey 决定 是否可以作为 cache-key ：标识为 Safe-to-Forward 的 Option 且 NoCacheKey 未全置 1 ? Request 超时返回 5.04 （ gateway timeout ）或者 server 返回的 Response 无法处理， 返回 5.02(Bad gateway) ，否则将 origin server 返回的响应给 clinet ? 如果 Reponse 从 Cache 中选择，返回 Client 中的 Max-Age 需要减去在 cache 中的存活 时间 ? 处理 Request 中 Option 时，对于不能识别的 Unsafe Option ，返回 4.02 （ bad option ），对于 Response 中不能识别的 Unsafe Option ，返回 5.02 （ bad gateway ）， 对于不能识别的 Safe-to-Forward option ，不影响转发 Response Code-2.xx success This class of Response Code indicates that the clients request was successfully received, understood, and accepted ? 2.01 Created ： response to POST and PUT ， response 中 可能包含一个操作结果的 Representation ； not cacheable ? 2.02 Deleted ： response to POST and DELETE, not cachea