Constrained Application Protocol (CoAP) is a UDP-based transport protocol developed for constrained devices, defined in RFC 7252. These are devices with limited memory, storage and computing power, limited battery power, and low bandwidth.
CoAP is like a limited HTTP, designed for constrained IoT devices. Similar to HTTP, it is client and server-based, where the client makes a request and the server sends a response. Also similar to HTTP, it is based on the REST model.
The REST model is an architectural style that defines a set of constraints to create a uniform interface for communication between client and server. The primary data representation in REST is a resource, which is basically an abstraction of any type of information. Then you can use commands like GET, POST, PUT and DELETE to read, write and manipulate this resource. Every resource has a URI (Uniform Resource Identifier).
The below image illustrates the format of a CoAP message.
It starts with a fixed 4-byte header, which contains
CoAP version – This is set to 1, other values are reserved for future versions.
Type – Indicates if the message is confirmable, non-confirmable, an acknowledgment or reset.
Token length – Indicates the length of the variable-length token field.
Code – Split into two parts, class (0-7) and detail (0-31), where class indicates request, success response or error response and detail gives additional information to the class.
Message ID – Unique ID in network byte order, used to detect duplicates and optionally for reliability.
CoAP messages are transported using UDP, so packets can arrive out of order, appear duplicated, or go missing. For this reason, there is an optional reliability feature implemented by marking the message type as confirmable in the CoAP header. The recipient must then either acknowledge the message or reject it (message is of type reset), using the message ID of the original message.
The CoAP header also has the Code field, which specifies the message class.
In request messages, the different options are:
GET – retrieves the information that currently corresponds to the resource specified in the CoAP request
POST – requests that the server process the information enclosed within the request and either update the target resource or create a new resource with the information if the target resource didn’t already exist.
PUT – similar to a POST request, however, if the resource doesn’t exist, the server has the option to create the resource.
DELETE – requests that the resource specified in the CoAP request be deleted
All CoAP requests also carry a token, a sequence of 0 – 8 bytes, which the server echoes in any response. The token is generated by the client and should be generated so they are unique and random.
In contrast to the message ID, the token is a nontrivial, randomized string to guard against spoofing and can also be used as a client-local identifier. Message IDs are sequentially assigned, and therefore easily guessable.
CoAP defines a number of options that can be included in a CoAP message, in both requests and responses. See RFC 7252 Section 5.4 Options for the full list of options.
For example, a GET request for a resource should include an option specifying the URI to said resource.
Since CoAP uses UDP as the transport protocol, it is possible to secure the communication using Datagram Transport Layer Security (DTLS).
DTLS provides the same features as TLS (confidentiality, integrity, and authenticity) with the added features to deal with the connectionless nature of UDP.
MQTT vs CoAP
In Lesson 4 we covered MQTT, another widely used communication protocol for IoT. Which one to choose for your cellular application depends on various factors.
The two protocols have very different network architectures, as we can see in the image below:
MQTT uses a publish/subscribe method, while CoAP uses request/response. And while MQTT uses a central broker to communicate messages, CoAP has a one-to-one architecture, with no middle element. CoAP uses UDP, which is not as reliable as the TCP-based connection that MQTT uses. However, this also results in a higher power consumption as MQTT has to maintain the connection between the client and the broker at all times. While CoAP has a one-to-one communication model, MQTT supports multiple nodes being connected at once.
As opposed to a TCP-based protocol, CoAP has the advantage of being connection-less, meaning you can communicate between two endpoints without a prior arrangement.
MQTT is ideal for event-based systems, where you have multiple nodes interacting based on for instance their sensor values. CoAP is more suited for systems that monitor state changes, where you can transfer state information between client and server.