The number of devices going online grows every day. Connecting them all presents new challenges since IoT hardware is often limited in terms of available resources. Cheap, power-efficient microcontrollers with unreliable power sources have to talk to each other over wireless networks with low throughput and high packet loss rate. They usually use lightweight application layer protocols for communication. Some of the popular choices include messaging protocols like MQTT or XMPP, but today we’ll have a look at something quite different. Constrained Application Protocol described in RFC 7252 is specially tailored to the task.

CoAP

It’s based on the familiar client/server model. The idea is to represent accessible data as “resources”. It can be a temperature reading from a thermometer, the amount of battery life left in a device or anything else. A CoAP server makes resources available under human-readable URIs like /thermometers/5. By convention used for discoverability, all resources can be listed by hitting /.well-known/core address. Each resource can also specify a set of options which can be queried on - /.well-known/core?rt=light_switch would list all resources with the rt (resource type) parameter set to light_switch.

Resources can be interacted with using the GET, POST, PUT and DELETE requests. As you might expect, they work just like the HTTP counterparts. This similarity makes it possible to map the requests from one protocol to another and integrate CoAP systems with the Web, which we’ll try to do. Unlike HTTP, to keep things light, communication happens over UDP. Requests can be “confirmable” or “non-confirmable” depending on our needs. Large payloads are handled on the application layer to avoid IP fragmentation through a block-wise transfer.

The most interesting feature is the “observe” option. A client, while making a GET request, can pass a specific flag to start an observation. It is then added by the server to the list of observers of the given resource and continues listening for the server’s responses. It allows us to build systems passively accepting data whenever they come just like the messaging protocols do.

There are other interesting features to explore. Datagrams can be secured with DTLS. There’s also a possibility for multicast and grouping of resources. It is used in one of the biggest and most promising open source IoT frameworks IoTivity sponsored by Open Connectivity Foundation - one of the emerging IoT standards.

#elixir phoenix #coap #iot