Open jiangyoudi opened 4 years ago
CoAP is a Simplex protocol, no specify for Duplex. you can refrence here:https://tools.ietf.org/html/rfc7252#section-2.2
Request/Response Model
CoAP request and response semantics are carried in CoAP messages,
which include either a Method Code or Response Code, respectively.
Optional (or default) request and response information, such as the
URI and payload media type are carried as CoAP options. A Token is
used to match responses to requests independently from the underlying
messages (Section 5.3). (Note that the Token is a concept separate
from the Message ID.)
A request is carried in a Confirmable (CON) or Non-confirmable (NON)
message, and, if immediately available, the response to a request
carried in a Confirmable message is carried in the resulting
Acknowledgement (ACK) message. This is called a piggybacked
response, detailed in Section 5.2.1. (There is no need for
separately acknowledging a piggybacked response, as the client will
retransmit the request if the Acknowledgement message carrying the
piggybacked response is lost.) Two examples for a basic GET request
with piggybacked response are shown in Figure 4, one successful, one
resulting in a 4.04 (Not Found) response.
Shelby, et al. Standards Track [Page 12]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Figure 4: Two GET Requests with Piggybacked Responses
If the server is not able to respond immediately to a request carried
in a Confirmable message, it simply responds with an Empty
Acknowledgement message so that the client can stop retransmitting
the request. When the response is ready, the server sends it in a
new Confirmable message (which then in turn needs to be acknowledged
by the client). This is called a "separate response", as illustrated
in Figure 5 and described in more detail in Section 5.2.2.
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figure 5: A GET Request with a Separate Response
Shelby, et al. Standards Track [Page 13]
RFC 7252 The Constrained Application Protocol (CoAP) June 2014
If a request is sent in a Non-confirmable message, then the response
is sent using a new Non-confirmable message, although the server may
instead send a Confirmable message. This type of exchange is
illustrated in Figure 6.
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figure 6: A Request and a Response Carried in Non-confirmable
Messages
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar
manner to HTTP, with the semantics specified in Section 5.8. (Note
that the detailed semantics of CoAP methods are "almost, but not
entirely unlike" [HHGTTG] those of HTTP methods: intuition taken from
HTTP experience generally does apply well, but there are enough
differences that make it worthwhile to actually read the present
specification.)
Methods beyond the basic four can be added to CoAP in separate
specifications. New methods do not necessarily have to use requests
and responses in pairs. Even for existing methods, a single request
may yield multiple responses, e.g., for a multicast request
(Section 8) or with the Observe option [OBSERVE].
URI support in a server is simplified as the client already parses
the URI and splits it into host, port, path, and query components,
making use of default values for efficiency. Response Codes relate
to a small subset of HTTP status codes with a few CoAP-specific codes
added, as defined in Section 5.9.
Hi, recently,i use emqx coap function,I have some question ask for advice. I want to know weather emqx-coap has device control function, I just see device infrom function? if it support control function ,the borker translate mqtt to coap and sent to device? if device send a coap request ,how it guarantee this message synchronous response or how shoule i do to guarantee a synchronous response?