CoAP over DTLS - unleash the power
CoAP over DTLS - unleash the power
In TLS and DTLS - Commons and Differences I explained some basics about TLS and DTLS. That gave a first impression about the benefits of using DTLS. The challenges are retransmission of messages and preferable small messages. This article explains, how CoAP does both for you.
CoAP is specified in The Constrained Application Protocol (CoAP).
It is split in two layers:
The message transmission uses 4 message types to control the transmission:
- CON, confirmed messages
- NON, non confirmed messages
- ACK, message acknowledge
- RST, message rejection
When sending a confirmed message to an other peer, the sending peer waits for receiving a message acknowledge from the other peer. If within a timeout no such message acknowledge is received, the confirmed messages are retransmitted. Using a maximum number of retransmissions and enlarging the timeouts as backoff. If the other peer receives the message, but is not able to process it, the other peer may also sent a message rejection to stop the first peer from resending the message again. With these COM messages, CoAP easily overcomes some message drops. And, even if one confirmed message can not be transmitted, that doesn’t break a connection.
If it makes sense for your application, just to send a message once and don’t use the CoAP retransmission, then non confirmed messages can be used.
CoAP offers the welknown REST semantic. It is easy to use, if you are already common with that from HTTP. In order to optimze the number of messages, it offers two message flows:
- Piggybacked if the response is immediately available, the ACK could be used to send the response. That makes a exchange using only two IP messages very efficient.
- Separate if the response maybe delayed, a separate ACK and a CON/NON message as response could be used in order to signal the other peer, not to retransmit the request. That makes a exchange also possible, if the time to response varies more than the transmission.
In difference to many other protocols, CoAP makes it easy to support REST in bidirectional way. The request and response messages uses the same basic message format, the difference is mainly the value of the message code field. With that, the difference of a client and a server is effectively small. At least, if the IP message could be exchanged bidirectional, that makes the design of distributed systems much easier. Unfortunately, exactly that IP message exchange fails frequently on the used network environment. If, e.g. NATs are used, they times out quickly and so the peers get unreachable, because the translation entry in the NAT was removed. There may be also sleeping devices, which will also only be reachable for a limited period of time. Both situations still benefits from the bidirectional REST feature build-in CoAP, but you can use it only within the certain time slot.
Simple and Small Messages
A CoAP message is very simple. It consists of a couple of control bytes, options and application-payload. Details are defined in message format.
In difference to HTTP, where additional meta information (header) is added as ASCII, CoAP adds such additional meta information as binary Option. That results in requests an responses with possibly only a couple of bytes (e.g. 60 bytes, using DTLS about 90 bytes). Sure, if the payload itself is large, that doesn’t help. But, if an application benefits from many small messages, CoAP does a perfect job.
CoAP provides both, retransmission and small messages. In my experience, using DTLS together with CoAP realy unleashs the power of both.
List of recommended standards/drafts: