Crate coap_handler[−][src]

The coap-handler crate defines an interface between a CoAP server (that listens for requests on the network and parses the messages) and request handlers (that process the requests and creates responses from them).

The interface is generic over message formats by using the coap-message crate, which allows the handler to construct the response right into the send buffer prepared by the server implementation. By separating the request processing and the response phase, a server can be implemented even on network stacks that have only a single network buffer.

Convenience, example and reference implementations are available in the coap-handler-implementations crate.

Known shortcomings of the current interface are:

  • No consideration for asynchronous processing.

  • Handler mutability is a bit iffy – there’s no way yet for the server to express any promise about only running one handler at a time, thus handlers often hold shared references to a RefCell that is borrow_mut()’d (if no other code that can be concurrent with the CoAP server can have access to the T), or try_borrow_mut()’d (and errs back with a 5.03 Max-Age:0 response).

    Alternatives (where multiple handlers could be built based on a single mutable reference to their data) are being explored.

  • Multiple responses (as, for example, in observations) are not supported.

Modules

helpersDeprecated

The implementations that used to reside here have been moved to coap-handler-implementations; its original version preserved here, but users are encouraged to use the later standalone versions.

implementationsDeprecated

The implementations that used to reside here have been moved to coap-handler-implementations; its original version is still available here, but users are encouraged to use the later standalone versions.

Traits

Handler

A CoAP request handler. This gets called by a CoAP server implementation that the handler is assigned to; the server has the handler digest the request’s data into a RequestData structure, possibly calls estimate_length before allocating a response message, and then asks the handler to populate the allocated response message with data persisted in the RequestData structure.