emqx-coap has device control function?

[jiangyoudi]

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?

[wwhai]

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.