Protocols based on UDP transport imply that the connection may not be inherently reliable. To compensate for reliability issues, CoAP introduces two message types that differ by either requiring acknowledgment or not. An additional feature of this approach is that messages can be asynchronous. 

In total there are only four messages in CoAP:

• Confirmable (CON): Requires an ACK. If a CON message is sent an ACK must be received within a random time interval between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR). If the ACK is not received, the sender transmits the CON message over and over at exponentially increasing intervals until it receives the ACK or a RST. This essentially is the CoAP form of congestion control. There is a maximum number of attempts set by MAX_RETRANSMIT. This is the resiliency mechanism to compensate for the lack of resiliency in UDP. 
• Non-confirmable (NON): Requires no ACK. Essentially a fire-and-forget message or broadcast.
• Acknowledgement (ACK): Acknowledges a CON message. The ACK message can piggyback along with other data.
• Reset (RST): Indicates that a CON message has been received but the context is missing. The RST message can piggyback along with other data.

CoAP is a RESTful design using request/response messages piggybacked on CoAP messages. This allows for greater efficiency and bandwidth preservation, as shown in the following figure:

The graphic shows three examples of CoAP non-confirmable and confirmable request/response transactions. These are enumerated and described as follows:

• Non-confirmable request/response (left):  A message broadcast between client A and B using the typical HTTP GET construct. B reciprocates with Content data sometime later and returns the temperature of 20 degrees celsius. 
• Confirmable request/response (middle):  Included is the Message-ID, a unique identifier for each message. The Token represents a value that must match during the duration of the exchange. 
• Confirmable request/response (right): Here the message is confirmable. Both client A and B will wait for an ACK after each message exchange. To optimize communication, Client B can elect to piggyback the ACK with the returned data as shown in the far right.

The actual log of CoAP transactions can be seen in the Copper Firefox extension on Firefox version 55: 

The retransmission process is illustrated in the following figure:

While other messaging architecture requires a central server to propagate messages between clients, CoAP allows messages to be sent between any CoAP client including sensors and servers. CoAP includes a simple caching model. Caching is controlled through response codes in the message header. An option number mask will determine if it is a cache key. The Max_Age option is used to control cache element lifetimes and ensure freshness of the data. That is, Max_Age sets the maximum time a response can be cached for before it must be refreshed. Max_Age defaults to 60 seconds and can span up to 136.1 years. Proxies play a role in caching; for example, a sleeping edge sensor may use a proxy to cache data and to preserve power. 

The CoAP message header is uniquely designed for maximum efficiency and bandwidth preservation. The header is four bytes in length with a typical request message taking only 10 to 20-byte headers. This is typically 10x smaller than an HTTP header. The structure consists of Message Type Identifiers (T), which must be included in each header along with an associated unique Message-ID. The Code field is used to signal errors or success states across channels. After the header, all other fields are optional and include variable length Tokens, Options, and Payload:

UDP also can cause duplicate messages to arrive for both CON and NON transmissions. If identical Message_IDs are delivered to a recipient within the prescribed EXCHANGE_LIFETIME, a duplicate is said to exist. This clearly can occur, as shown in the previous figures, when an ACK is missing or dropped and the client retransmits the message with the same Message_ID. The CoAP specification states the recipient should ACK each duplicate message it receives but should only process one request or response. This rule may be relaxed if a CON message transports a request that is idempotent.

As mentioned, CoAP allows for the role of an observer in a system. This is unique as it allows CoAP to behave in a similar manner to MQTT. The observation process allows a client to register for observation and the server will notify the client whenever the resource being monitored changes state. The duration of observation can be defined during registration. Additionally, the observation relationship ends when the initiating client sends a RST or another GET message:

As mention previously, there is no inherent authentication or encryption in the CoAP standard, rather, the user must rely on DTLS to provide that level of security. If DTLS is used then an example URI would be:

    //insecure
    coap://example.net:1234/~temperature/value.xml

    //secure
    coaps://example.net:1234/~temperature/value.xml

CoAP offers resource discovery mechanisms as well. Simply sending a GET request to /.well-known/core will disclose a list of known resources on the device. Additionally, query strings can be used in the request for applying specific filters.