Internet Engineering Task Force (IETF) K. Hartke
Request for Comments: 7641 Universitaet Bremen TZI
Category: Standards Track September 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Hartke
Request for Comments: 7641 Universitaet Bremen TZI
Category: Standards Track September 2015
ISSN: 2070-1721
Observing Resources in the Constrained Application Protocol (CoAP)
观察受限应用程序协议（CoAP）中的资源
Abstract
摘要
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.
受约束应用程序协议（CoAP）是一种用于受约束节点和网络的RESTful应用程序协议。CoAP服务器上资源的状态可能会随时间而变化。本文档为CoAP指定了一个简单的协议扩展，使CoAP客户端能够“观察”资源，即检索资源的表示，并在一段时间内保持服务器对该表示的更新。该协议遵循尽最大努力向客户端发送新表示的方法，并在每个客户端观察到的状态和服务器上的实际资源状态之间提供最终一致性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7641.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7641.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Consistency Model . . . . . . . . . . . . . . . . . . . . 6
1.4. Observable Resources . . . . . . . . . . . . . . . . . . 7
1.5. Requirements Notation . . . . . . . . . . . . . . . . . . 8
2. The Observe Option . . . . . . . . . . . . . . . . . . . . . 9
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 10
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13
4. Server-Side Requirements . . . . . . . . . . . . . . . . . . 14
4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 17
5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 20
6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Client/Server Examples . . . . . . . . . . . . . . . . . 24
A.2. Proxy Examples . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Consistency Model . . . . . . . . . . . . . . . . . . . . 6
1.4. Observable Resources . . . . . . . . . . . . . . . . . . 7
1.5. Requirements Notation . . . . . . . . . . . . . . . . . . 8
2. The Observe Option . . . . . . . . . . . . . . . . . . . . . 9
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 10
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13
4. Server-Side Requirements . . . . . . . . . . . . . . . . . . 14
4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 17
5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 20
6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Client/Server Examples . . . . . . . . . . . . . . . . . 24
A.2. Proxy Examples . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
The Constrained Application Protocol (CoAP) [RFC7252] is intended to provide RESTful services [REST] not unlike HTTP [RFC7230] while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of themselves highly constrained nodes [RFC7228].
受限应用程序协议（CoAP）[RFC7252]旨在提供RESTful服务[REST]，与HTTP[RFC7230]不同，同时降低实现的复杂性以及交换的数据包的大小，以使这些服务在自身高度受限节点的高度受限网络中有用[RFC7228]。
The model of REST is that of a client exchanging representations of resources with a server, where a representation captures the current or intended state of a resource. The server is the authority for representations of the resources in its namespace. A client interested in the state of a resource initiates a request to the server; the server then returns a response with a representation of the resource that is current at the time of the request.
REST模型是客户端与服务器交换资源表示的模型，其中表示捕获资源的当前或预期状态。服务器是其命名空间中资源表示的权威。对资源的状态感兴趣的客户端向服务器发起请求；然后，服务器返回一个响应，其中包含请求时当前的资源表示形式。
This model does not work well when a client is interested in having a current representation of a resource over a period of time. Existing approaches from HTTP, such as repeated polling or HTTP long polling [RFC6202], generate significant complexity and/or overhead and thus are less applicable in a constrained environment.
当客户端希望在一段时间内拥有资源的当前表示形式时，此模型无法正常工作。来自HTTP的现有方法，例如重复轮询或HTTP长轮询[RFC6202]，会产生显著的复杂性和/或开销，因此在受限环境中不太适用。
The protocol specified in this document extends the CoAP core protocol with a mechanism for a CoAP client to "observe" a resource on a CoAP server: the client retrieves a representation of the resource and requests this representation be updated by the server as long as the client is interested in the resource.
本文档中指定的协议扩展了CoAP核心协议，使CoAP客户端能够“观察”CoAP服务器上的资源：只要客户端对资源感兴趣，客户端就会检索资源的表示，并请求服务器更新该表示。
The protocol keeps the architectural properties of REST. It enables high scalability and efficiency through the support of caches and proxies. There is no intention, though, to solve the full set of problems that the existing HTTP solutions solve or to replace publish/subscribe networks that solve a much more general problem [RFC5989].
该协议保留了REST的体系结构属性。它通过支持缓存和代理实现了高可扩展性和高效率。不过，我们无意解决现有HTTP解决方案所解决的全部问题，也无意取代解决更一般问题的发布/订阅网络[RFC5989]。
The protocol is based on the well-known observer design pattern [GOF]. In this design pattern, components called "observers" register at a specific, known provider called the "subject" that they are interested in being notified whenever the subject undergoes a change in state. The subject is responsible for administering its list of registered observers. If multiple subjects are of interest to an observer, the observer must register separately for all of them.
该协议基于著名的观测器设计模式[GOF]。在这种设计模式中，称为“观察者”的组件在称为“主体”的特定已知提供者处注册，每当主体发生状态变化时，它们都希望得到通知。受试者负责管理其登记观察员名单。如果一个观察者对多个主题感兴趣，则该观察者必须为所有主题分别注册。
Observer Subject
| |
| Registration |
+------------------->|
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
Observer Subject
| |
| Registration |
+------------------->|
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
Figure 1: The Observer Design Pattern
图1：观察者设计模式
The observer design pattern is realized in CoAP as follows:
观察者设计模式在CoAP中实现如下：
Subject: In the context of CoAP, the subject is a resource in the namespace of a CoAP server. The state of the resource can change over time, ranging from infrequent updates to continuous state transformations.
主题：在CoAP上下文中，主题是CoAP服务器名称空间中的资源。资源的状态可以随时间变化，从不频繁的更新到连续的状态转换。
Observer: An observer is a CoAP client that is interested in having a current representation of the resource at any given time.
观察者：观察者是一个CoAP客户机，它对在任何给定时间拥有资源的当前表示感兴趣。
Registration: A client registers its interest in a resource by initiating an extended GET request to the server. In addition to returning a representation of the target resource, this request causes the server to add the client to the list of observers of the resource.
注册：客户机通过向服务器发起扩展GET请求来注册其对资源的兴趣。除了返回目标资源的表示形式外，此请求还会导致服务器将客户端添加到资源的观察者列表中。
Notification: Whenever the state of a resource changes, the server notifies each client in the list of observers of the resource. Each notification is an additional CoAP response sent by the server in reply to the single extended GET request and includes a complete, updated representation of the new resource state.
通知：每当资源的状态发生变化时，服务器都会通知资源观察者列表中的每个客户端。每个通知都是服务器为响应单个扩展GET请求而发送的附加CoAP响应，包括新资源状态的完整更新表示。
Figure 2 below shows an example of a CoAP client registering its interest in a resource and receiving three notifications: the first with the current state upon registration, and then two upon changes to the resource state. Both the registration request and the notifications are identified as such by the presence of the Observe Option defined in this document. In notifications, the Observe Option additionally provides a sequence number for reordering detection. All notifications carry the token specified by the client, so the client can easily correlate them to the request.
下面的图2显示了一个CoAP客户端注册其对资源的兴趣并接收三个通知的示例：第一个通知在注册时具有当前状态，然后在资源状态发生更改时接收两个通知。注册请求和通知均通过存在本文件中定义的观察选项来识别。在通知中，“观察”选项还提供了用于重新排序检测的序列号。所有通知都带有客户端指定的令牌，因此客户端可以轻松地将它们与请求关联起来。
Client Server
| |
| GET /temperature |
| Token: 0x4a | Registration
| Observe: 0 |
+------------------->|
| |
| 2.05 Content |
| Token: 0x4a | Notification of
| Observe: 12 | the current state
| Payload: 22.9 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 44 | a state change
| Payload: 22.8 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 60 | a state change
| Payload: 23.1 Cel |
|<-------------------+
| |
Client Server
| |
| GET /temperature |
| Token: 0x4a | Registration
| Observe: 0 |
+------------------->|
| |
| 2.05 Content |
| Token: 0x4a | Notification of
| Observe: 12 | the current state
| Payload: 22.9 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 44 | a state change
| Payload: 22.8 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 60 | a state change
| Payload: 23.1 Cel |
|<-------------------+
| |
Figure 2: Observing a Resource in CoAP
图2：在CoAP中观察资源
Note: In this document, "Cel" stands for "degrees Celsius".
注：在本文件中，“Cel”代表“摄氏度”。
A client remains on the list of observers as long as the server can determine the client's continued interest in the resource. The server may send a notification in a confirmable CoAP message to request an acknowledgement from the client. When the client deregisters, rejects a notification, or the transmission of a notification times out after several transmission attempts, the client is considered no longer interested in the resource and is removed by the server from the list of observers.
只要服务器能够确定客户端对资源的持续兴趣，客户端就会保留在观察者列表中。服务器可以在可确认的CoAP消息中发送通知以请求来自客户端的确认。当客户端注销、拒绝通知或在多次传输尝试后通知传输超时时，客户端将被视为对资源不再感兴趣，服务器将其从观察者列表中删除。
While a client is in the list of observers of a resource, the goal of the protocol is to keep the resource state observed by the client as closely in sync with the actual state at the server as possible.
当客户端位于资源的观察者列表中时，协议的目标是使客户端观察到的资源状态尽可能与服务器上的实际状态保持同步。
It cannot be avoided that the client and the server become out of sync at times: First, there is always some latency between the change of the resource state and the receipt of the notification. Second,
客户机和服务器有时会变得不同步，这是不可避免的：首先，在更改资源状态和接收通知之间总是有一些延迟。第二
CoAP messages with notifications can get lost, which will cause the client to assume an old state until it receives a new notification. And third, the server may erroneously come to the conclusion that the client is no longer interested in the resource, which will cause the server to stop sending notifications and the client to assume an old state until it eventually registers its interest again.
带有通知的CoAP消息可能会丢失，这将导致客户端在收到新通知之前一直处于旧状态。第三，服务器可能错误地得出客户机不再对资源感兴趣的结论，这将导致服务器停止发送通知，并且客户机假定为旧状态，直到它最终再次注册其兴趣为止。
The protocol addresses this issue as follows:
该议定书处理这一问题的方式如下：
o It follows a best-effort approach for sending the current representation to the client after a state change: clients should see the new state after a state change as soon as possible, and they should see as many states as possible. This is limited by congestion control, however, so a client cannot rely on observing every single state that a resource might go through.
o 它遵循一种尽力而为的方法，在状态更改后将当前表示发送给客户机：客户机应该在状态更改后尽快看到新状态，并且应该看到尽可能多的状态。但是，这受到拥塞控制的限制，因此客户端不能依赖于观察资源可能经历的每个状态。
o It labels notifications with a maximum duration up to which it is acceptable for the observed state and the actual state to be out of sync. When the age of the notification received reaches this limit, the client cannot use the enclosed representation until it receives a new notification.
o 它标记通知的最长持续时间，在该时间内，观察到的状态和实际状态不同步是可以接受的。当收到的通知的期限达到此限制时，客户端在收到新通知之前无法使用随附的表示。
o It is designed on the principle of eventual consistency: the protocol guarantees that if the resource does not undergo a new change in state, eventually all registered observers will have a current representation of the latest resource state.
o 它是基于最终一致性原则设计的：协议保证，如果资源的状态没有发生新的变化，最终所有注册的观察者都将拥有最新资源状态的当前表示。
A CoAP server is the authority for determining under what conditions resources change their state and thus when observers are notified of new resource states. The protocol does not offer explicit means for setting up triggers or thresholds; it is up to the server to expose observable resources that change their state in a way that is useful in the application context.
CoAP服务器是确定资源在什么条件下改变其状态以及何时通知观察者新的资源状态的权威。该协议没有提供设置触发器或阈值的明确方法；由服务器来公开可观察到的资源，这些资源以在应用程序上下文中有用的方式更改其状态。
For example, a CoAP server with an attached temperature sensor could expose one or more of the following resources:
例如，带有温度传感器的CoAP服务器可能会暴露以下一个或多个资源：
o <coap://server/temperature>, which changes its state every few
seconds to a current reading of the temperature sensor;
o <coap://server/temperature>, which changes its state every few
seconds to a current reading of the temperature sensor;
o <coap://server/temperature/felt>, which changes its state to
"COLD" whenever the temperature reading drops below a certain pre-
configured threshold and to "WARM" whenever the reading exceeds a
second, slightly higher threshold;
o <coap://server/temperature/felt>, which changes its state to
"COLD" whenever the temperature reading drops below a certain pre-
configured threshold and to "WARM" whenever the reading exceeds a
second, slightly higher threshold;
o <coap://server/temperature/critical?above=42>, which changes its
state based on the client-specified parameter value either every
few seconds to the current temperature reading if the temperature
exceeds the threshold or to "OK" when the reading drops below;
o <coap://server/temperature/critical?above=42>, which changes its
state based on the client-specified parameter value either every
few seconds to the current temperature reading if the temperature
exceeds the threshold or to "OK" when the reading drops below;
o <coap://server/?query=select+avg(temperature)+from+Sensor.window: time(30sec)>, which accepts expressions of arbitrary complexity and changes its state accordingly.
o <coap://server/?query=select+avg（温度）+from+Sensor.window:time（30秒）>，它接受任意复杂度的表达式并相应地更改其状态。
Thus, by designing CoAP resources that change their state on certain conditions, it is possible to update the client only when these conditions occur instead of supplying it continuously with raw sensor data. By parameterizing resources, this is not limited to conditions defined by the server, but can be extended to arbitrarily complex queries specified by the client. The application designer therefore can choose exactly the right level of complexity for the application envisioned and devices involved and is not constrained to a "one size fits all" mechanism built into the protocol.
因此，通过设计在特定条件下改变其状态的CoAP资源，仅当这些条件发生时才可能更新客户端，而不是持续向其提供原始传感器数据。通过参数化资源，这不仅限于服务器定义的条件，还可以扩展到客户机指定的任意复杂查询。因此，应用程序设计者可以为设想的应用程序和所涉及的设备选择准确的复杂度级别，并且不受协议内置的“一刀切”机制的限制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The Observe Option has the following properties. Its meaning depends on whether it is included in a GET request or in a response.
“观察”选项具有以下属性。它的含义取决于它是包含在GET请求中还是包含在响应中。
+-----+---+---+---+---+---------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+---------+--------+--------+---------+
| 6 | | x | - | | Observe | uint | 0-3 B | (none) |
+-----+---+---+---+---+---------+--------+--------+---------+
+-----+---+---+---+---+---------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+---------+--------+--------+---------+
| 6 | | x | - | | Observe | uint | 0-3 B | (none) |
+-----+---+---+---+---+---------+--------+--------+---------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
Table 1: The Observe Option
表1：观察选项
When included in a GET request, the Observe Option extends the GET method so it does not only retrieve a current representation of the target resource, but also requests the server to add or remove an entry in the list of observers of the resource depending on the option value. The list entry consists of the client endpoint and the token specified by the client in the request. Possible values are:
当包含在GET请求中时，Observe选项扩展了GET方法，因此它不仅检索目标资源的当前表示形式，而且还请求服务器根据选项值在资源的观察者列表中添加或删除条目。列表项由客户端端点和客户端在请求中指定的令牌组成。可能的值为：
0 (register) adds the entry to the list, if not present;
0（寄存器）将条目添加到列表中（如果不存在）；
1 (deregister) removes the entry from the list, if present.
1（注销）从列表中删除条目（如果存在）。
The Observe Option is not critical for processing the request. If the server is unwilling or unable to add a new entry to the list of observers, then the request falls back to a normal GET request and the response does not include the Observe Option.
观察选项对于处理请求并不重要。如果服务器不愿意或无法将新条目添加到观察者列表中，那么请求将返回到正常的GET请求，并且响应不包括观察选项。
The Observe Option is not part of the Cache-Key: a cacheable response obtained with an Observe Option in the request can be used to satisfy a request without an Observe Option, and vice versa. When a stored response with an Observe Option is used to satisfy a normal GET request, the option MUST be removed before the response is returned.
Observe选项不是缓存键的一部分：在请求中使用Observe选项获得的可缓存响应可用于满足不使用Observe选项的请求，反之亦然。当使用带有观察选项的存储响应来满足正常GET请求时，必须在返回响应之前删除该选项。
When included in a response, the Observe Option identifies the message as a notification. This implies that a matching entry exists in the list of observers and that the server will notify the client of changes to the resource state. The option value is a sequence number for reordering detection (see Sections 3.4 and 4.4).
当包含在响应中时，观察选项将消息标识为通知。这意味着观察者列表中存在匹配的条目，并且服务器将通知客户端资源状态的更改。选项值是用于重新排序检测的序列号（见第3.4节和第4.4节）。
The value of the Observe Option is encoded as an unsigned integer in network byte order using a variable number of bytes ('uint' option format); see Section 3.2 of RFC 7252 [RFC7252].
观察选项的值使用可变字节数（“uint”选项格式）按网络字节顺序编码为无符号整数；参见RFC 7252[RFC7252]第3.2节。
A client registers its interest in a resource by issuing a GET request with an Observe Option set to 0 (register). If the server returns a 2.xx response that includes an Observe Option as well, the server has successfully added an entry with the client endpoint and request token to the list of observers of the target resource, and the client will be notified of changes to the resource state.
客户机通过发出一个GET请求，并将观察选项设置为0（register），来注册其对资源的兴趣。如果服务器返回的2.xx响应也包含观察选项，则服务器已成功地向目标资源的观察者列表添加了一个带有客户端端点和请求令牌的条目，并且将通知客户端资源状态的更改。
Like a fresh response can be used to satisfy a request without contacting the server, the stream of updates resulting from one observation request can be used to satisfy another (observation or normal GET) request if the target resource is the same. A client MUST aggregate such requests and MUST NOT register more than once for the same target resource. The target resource is identified by all options in the request that are part of the Cache-Key. This includes, for example, the full request URI and the Accept Option.
与新响应可用于满足请求而无需联系服务器一样，如果目标资源相同，则一个观察请求产生的更新流可用于满足另一个（观察或正常GET）请求。客户端必须聚合此类请求，并且不能为同一目标资源注册多次。目标资源由请求中作为缓存密钥一部分的所有选项标识。例如，这包括完整的请求URI和接受选项。
Notifications are additional responses sent by the server in reply to the single extended GET request that created the registration. Each notification includes the token specified by the client in the request. The only difference between a notification and a normal response is the presence of the Observe Option.
通知是服务器为响应创建注册的单个扩展GET请求而发送的附加响应。每个通知都包括客户端在请求中指定的令牌。通知和正常响应之间的唯一区别是存在“观察”选项。
Notifications typically have a 2.05 (Content) response code. They include an Observe Option with a sequence number for reordering detection (see Section 3.4) and a payload in the same Content-Format as the initial response. If the client included one or more ETag Options in the GET request (see Section 3.3), notifications can have a 2.03 (Valid) response code rather than a 2.05 (Content) response code. Such notifications include an Observe Option with a sequence number but no payload.
通知通常具有2.05（内容）响应代码。它们包括一个带有用于重新排序检测的序列号的观察选项（见第3.4节）和一个与初始响应内容格式相同的有效载荷。如果客户端在GET请求中包含一个或多个ETag选项（请参见第3.3节），则通知可以具有2.03（有效）响应代码，而不是2.05（内容）响应代码。此类通知包括一个带有序列号但没有有效负载的观察选项。
In the event that the resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server sends a notification with an appropriate response code (such as 4.04 Not Found) and removes the client's entry from the list of observers of the resource. Non-2.xx responses do not include an Observe Option.
如果资源发生更改，导致正常GET请求在此时返回非2.xx响应（例如，当资源被删除时），服务器将发送一个带有适当响应代码（例如4.04 Not Found）的通知，并从资源的观察者列表中删除客户端条目。非2.xx响应不包括观察选项。
As notifications are just additional responses to a GET request, notifications partake in caching as defined in Section 5.6 of RFC 7252 [RFC7252]. Both the freshness model and the validation model are supported.
由于通知只是GET请求的附加响应，因此通知参与缓存，如RFC 7252[RFC7252]第5.6节所定义。同时支持新鲜度模型和验证模型。
A client MAY store a notification like a response in its cache and use a stored notification that is fresh without contacting the server. Like a response, a notification is considered fresh while its age is not greater than the value indicated by the Max-Age Option (and no newer notification/response has been received).
客户端可以在其缓存中存储通知（如响应），并使用存储的通知，该通知是新的，无需联系服务器。与响应一样，当通知的期限不大于“最大期限”选项所指示的值（并且未收到更新的通知/响应）时，通知被视为是新的。
The server will do its best to keep the resource state observed by the client as closely in sync with the actual state as possible. However, a client cannot rely on observing every single state that a resource might go through. For example, if the network is congested or the state changes more frequently than the network can handle, the server can skip notifications for any number of intermediate states.
服务器将尽最大努力使客户端观察到的资源状态尽可能与实际状态保持同步。然而，客户机不能依赖于观察资源可能经历的每一种状态。例如，如果网络拥塞或状态更改的频率超过网络所能处理的频率，服务器可以跳过任何数量的中间状态的通知。
The server uses the Max-Age Option to indicate an age up to which it is acceptable that the observed state and the actual state are inconsistent. If the age of the latest notification becomes greater than its indicated Max-Age, then the client MUST NOT assume that the enclosed representation reflects the actual resource state.
服务器使用“最大年龄”选项来指示观察到的状态与实际状态不一致是可以接受的年龄。如果最新通知的期限大于其指示的最大期限，则客户端不得假定所附的表示反映了实际的资源状态。
To make sure it has a current representation and/or to re-register its interest in a resource, a client MAY issue a new GET request with the same token as the original at any time. All options MUST be identical to those in the original request except for the set of ETag Options. It is RECOMMENDED that the client does not issue the request while it still has a fresh notification/response for the resource in its cache. Additionally, the client SHOULD at least wait for a random amount of time between 5 and 15 seconds after Max-Age expired to reduce collisions with other clients.
为了确保其具有当前表示和/或重新注册其在资源中的权益，客户机可以随时使用与原始相同的令牌发出新的GET请求。除ETag选项集外，所有选项必须与原始请求中的选项相同。建议客户端在其缓存中仍有资源的新通知/响应时不要发出请求。此外，客户机应在“最长使用期限”过期后至少等待5到15秒之间的随机时间，以减少与其他客户机的冲突。
When a client has one or more notifications stored in its cache for a resource, it can use the ETag Option in the GET request to give the server an opportunity to select a stored notification to be used.
当客户机的缓存中存储了一个或多个资源通知时，它可以使用GET请求中的ETag选项为服务器提供选择要使用的存储通知的机会。
The client MAY include an ETag Option for each stored response that is applicable in the GET request. Whenever the observed resource changes to a representation identified by one of the ETag Options, the server can select a stored response by sending a 2.03 (Valid)
客户机可以包括适用于GET请求的每个存储响应的ETag选项。每当观察到的资源更改为ETag选项之一标识的表示时，服务器可以通过发送2.03（有效）来选择存储的响应
notification with an appropriate ETag Option instead of a 2.05 (Content) notification.
带有适当ETag选项的通知，而不是2.05（内容）通知。
A client implementation needs to keep all candidate responses in its cache until it is no longer interested in the target resource or it re-registers with a new set of entity tags.
客户机实现需要将所有候选响应保留在其缓存中，直到它不再对目标资源感兴趣或使用一组新的实体标记重新注册。
Messages with notifications can arrive in a different order than they were sent. Since the goal is to keep the observed state as closely in sync with the actual state as possible, a client MUST consider the notification that was sent most recently as the freshest, regardless of the order of arrival.
带有通知的邮件到达的顺序可能与发送的顺序不同。由于目标是尽可能地将观察到的状态与实际状态保持同步，因此客户端必须考虑最近发送的最新鲜的通知，而不考虑到达顺序。
To provide an order among notifications for the client, the server sets the value of the Observe Option in each notification to the 24 least significant bits of a strictly increasing sequence number. An incoming notification was sent more recently than the freshest notification so far when one of the following conditions is met:
为了为客户端提供通知之间的顺序，服务器将每个通知中的Observe选项的值设置为严格递增序列号的24个最低有效位。当满足以下条件之一时，发送的传入通知比迄今为止最新的通知要晚：
(V1 < V2 and V2 - V1 < 2^23) or
(V1 > V2 and V1 - V2 > 2^23) or
(T2 > T1 + 128 seconds)
(V1 < V2 and V2 - V1 < 2^23) or
(V1 > V2 and V1 - V2 > 2^23) or
(T2 > T1 + 128 seconds)
where V1 is the value of the Observe Option in the freshest notification so far, V2 is the value of the Observe Option in the incoming notification, T1 is a client-local timestamp for the freshest notification so far, and T2 is a client-local timestamp for the incoming notification.
其中V1是迄今为止最新通知中的观察选项的值，V2是传入通知中的观察选项的值，T1是迄今为止最新通知的客户端本地时间戳，T2是传入通知的客户端本地时间戳。
Design Note: The first two conditions verify that V1 is less than V2 in 24-bit serial number arithmetic [RFC1982]. The third condition ensures that if the server is generating serial numbers based on a local clock, the time elapsed between the two incoming messages is not so large that the difference between V1 and V2 has become larger than the largest integer that it is meaningful to add to a 24-bit serial number; in other words, after 128 seconds have elapsed without any notification, a client does not need to check the sequence numbers to assume that an incoming notification was sent more recently than the freshest notification it has received so far.
设计说明：前两个条件验证24位序列号算法[RFC1982]中的V1小于V2。第三个条件确保，如果服务器基于本地时钟生成序列号，则两条传入消息之间经过的时间不会太长，以致V1和V2之间的差值已大于最大整数，因此添加到24位序列号是有意义的；换句话说，在没有任何通知的情况下经过128秒之后，客户端不需要检查序列号，以假定传入通知的发送时间比它迄今为止收到的最新通知的发送时间要晚。
The duration of 128 seconds was chosen as a nice round number greater than MAX_LATENCY (Section 4.8.2 of RFC 7252 [RFC7252]).
128秒的持续时间被选为大于最大延迟（RFC 7252[RFC7252]第4.8.2节）的一个不错的整数。
A notification can be confirmable or non-confirmable, i.e., it can be sent in a confirmable or a non-confirmable message. The message type used for a notification is independent of the type used for the request and of any previous notification.
通知可以是可确认的，也可以是不可确认的，也就是说，它可以在可确认的或不可确认的消息中发送。用于通知的消息类型独立于用于请求和以前任何通知的类型。
If a client does not recognize the token in a confirmable notification, it MUST NOT acknowledge the message and SHOULD reject it with a Reset message; otherwise, the client MUST acknowledge the message as usual. In the case of a non-confirmable notification, rejecting the message with a Reset message is OPTIONAL.
如果客户机无法识别可确认通知中的令牌，则不得确认该消息，并应使用重置消息拒绝该消息；否则，客户端必须像往常一样确认消息。在不可确认通知的情况下，使用重置消息拒绝消息是可选的。
An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers (Section 4.5).
确认消息向服务器发信号表示客户端处于活动状态并且有兴趣接收进一步的通知；如果服务器没有收到回复可确认通知的确认，它将假定客户端不再感兴趣，并最终从观察者列表中删除相关条目（第4.5节）。
A client that is no longer interested in receiving notifications for a resource can simply "forget" the observation. When the server then sends the next notification, the client will not recognize the token in the message and thus will return a Reset message. This causes the server to remove the associated entry from the list of observers. The entries in lists of observers are effectively "garbage collected" by the server.
不再对接收资源通知感兴趣的客户端可以简单地“忘记”观察结果。当服务器随后发送下一个通知时，客户端将无法识别消息中的令牌，因此将返回重置消息。这会导致服务器从观察者列表中删除关联的条目。观察者列表中的条目被服务器有效地“垃圾收集”。
Implementation Note: Due to potential message loss, the Reset message may not reach the server. The client may therefore have to reject multiple notifications, each with one Reset message, until the server finally removes the associated entry from the list of observers and stops sending notifications.
实施说明：由于潜在的消息丢失，重置消息可能无法到达服务器。因此，客户端可能必须拒绝多个通知，每个通知都带有一条重置消息，直到服务器最终从观察者列表中删除相关条目并停止发送通知为止。
In some circumstances, it may be desirable to cancel an observation and release the resources allocated by the server to it more eagerly. In this case, a client MAY explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). All other options MUST be identical to those in the registration request except for the set of ETag Options. When the server receives such a request, it will remove any matching entry from the list of observers and process the GET request as usual.
在某些情况下，可能需要取消观察并更急切地释放服务器分配给它的资源。在这种情况下，客户机可以通过发出GET请求来显式取消注册，该请求将令牌字段设置为要取消的观察的令牌，并包括值设置为1（取消注册）的观察选项。除ETag选项集外，所有其他选项必须与注册请求中的选项相同。当服务器收到这样的请求时，它将从观察者列表中删除任何匹配的条目，并像往常一样处理GET请求。
A GET request with an Observe Option set to 0 (register) requests the server not only to return a current representation of the target resource, but also to add the client to the list of observers of that resource. Upon success, the server returns a current representation of the resource and MUST keep this representation updated (as described in Section 1.3) as long as the client is on the list of observers.
将Observe选项设置为0（register）的GET请求请求服务器不仅返回目标资源的当前表示形式，还请求将客户端添加到该资源的观察者列表中。成功后，服务器返回资源的当前表示形式，并且只要客户端在观察者列表中，服务器就必须更新此表示形式（如第1.3节所述）。
The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one.
观察者列表中的条目由客户端端点和客户端在请求中指定的令牌设置密钥。如果列表中已存在具有匹配端点/令牌对的条目（例如，当客户端希望增强其对资源的兴趣时，会发生这种情况），则服务器不得添加新条目，而必须替换或更新现有条目。
A server that is unable or unwilling to add a new entry to the list of observers of a resource MAY silently ignore the registration request and process the GET request as usual. The resulting response MUST NOT include an Observe Option, the absence of which signals to the client that it will not be notified of changes to the resource and, e.g., needs to poll the resource for its state instead.
无法或不愿意向资源的观察者列表添加新条目的服务器可能会自动忽略注册请求，并像往常一样处理GET请求。产生的响应不得包括观察选项，如果没有观察选项，则向客户端发出信号，表示不会向其通知资源的更改，例如，需要轮询资源的状态。
If the Observe Option in a GET request is set to 1 (deregister), then the server MUST remove any existing entry with a matching endpoint/ token pair from the list of observers and process the GET request as usual. The resulting response MUST NOT include an Observe Option.
如果GET请求中的观察选项设置为1（取消注册），则服务器必须从观察者列表中删除任何具有匹配端点/令牌对的现有条目，并像往常一样处理GET请求。结果响应不得包括观察选项。
A client is notified of changes to the resource state by additional responses sent by the server in reply to the GET request. Each such notification response (including the initial response) MUST echo the token specified by the client in the GET request. If there are multiple entries in the list of observers, the order in which the clients are notified is not defined; the server is free to use any method to determine the order.
服务器在响应GET请求时发送额外响应，通知客户机资源状态的更改。每个这样的通知响应（包括初始响应）必须回显客户端在GET请求中指定的令牌。如果观察者列表中有多个条目，则未定义通知客户的顺序；服务器可以自由使用任何方法来确定顺序。
A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response code. However, in the event that the state of a resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server SHOULD notify the client by sending a notification with an
通知应具有2.05（内容）或2.03（有效）响应代码。但是，如果资源的状态发生变化，导致正常的GET请求在此时返回非2.xx响应（例如，当资源被删除时），服务器应通过发送带有
appropriate response code (such as 4.04 Not Found) and subsequently MUST remove the associated entry from the list of observers of the resource.
相应的响应代码（如4.04未找到），随后必须从资源的观察者列表中删除相关条目。
The Content-Format specified in a 2.xx notification MUST be the same as the one used in the initial response to the GET request. If the server is unable to continue sending notifications in this format, it SHOULD send a notification with a 4.06 (Not Acceptable) response code and subsequently MUST remove the associated entry from the list of observers of the resource.
2.xx通知中指定的内容格式必须与GET请求初始响应中使用的格式相同。如果服务器无法继续以这种格式发送通知，则应发送带有4.06（不可接受）响应代码的通知，并且随后必须从资源的观察者列表中删除相关条目。
A 2.xx notification MUST include an Observe Option with a sequence number as specified in Section 4.4 below; a non-2.xx notification MUST NOT include an Observe Option.
2.xx通知必须包括一个带有以下第4.4节规定序号的观察选项；非2.xx通知不得包含观察选项。
As notifications are just additional responses sent by the server in reply to a GET request, they are subject to caching as defined in Section 5.6 of RFC 7252 [RFC7252].
由于通知只是服务器为响应GET请求而发送的附加响应，因此它们受到RFC 7252[RFC7252]第5.6节中定义的缓存的约束。
After returning the initial response, the server MUST keep the resource state that is observed by the client as closely in sync with the actual resource state as possible.
返回初始响应后，服务器必须使客户端观察到的资源状态尽可能与实际资源状态保持同步。
Since becoming out of sync at times cannot be avoided, the server MUST indicate for each representation an age up to which it is acceptable that the observed state and the actual state are inconsistent. This age is application dependent and MUST be specified in notifications using the Max-Age Option.
由于有时无法避免失去同步，服务器必须为每个表示指明一个年龄，在该年龄之前，观察到的状态和实际状态不一致是可以接受的。此年龄取决于应用程序，必须在通知中使用“最大年龄”选项指定。
When the resource does not change and the client has a current representation, the server does not need to send a notification. However, if the client does not receive a notification, the client cannot tell if the observed state and the actual state are still in sync. Thus, when the age of the latest notification becomes greater than its indicated Max-Age, the client no longer has a usable representation of the resource state. The server MAY wish to prevent that by sending a new notification with the unchanged representation and a new Max-Age just before the Max-Age indicated earlier expires.
当资源未更改且客户端具有当前表示时，服务器无需发送通知。但是，如果客户端没有收到通知，则客户端无法判断观察到的状态和实际状态是否仍然同步。因此，当最新通知的期限变得大于其指示的最大期限时，客户端不再具有资源状态的可用表示。服务器可能希望通过在前面指示的最长期限即将到期之前发送具有未更改表示形式和新最长期限的新通知来防止这种情况。
A client can include a set of entity tags in its request using the ETag Option. When an observed resource changes its state and the origin server is about to send a 2.05 (Content) notification, then whenever that notification has an entity tag in the set of entity tags specified by the client, the server MAY send a 2.03 (Valid) response with an appropriate ETag Option instead.
客户机可以使用ETag选项在其请求中包含一组实体标记。当观察到的资源更改其状态且源服务器即将发送2.05（内容）通知时，则每当该通知在客户端指定的实体标记集中具有实体标记时，服务器可能会发送带有适当ETag选项的2.03（有效）响应。
Because messages can get reordered, the client needs a way to determine if a notification arrived later than a newer notification. For this purpose, the server MUST set the value of the Observe Option of each notification it sends to the 24 least significant bits of a strictly increasing sequence number. The sequence number MAY start at any value and MUST NOT increase so fast that it increases by more than 2^23 within less than 256 seconds.
因为消息可以被重新排序，所以客户端需要一种方法来确定通知是否晚于新的通知到达。为此，服务器必须将其发送的每个通知的Observe选项的值设置为严格递增的序列号的24个最低有效位。序列号可以从任何值开始，并且不能增加得太快，以至于在256秒内增加超过2^23。
The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. The value of the Observe Option MUST be current at the time of transmission; if a notification is retransmitted, the server MUST update the value of the option to the sequence number that is current at that time before retransmission.
为通知选择的序列号必须大于使用相同资源的相同令牌发送到相同客户端的任何先前通知的序列号。观察选项的值必须是传输时的当前值；如果重新传输通知，服务器必须在重新传输之前将选项的值更新为当前的序列号。
Implementation Note: A simple implementation that satisfies the requirements is to obtain a timestamp from a local clock. The sequence number then is the timestamp in ticks, where 1 tick = (256 seconds)/(2^23) = 30.52 microseconds. It is not necessary that the clock reflects the current time/date.
实现说明：满足需求的一个简单实现是从本地时钟获取时间戳。然后，序列号是时间戳，单位为ticks，其中1 tick=（256秒）/（2^23）=30.52微秒。时钟不必反映当前时间/日期。
Another valid implementation is to store a 24-bit unsigned integer variable per resource and increment this variable each time the resource undergoes a change of state (provided that the resource changes its state less than 2^23 times in the first 256 seconds after every state change). This removes the need to update the value of the Observe Option on retransmission when the resource state did not change.
另一个有效的实现是为每个资源存储一个24位无符号整数变量，并在每次资源发生状态更改时递增该变量（前提是资源在每次状态更改后的前256秒内更改其状态的次数少于2^23次）。这样，当资源状态没有改变时，就不需要在重新传输时更新Observe选项的值。
Design Note: The choice of a 24-bit option value and a time span of 256 seconds theoretically allows for a notification rate of up to 65536 notifications per second. Constrained nodes often have rather imprecise clocks, though, and inaccuracies of the client and server side may cancel out or add in effect. Therefore, the maximum notification rate is reduced to 32768 notifications per second. This is still well beyond the highest known design
设计说明：选择24位选项值和256秒的时间跨度理论上允许每秒最多65536次通知的通知速率。然而，受约束的节点通常具有相当不精确的时钟，客户端和服务器端的不精确性可能会抵消或增加影响。因此，最大通知速率降低到每秒32768个通知。这仍然远远超出了已知的最高设计
objective of around 1 kHz (most CoAP applications will be several orders of magnitude below that) but allows total clock inaccuracies of up to -50/+100%.
目标约为1 kHz（大多数CoAP应用将比该值低几个数量级），但允许总时钟误差高达-50/+100%。
A notification can be sent in a confirmable or a non-confirmable message. The message type used is typically application dependent and may be determined by the server for each notification individually.
通知可以通过可确认或不可确认的消息发送。所使用的消息类型通常取决于应用程序，并且可能由服务器为每个通知单独确定。
For example, for resources that change in a somewhat predictable or regular fashion, notifications can be sent in non-confirmable messages; for resources that change infrequently, notifications can be sent in confirmable messages. The server can combine these two approaches depending on the frequency of state changes and the importance of individual notifications.
例如，对于以某种可预测或常规方式更改的资源，可以在不可确认的消息中发送通知；对于不经常更改的资源，可以在可确认消息中发送通知。服务器可以根据状态更改的频率和单个通知的重要性将这两种方法结合起来。
A server MAY choose to skip sending a notification if it knows that it will send another notification soon, for example, when the state of a resource is changing frequently. It also MAY choose to send more than one notification for the same resource state. However, above all, the server MUST ensure that a client in the list of observers of a resource eventually observes the latest state if the resource does not undergo a new change in state.
如果服务器知道它将很快发送另一个通知（例如，当资源的状态频繁更改时），则可以选择跳过发送通知。它还可以选择为同一资源状态发送多个通知。但是，最重要的是，服务器必须确保资源的观察者列表中的客户端最终观察到最新状态，前提是该资源的状态没有发生新的更改。
For example, when state changes occur in bursts, the server can skip some notifications, send the notifications in non-confirmable messages, and make sure that the client observes the latest state change by repeating the last notification in a confirmable message when the burst is over.
例如，当状态更改以突发方式发生时，服务器可以跳过一些通知，以不可确认消息的形式发送通知，并确保客户端在突发结束时通过重复可确认消息中的最后一个通知来观察最新的状态更改。
The client's acknowledgement of a confirmable notification signals that the client is interested in receiving further notifications. If a client rejects a confirmable or non-confirmable notification with a Reset message, or if the last attempt to retransmit a confirmable notification times out, then the client is considered no longer interested and the server MUST remove the associated entry from the list of observers.
客户对可确认通知的确认表示客户有兴趣接收进一步的通知。如果客户端使用重置消息拒绝可确认或不可确认通知，或者如果上次尝试重新传输可确认通知超时，则认为客户端不再感兴趣，服务器必须从观察者列表中删除相关条目。
Implementation Note: To properly process a Reset message that rejects a non-confirmable notification, a server needs to remember the message IDs of the non-confirmable notifications it sends. This may be challenging for a server with constrained resources. However, since Reset messages are transmitted unreliably, the client must be prepared in case the Reset messages are not received by the server. Thus, a server can always pretend that a Reset message rejecting a non-confirmable notification was lost.
实现说明：要正确处理拒绝不可确认通知的重置消息，服务器需要记住它发送的不可确认通知的消息ID。对于资源受限的服务器来说，这可能是一个挑战。但是，由于重置消息的传输不可靠，因此客户端必须做好准备，以防服务器未收到重置消息。因此，服务器总是可以假装拒绝不可确认通知的重置消息丢失。
If a server does this, it could accelerate cancellation by sending the following notifications to that client in confirmable messages.
如果服务器这样做，它可以通过在可确认消息中向该客户端发送以下通知来加速取消。
A server that transmits notifications mostly in non-confirmable messages MUST send a notification in a confirmable message instead of a non-confirmable message at least every 24 hours. This prevents a client that went away or is no longer interested from remaining in the list of observers indefinitely.
主要以不可确认消息形式发送通知的服务器必须至少每24小时以可确认消息而不是不可确认消息形式发送通知。这可以防止离开或不再感兴趣的客户无限期地留在观察者列表中。
Basic congestion control for CoAP is provided by the exponential back-off mechanism in Section 4.2 of RFC 7252 [RFC7252] and the limitations in Section 4.7 of RFC 7252 [RFC7252]. However, CoAP places the responsibility of congestion control for simple request/ response interactions only on the clients: rate-limiting request transmission implicitly controls the transmission of the responses. When a single request yields a potentially infinite number of notifications, additional responsibility needs to be placed on the server.
CoAP的基本拥塞控制由RFC 7252[RFC7252]第4.2节中的指数退避机制和RFC 7252[RFC7252]第4.7节中的限制提供。然而，CoAP将简单请求/响应交互的拥塞控制责任仅放在客户端上：速率限制请求传输隐式地控制响应的传输。当单个请求产生可能无限多的通知时，服务器需要承担额外的责任。
In order not to cause congestion, servers MUST strictly limit the number of simultaneous outstanding notifications/responses that they transmit to a given client to NSTART (1 by default; see Section 4.7 of RFC 7252 [RFC7252]). An outstanding notification/response is either a confirmable message for which an acknowledgement has not yet been received and whose last retransmission attempt has not yet timed out or a non-confirmable message for which the waiting time that results from the following rate-limiting rules has not yet elapsed.
为了避免造成拥塞，服务器必须严格限制向NSTART发送给给定客户端的同时未完成通知/响应的数量（默认情况下为1；请参阅RFC 7252[RFC7252]第4.7节）。未完成的通知/响应是尚未收到确认且其最后一次重传尝试尚未超时的可确认消息，或者是尚未经过由以下速率限制规则产生的等待时间的不可确认消息。
The server SHOULD NOT send more than one non-confirmable notification per round-trip time (RTT) to a client on average. If the server cannot maintain an RTT estimate for a client, it SHOULD NOT send more than one non-confirmable notification every 3 seconds and SHOULD use an even less aggressive rate when possible (see also Section 3.1.2 of RFC 5405 [RFC5405]).
服务器平均每个往返时间（RTT）不应向客户端发送多个不可确认的通知。如果服务器无法维持客户端的RTT估计值，则不应每3秒发送一个以上的不可确认通知，并应在可能的情况下使用更低的攻击性速率（另请参见RFC 5405[RFC5405]第3.1.2节）。
Further congestion control optimizations and considerations are expected in the future with advanced CoAP congestion control mechanisms.
未来，预计将使用先进的CoAP拥塞控制机制进行进一步的拥塞控制优化和考虑。
The state of an observed resource may change while the number of simultaneous outstanding notifications/responses to a client on the list of observers is greater than or equal to NSTART. In this case, the server cannot notify the client of the new resource state
观察者列表上同时发送给客户端的未完成通知/响应数大于或等于NSTART时，观察到的资源的状态可能会发生变化。在这种情况下，服务器无法通知客户端新的资源状态
immediately but has to wait for an outstanding notification/response to complete first.
立即，但必须等待未完成的通知/响应才能首先完成。
If there exists an outstanding notification/response that the server transmits to the client and that pertains to the changed resource, then it is desirable for the server to stop working towards getting the representation of the old resource state to the client and to start transmitting the current representation to the client instead, so the resource state observed by the client stays closer in sync with the actual state at the server.
如果存在服务器发送给客户机且与已更改资源相关的未完成通知/响应，则服务器最好停止向客户机获取旧资源状态的表示，并开始向客户机发送当前表示，因此，客户端观察到的资源状态与服务器上的实际状态保持更紧密的同步。
For this purpose, the server MAY optimize the transmission process by aborting the transmission of the old notification (but not before the current transmission attempt is completed) and starting a new transmission for the new notification (but with the retransmission timer and counter of the aborted transmission retained).
为此，服务器可以通过中止旧通知的传输（但不是在当前传输尝试完成之前）和为新通知启动新传输（但保留中止传输的重传计时器和计数器）来优化传输过程。
In more detail, a server MAY supersede an outstanding transmission that pertains to an observation as follows:
更详细地说，服务器可以取代与观测相关的未完成传输，如下所示：
1. Wait for the current (re)transmission attempt to be acknowledged, rejected, or to time out (confirmable transmission); or, wait for the waiting time to elapse or the transmission to be rejected (non-confirmable transmission).
1. 等待当前（重新）传输尝试被确认、拒绝或超时（可确认传输）；或者，等待等待时间过去或拒绝传输（不可确认传输）。
2. If the transmission is rejected or it was the last attempt to retransmit a notification, remove the associated entry from the list of observers of the observed resource.
2. 如果传输被拒绝或是最后一次尝试重新传输通知，请从观察到的资源的观察者列表中删除相关条目。
3. If the entry is still in the list of observers, start to transmit a new notification with a representation of the current resource state. Should the resource have changed its state more than once in the meantime, the notifications for the intermediate states are silently skipped.
3. 如果该条目仍在观察者列表中，则开始传输表示当前资源状态的新通知。如果资源同时多次更改其状态，则会自动跳过中间状态的通知。
4. The new notification is transmitted with a new Message ID and the following transmission parameters: if the previous (re)transmission attempt timed out, retain its transmission parameters, increment the retransmission counter, and double the timeout; otherwise, initialize the transmission parameters as usual (see Section 4.2 of RFC 7252 [RFC7252]).
4. 使用新消息ID和以下传输参数传输新通知：如果上一次（重新）传输尝试超时，保留其传输参数，增加重传计数器，并加倍超时；否则，按常规初始化变速箱参数（见RFC 7252[RFC7252]第4.2节）。
It is possible that the server later receives an acknowledgement for a confirmable notification that it superseded this way. Even though this does not signal consistency, it is valuable in that it signals the client's further interest in the resource. The server therefore should avoid inadvertently removing the associated entry from the list of observers.
服务器稍后可能会收到一个确认通知，确认它以这种方式取代了可确认的通知。尽管这并不表示一致性，但它很有价值，因为它表示客户对资源的进一步兴趣。因此，服务器应避免无意中从观察者列表中删除相关条目。
A client may be interested in a resource in the namespace of a server that is reached through a chain of one or more CoAP intermediaries. In this case, the client registers its interest with the first intermediary towards the server, acting as if it was communicating with the server itself, as specified in Section 3. It is the task of this intermediary to provide the client with a current representation of the target resource and to keep the representation updated upon changes to the resource state, as specified in Section 4.
客户端可能对通过一个或多个CoAP中介链到达的服务器命名空间中的资源感兴趣。在这种情况下，客户端向服务器的第一个中介注册它的兴趣，就像它正在与服务器本身通信一样，如第3节所述。该中介体的任务是向客户机提供目标资源的当前表示，并在资源状态发生变化时保持表示的更新，如第4节所述。
To perform this task, the intermediary SHOULD make use of the protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the next hop towards the server. If the response returned by the next hop doesn't include an Observe Option, the intermediary MAY resort to polling the next hop or MAY itself return a response without an Observe Option.
要执行此任务，中介体应使用本文档中指定的协议，扮演客户机的角色，并在目标资源中注册自己对服务器的下一个跃点的兴趣。如果下一个跃点返回的响应不包括观察选项，则中间层可能会诉诸于轮询下一个跃点，或者自身可能会返回一个没有观察选项的响应。
The communication between each pair of hops is independent; each hop in the server role MUST determine individually how many notifications to send, of which message type, and so on. Each hop MUST generate its own values for the Observe Option in notifications and MUST set the value of the Max-Age Option according to the age of the local current representation.
每对跳之间的通信是独立的；服务器角色中的每个跃点必须分别确定要发送多少通知、哪种消息类型等。每个跃点必须为通知中的“观察”选项生成自己的值，并且必须根据本地当前表示的年龄设置“最大年龄”选项的值。
If two or more clients have registered their interest in a resource with an intermediary, the intermediary MUST register itself only once with the next hop and fan out the notifications it receives to all registered clients. This relieves the next hop from sending the same notifications multiple times and thus enables scalability.
如果两个或多个客户端已向中介体注册了他们对资源的兴趣，则中介体必须仅向下一跳注册一次，并将其收到的通知扇出给所有已注册的客户端。这样可以避免下一个跃点多次发送相同的通知，从而实现可伸缩性。
An intermediary is not required to act on behalf of a client to observe a resource; an intermediary MAY observe a resource, for example, just to keep its own cache up to date.
中介机构无需代表客户观察资源；例如，中介可以观察资源，只是为了使自己的缓存保持最新。
See Appendix A.2 for examples.
示例见附录A.2。
A web link [RFC5988] to a resource accessible over CoAP (for example, in a link-format document [RFC6690]) MAY include the target attribute "obs".
指向可通过CoAP访问的资源的web链接[RFC5988]（例如，链接格式文档[RFC6690]）可能包括目标属性“obs”。
The "obs" attribute, when present, is a hint indicating that the destination of a link is useful for observation and thus, for example, should have a suitable graphical representation in a user interface. Note that this is only a hint; it is not a promise that
“obs”属性（当存在时）是一个提示，指示链路的目的地对于观察是有用的，因此，例如，应该在用户界面中具有合适的图形表示。请注意，这只是一个提示；这不是一个承诺
the Observe Option can actually be used to perform the observation. A client may need to resort to polling the resource if the Observe Option is not returned in the response to the GET request.
“观察”选项实际上可用于执行观察。如果GET请求的响应中没有返回Observe选项，则客户端可能需要轮询资源。
A value MUST NOT be given for the "obs" attribute; any present value MUST be ignored by parsers. The "obs" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
不能为“obs”属性指定值；解析器必须忽略任何当前值。“obs”属性在给定链路值中不得出现多次；解析器必须忽略第一个事件之后出现的事件。
The security considerations in Section 11 of [RFC7252], the CoAP specification, apply.
CoAP规范[RFC7252]第11节中的安全注意事项适用。
Observing resources can dramatically increase the negative effects of amplification attacks. That is, not only can notifications messages be much larger than the request message, but the nature of the protocol can cause a significant number of notifications to be generated. Without client authentication, a server therefore MUST strictly limit the number of notifications that it sends between receiving acknowledgements that confirm the actual interest of the client in the data; i.e., any notifications sent in non-confirmable messages MUST be interspersed with confirmable messages. Note that an attacker may still spoof the acknowledgements if the confirmable messages are sufficiently predictable.
观察资源可以显著增加放大攻击的负面影响。也就是说，不仅通知消息可能比请求消息大得多，而且协议的性质可能导致生成大量通知。因此，在没有客户端身份验证的情况下，服务器必须严格限制在接收确认客户端对数据的实际兴趣的确认之间发送的通知数量；i、 例如，在不可确认消息中发送的任何通知必须散布在可确认消息中。请注意，如果可确认消息具有足够的可预测性，则攻击者仍可能伪造确认。
The protocol follows a best-effort approach for keeping the state observed by a client and the actual resource state at a server in sync. This may have the client and the server become out of sync at times. Depending on the sensitivity of the observed resource, operating on an old state might be a security threat. The client therefore must be careful not to use a representation after its Max-Age expires, and the server must set the Max-Age Option to a sensible value.
该协议遵循尽最大努力保持客户端观察到的状态与服务器上的实际资源状态同步的方法。这可能会导致客户端和服务器有时不同步。根据观察到的资源的敏感性，在旧状态下操作可能会造成安全威胁。因此，客户端必须小心，不要在其最大年龄过期后使用表示，服务器必须将最大年龄选项设置为合理的值。
As with any protocol that creates state, attackers may attempt to exhaust the resources that the server has available for maintaining the list of observers for each resource. Servers may want to apply access controls to this creation of state. As degraded behavior, the server can always fall back to processing the request as a normal GET request (without an Observe Option) if it is unwilling or unable to add a client to the list of observers of a resource, including if system resources are exhausted or nearing exhaustion.
与创建状态的任何协议一样，攻击者可能试图耗尽服务器可用于维护每个资源的观察者列表的资源。服务器可能希望对此状态的创建应用访问控制。作为降级行为，如果服务器不愿意或无法将客户端添加到资源的观察者列表中（包括系统资源耗尽或接近耗尽），则服务器始终可以退回到将请求作为正常GET请求处理（不带观察选项）。
Intermediaries must be careful to ensure that notifications cannot be employed to create a loop. A simple way to break any loops is to employ caches for forwarding notifications in intermediaries.
中介机构必须小心确保不能使用通知来创建循环。打破任何循环的一种简单方法是使用缓存在中介中转发通知。
Resources can be observed over CoAP that is secured by Datagram Transport Layer Security (DTLS) using any of the security modes described in Section 9 of RFC 7252. The use of DTLS is indicated by the "coaps" URI scheme. All notifications resulting from a GET request with an Observe Option MUST be returned within the same epoch of the same connection as the request.
可以通过使用RFC 7252第9节中描述的任何安全模式的数据报传输层安全性（DTLS）保护的CoAP观察资源。DTL的使用由“coaps”URI方案表示。带有观察选项的GET请求产生的所有通知必须在与请求相同连接的相同时间段内返回。
The following entry has been added to the CoAP Option Numbers registry:
以下条目已添加到CoAP选项编号注册表中：
+--------+---------+-----------+
| Number | Name | Reference |
+--------+---------+-----------+
| 6 | Observe | RFC 7641 |
+--------+---------+-----------+
+--------+---------+-----------+
| Number | Name | Reference |
+--------+---------+-----------+
| 6 | Observe | RFC 7641 |
+--------+---------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <http://www.rfc-editor.org/info/rfc5988>.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，DOI 10.17487/RFC5988，2010年10月<http://www.rfc-editor.org/info/rfc5988>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[GOF] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley Professional Computing Series, 1994.
[GOF]Gamma，E.，Helm，R.，Johnson，R.，和J.Vlissides，“设计模式：可重用面向对象软件的元素”，Addison-Wesley专业计算系列，1994年。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，博士。学位论文，加利福尼亚大学，尔湾，2000，<http://www.ics.uci.edu/~fielding/pubs/demission/fielding\u demission.pdf>。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <http://www.rfc-editor.org/info/rfc1982>.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，DOI 10.17487/RFC1982，1996年8月<http://www.rfc-editor.org/info/rfc1982>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，DOI 10.17487/RFC5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes to an HTTP Resource", RFC 5989, DOI 10.17487/RFC5989, October 2010, <http://www.rfc-editor.org/info/rfc5989>.
[RFC5989]Roach，A.，“用于订阅HTTP资源更改的SIP事件包”，RFC 5989，DOI 10.17487/RFC5989，2010年10月<http://www.rfc-editor.org/info/rfc5989>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, DOI 10.17487/RFC6202, April 2011, <http://www.rfc-editor.org/info/rfc6202>.
[RFC6202]Loreto，S.，Saint Andre，P.，Salsano，S.，和G.Wilkins，“双向HTTP中使用长轮询和流的已知问题和最佳实践”，RFC 6202，DOI 10.17487/RFC6202，2011年4月<http://www.rfc-editor.org/info/rfc6202>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<http://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 Cel
3 +----->| Header: GET 0x41011633
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Observe: 0 (register)
7 | |
8 | |
9 ____________ |<-----+ Header: 2.05 0x61451633
10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9
12 | | Max-Age: 15
13 | | Payload: "18.5 Cel"
14 | |
15 | | ____________
16 ____________ |<-----+ Header: 2.05 0x51457b50
17 | 2.05 | 19.2 Cel Token: 0x4a
18 19.2 Cel | | Observe: 16
29 | | Max-Age: 15
20 | | Payload: "19.2 Cel"
21 | |
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 Cel
3 +----->| Header: GET 0x41011633
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Observe: 0 (register)
7 | |
8 | |
9 ____________ |<-----+ Header: 2.05 0x61451633
10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9
12 | | Max-Age: 15
13 | | Payload: "18.5 Cel"
14 | |
15 | | ____________
16 ____________ |<-----+ Header: 2.05 0x51457b50
17 | 2.05 | 19.2 Cel Token: 0x4a
18 19.2 Cel | | Observe: 16
29 | | Max-Age: 15
20 | | Payload: "19.2 Cel"
21 | |
Figure 3: A Client Registers and Receives One Notification of the Current State and One of a New State upon a State Change
图3：客户机注册并接收一个当前状态通知和一个状态更改后的新状态通知
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
22 | |
23 19.2 Cel | | 19.2 Cel
24 | | ____________
25 | X----+ Header: 2.05 0x51457b51
26 | 2.05 | 19.7 Cel Token: 0x4a
27 | | Observe: 25
28 | | Max-Age: 15
29 | | Payload: "19.7 Cel"
30 | |
31 ____________ | |
32 | |
33 19.2 Cel | |
34 (stale) | |
35 | |
36 | |
37 | |
38 +----->| Header: GET 0x41011634
39 | GET | Token: 0xb2
40 | | Uri-Path: temperature
41 | | Observe: 0 (register)
42 | |
43 | |
44 ____________ |<-----+ Header: 2.05 0x61451634
45 | 2.05 | Token: 0xb2
46 19.7 Cel | | Observe: 44
47 | | Max-Age: 15
48 | | ETag: 0x78797a7a79
49 | | Payload: "19.7 Cel"
50 | |
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
22 | |
23 19.2 Cel | | 19.2 Cel
24 | | ____________
25 | X----+ Header: 2.05 0x51457b51
26 | 2.05 | 19.7 Cel Token: 0x4a
27 | | Observe: 25
28 | | Max-Age: 15
29 | | Payload: "19.7 Cel"
30 | |
31 ____________ | |
32 | |
33 19.2 Cel | |
34 (stale) | |
35 | |
36 | |
37 | |
38 +----->| Header: GET 0x41011634
39 | GET | Token: 0xb2
40 | | Uri-Path: temperature
41 | | Observe: 0 (register)
42 | |
43 | |
44 ____________ |<-----+ Header: 2.05 0x61451634
45 | 2.05 | Token: 0xb2
46 19.7 Cel | | Observe: 44
47 | | Max-Age: 15
48 | | ETag: 0x78797a7a79
49 | | Payload: "19.7 Cel"
50 | |
Figure 4: The Client Re-registers after Max-Age Ends
图4:Max Age结束后客户端重新注册
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
51 | |
52 19.7 Cel | | 19.7 Cel
53 | |
54 | | ____________
55 | crash
56 |
57 |
58 |
59 ____________ |
60 |
61 19.7 Cel |
62 (stale) |
63 | reboot____________
64 | |
65 | | 20.0 Cel
66 | |
67 +----->| Header: GET 0x41011635
68 | GET | Token: 0xf9
69 | | Uri-Path: temperature
70 | | Observe: 0 (register)
71 | | ETag: 0x78797a7a79
72 | |
73 | |
74 ____________ |<-----+ Header: 2.05 0x61451635
75 | 2.05 | Token: 0xf9
76 20.0 Cel | | Observe: 74
77 | | Max-Age: 15
78 | | Payload: "20.0 Cel"
79 | |
80 | | ____________
81 ____________ |<-----+ Header: 2.03 0x5143aa0c
82 | 2.03 | 19.7 Cel Token: 0xf9
83 19.7 Cel | | Observe: 81
84 | | ETag: 0x78797a7a79
85 | | Max-Age: 15
86 | |
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
51 | |
52 19.7 Cel | | 19.7 Cel
53 | |
54 | | ____________
55 | crash
56 |
57 |
58 |
59 ____________ |
60 |
61 19.7 Cel |
62 (stale) |
63 | reboot____________
64 | |
65 | | 20.0 Cel
66 | |
67 +----->| Header: GET 0x41011635
68 | GET | Token: 0xf9
69 | | Uri-Path: temperature
70 | | Observe: 0 (register)
71 | | ETag: 0x78797a7a79
72 | |
73 | |
74 ____________ |<-----+ Header: 2.05 0x61451635
75 | 2.05 | Token: 0xf9
76 20.0 Cel | | Observe: 74
77 | | Max-Age: 15
78 | | Payload: "20.0 Cel"
79 | |
80 | | ____________
81 ____________ |<-----+ Header: 2.03 0x5143aa0c
82 | 2.03 | 19.7 Cel Token: 0xf9
83 19.7 Cel | | Observe: 81
84 | | ETag: 0x78797a7a79
85 | | Max-Age: 15
86 | |
Figure 5: The Client Re-registers and Gives the Server the Opportunity to Select a Stored Response
图5：客户端重新注册并使服务器有机会选择存储的响应
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
87 | |
88 19.7 Cel | | 19.7 Cel
89 | |
90 | | ____________
91 ____________ |<-----+ Header: 2.05 0x4145aa0f
92 | 2.05 | 19.3 Cel Token: 0xf9
93 19.3 Cel | | Observe: 91
94 | | Max-Age: 15
95 | | Payload: "19.3 Cel"
96 | |
97 | |
98 +- - ->| Header: 0x7000aa0f
99 | |
100 | |
101 | |
102 | | ____________
103 | |
104 | | 19.0 Cel
105 | |
106 ____________ | |
107 | |
108 19.3 Cel | |
109 (stale) | |
110 | |
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
87 | |
88 19.7 Cel | | 19.7 Cel
89 | |
90 | | ____________
91 ____________ |<-----+ Header: 2.05 0x4145aa0f
92 | 2.05 | 19.3 Cel Token: 0xf9
93 19.3 Cel | | Observe: 91
94 | | Max-Age: 15
95 | | Payload: "19.3 Cel"
96 | |
97 | |
98 +- - ->| Header: 0x7000aa0f
99 | |
100 | |
101 | |
102 | | ____________
103 | |
104 | | 19.0 Cel
105 | |
106 ____________ | |
107 | |
108 19.3 Cel | |
109 (stale) | |
110 | |
Figure 6: The Client Rejects a Notification and Thereby Cancels the Observation
图6：客户端拒绝通知，从而取消观察
CLIENT PROXY SERVER
| | |
| +----->| Header: GET 0x41015fb8
| | GET | Token: 0x1a
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x61455fb8
| | 2.05 | Token: 0x1a
| | | Observe: 42
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+----->| | Header: GET 0x41011633
| GET | | Token: 0x9a
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451633
| 2.05 | | Token: 0x9a
| | | Max-Age: 53
| | | Payload: "ready"
| | |
| |<-----+ Header: 2.05 0x514505fc0
| | 2.05 | Token: 0x1a
| | | Observe: 135
| | | Max-Age: 60
| | | Payload: "busy"
| | |
+----->| | Header: GET 0x41011634
| GET | | Token: 0x9b
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451634
| 2.05 | | Token: 0x9b
| | | Max-Age: 49
| | | Payload: "busy"
| | |
CLIENT PROXY SERVER
| | |
| +----->| Header: GET 0x41015fb8
| | GET | Token: 0x1a
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x61455fb8
| | 2.05 | Token: 0x1a
| | | Observe: 42
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+----->| | Header: GET 0x41011633
| GET | | Token: 0x9a
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451633
| 2.05 | | Token: 0x9a
| | | Max-Age: 53
| | | Payload: "ready"
| | |
| |<-----+ Header: 2.05 0x514505fc0
| | 2.05 | Token: 0x1a
| | | Observe: 135
| | | Max-Age: 60
| | | Payload: "busy"
| | |
+----->| | Header: GET 0x41011634
| GET | | Token: 0x9b
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451634
| 2.05 | | Token: 0x9b
| | | Max-Age: 49
| | | Payload: "busy"
| | |
Figure 7: A Proxy Observes a Resource to Keep its Cache Up to Date
图7：代理观察资源以使其缓存保持最新
CLIENT PROXY SERVER
| | |
+----->| | Header: GET 0x41011635
| GET | | Token: 0x6a
| | | Proxy-Uri: coap://sensor.example/status
| | | Observe: 0 (register)
| | |
|<- - -+ | Header: 0x60001635
| | |
| +----->| Header: GET 0x4101af90
| | GET | Token: 0xaa
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x6145af90
| | 2.05 | Token: 0xaa
| | | Observe: 67
| | | Max-Age: 60
| | | Payload: "ready"
| | |
|<-----+ | Header: 2.05 0x4145af94
| 2.05 | | Token: 0x6a
| | | Observe: 17346
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+- - ->| | Header: 0x6000af94
| | |
| |<-----+ Header: 2.05 0x51455a20
| | 2.05 | Token: 0xaa
| | | Observe: 157
| | | Max-Age: 60
| | | Payload: "busy"
| | |
|<-----+ | Header: 2.05 0x5145af9b
| 2.05 | | Token: 0x6a
| | | Observe: 17436
| | | Max-Age: 60
| | | Payload: "busy"
| | |
CLIENT PROXY SERVER
| | |
+----->| | Header: GET 0x41011635
| GET | | Token: 0x6a
| | | Proxy-Uri: coap://sensor.example/status
| | | Observe: 0 (register)
| | |
|<- - -+ | Header: 0x60001635
| | |
| +----->| Header: GET 0x4101af90
| | GET | Token: 0xaa
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x6145af90
| | 2.05 | Token: 0xaa
| | | Observe: 67
| | | Max-Age: 60
| | | Payload: "ready"
| | |
|<-----+ | Header: 2.05 0x4145af94
| 2.05 | | Token: 0x6a
| | | Observe: 17346
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+- - ->| | Header: 0x6000af94
| | |
| |<-----+ Header: 2.05 0x51455a20
| | 2.05 | Token: 0xaa
| | | Observe: 157
| | | Max-Age: 60
| | | Payload: "busy"
| | |
|<-----+ | Header: 2.05 0x5145af9b
| 2.05 | | Token: 0x6a
| | | Observe: 17436
| | | Max-Age: 60
| | | Payload: "busy"
| | |
Figure 8: A Client Observes a Resource through a Proxy
图8：客户机通过代理观察资源
Acknowledgements
致谢
Carsten Bormann was an original author of this document and is acknowledged for significant contribution to this document.
Carsten Bormann是本文件的原始作者，并因对本文件的重大贡献而受到认可。
Thanks to Daniele Alessandrelli, Jari Arkko, Peter A. Bigot, Angelo P. Castellani, Gilbert Clark, Esko Dijk, Thomas Fossati, Brian Frank, Bert Greevenbosch, Jeroen Hoebeke, Cullen Jennings, Matthias Kovatsch, Barry Leiba, Salvatore Loreto, Charles Palmer, Akbar Rahman, Zach Shelby, and Floris Van den Abeele for helpful comments and discussions that have shaped the document.
感谢Daniele Alessandrelli、Jari Arkko、Peter A.Bigot、Angelo P.Castellani、Gilbert Clark、Esko Dijk、Thomas Fossati、Brian Frank、Bert Greevenbosch、Jeroen Hoebek、Cullen Jennings、Matthias Kovatsch、Barry Leiba、Salvatore Loreto、Charles Palmer、Akbar Rahman、Zach Shelby、，以及Floris Van den Abele对形成该文件的有益评论和讨论。
This work was supported in part by Klaus Tschira Foundation, Intel, Cisco, and Nokia.
这项工作得到了克劳斯TSHIRA基金会、英特尔、思科和诺基亚的支持。
Author's Address
作者地址
Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
克劳斯·哈特克大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63905
Email: hartke@tzi.org
Phone: +49-421-218-63905
Email: hartke@tzi.org