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)
AbstractThe 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. 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. 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.
Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
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
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]. 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. 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. 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. 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]. 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.
Observer Subject | | | Registration | +------------------->| | | | Notification | |<-------------------+ | | | Notification | |<-------------------+ | | | Notification | |<-------------------+ | | Figure 1: The Observer Design Pattern The observer design pattern is realized in CoAP as follows: 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. Observer: An observer is a CoAP client that is interested in having a current representation of the resource at any given time. 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. 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. 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.
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 Note: In this document, "Cel" stands for "degrees Celsius". 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 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. 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 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 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 <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. 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. RFC2119].
+-----+---+---+---+---+---------+--------+--------+---------+ | 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 Table 1: The Observe Option 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: 0 (register) adds the entry to the list, if not present; 1 (deregister) removes the entry from the list, if present. 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. 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. 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). 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].
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. 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.
Section 5.6 of RFC 7252 [RFC7252]. Both the freshness model and the validation model are supported.
notification with an appropriate ETag Option instead of a 2.05 (Content) notification. 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. 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. The duration of 128 seconds was chosen as a nice round number greater than MAX_LATENCY (Section 4.8.2 of RFC 7252 [RFC7252]).
Section 1.3) as long as the client is on the list of observers. 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. 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.
appropriate response code (such as 4.04 Not Found) and subsequently MUST remove the associated entry from the list of observers of the resource. 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. 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. Section 5.6 of RFC 7252 [RFC7252].
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%.
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. 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. 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. 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]). Further congestion control optimizations and considerations are expected in the future with advanced CoAP congestion control mechanisms.
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). 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. 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. 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]). 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.
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. 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. RFC5988] to a resource accessible over CoAP (for example, in a link-format document [RFC6690]) MAY include the target attribute "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
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. 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. Section 11 of [RFC7252], the CoAP specification, apply. 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. 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. 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. [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>. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <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>. [GOF] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley Professional Computing Series, 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>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <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>. [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>. [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>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <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>. [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>.
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
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
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
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
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
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