A demo of unicoap
message APIs.
A demo of unicoap
message APIs.
Sample code. This example demonstrates how you can use unicoap
message and options APIs and how to parse PDUs. You can find a demo application in the examples/networking/coap/unicoap_message
folder.
To start, let us assume pdu
is a buffer containing the CoAP PDU.
Next, allocate a result structure.
Then, call one of the message parsers. CoAP supports different transports which is why the CoAP PDU header varies. In this case, let us assume we received the message over UDP or DTLS. In these cases, we use the RFC 7252 PDU format. Using the result structure frees you of needing to allocate options and a message struct and to wire up options with message struct.
Because the header varies, transport-dependent details like the RFC 7252 message type and ID are accessible via the unicoap_message_properties_t::rfc7252 member.
You use the unicoap_message_is_request, unicoap_message_is_response, and unicoap_message_is_signal methods to check whether a given message is a request, response, or signaling message.
The corresponding typed view of the code is accessible through unicoap_message_t::method, unicoap_message_t::status, and unicoap_message_t::signal.
You can also obtain a human-readable constant null-terminated C string. There are also versions available for status codes and signal numbers. To get a string description of the CoAP code without checking the message class first, use unicoap_string_from_code.
The payload and payload size in bytes can be retrieved the unicoap_message_t::payload and unicoap_message_t::payload_size members.
First, let us dump all options to the standard output.
To read options like Content-Format
which can occur no more than once, you use unicoap_options_t::unicoap_options_get_content_format. Read accessors for non-repeatable options are prefixed with unicoap_options_get
.
Options like Uri-Query
can occur more than once. For these types of options, unicoap
defines several convenience accessors. Let us retrieve the first Uri-Query
option.
The first
getter provides a view into the PDU buffer. The returned string is thus not null-terminated.
In the case of URI queries, you can also retrieve queries by name (if they obey the name=value
format).
For a number of repeatable options, such as Uri-Path
, Location-Path
, Uri-Query
, and Location-Query
, unicoap
offers accessors that generate the original, contiguous representation. This means that multiple Uri-Path
options are stitched back together, forming the /original/path
. These accessores do copy. Now, let us create a query string (?a=1&b=2&c=3
).
Alternatively, you can iterate over all query options, avoiding the copy operation and allocation. To do this, you will need to allocate an unicoap_options_iterator_t and initialize it using unicoap_options_iterator_t::unicoap_options_iterator_init. This is the main tool to iterate over options. unicoap
exposes multiple methods for getting the next instance of a repeatable option.
The option iterator can also be used to iterate over all options, regardless of their type.
Since we want to add options to the CoAP message, we need to allocate an options buffer first. To avoid the boilerplate necessary for allocating a helper structure and buffer and the initialization work, you just need to call UNICOAP_OPTIONS_ALLOC and provide the desired buffer capacity.
Now, let us initialize a message. You can either use the designated initializer or initializer function.
To set non-repeatable options like Content-Format
, use unicoap_options_set
accessors.
For repeatable options, unicoap
provides two versions. You can either add multiple instances of an option like Uri-Path
by providing the original, contiguous representation (e.g., the path).
Or, you can add components individually as follows.
The same applies to Uri-Query
.
unicoap
offers versions for both null-terminated C strings and strings without a null-terminator that require a length indication instead. Example: unicoap_options_t::unicoap_options_add_uri_queries and unicoap_options_t::unicoap_options_add_uri_queries_string, or unicoap_options_t::unicoap_options_add_uri_query and unicoap_options_t::unicoap_options_add_uri_query_string.
First, allocate a buffer with a capacity of your choice.
The header format varies depending on the transport. Let's use CoAP over UDP or CoAP over DTLS, i.e., the RFC 7252 format.
Finally, call the serializer appropriate for the transport.