What is a CoAP Resources Directory?

171 views Asked by At

I understand that CoAP is a lightweight communication protocol used in IoT, and that it supports both client-server and Pub/Sub communications. However, I can't find a nice explanation of the Resource Directory and how it's used in a real life example. I tried reading the RFC but could not understand much. Could you please explain what's the role of the Resource Directory?

Thank you

1

There are 1 answers

0
chrysn On

As for what it is, an RD is a CoAP server that stores and disseminates information about resources (and thus, implicitly, about CoAP devices).

As for how it is used in practice, there are different purposes it can fulfill, for example:

  1. It holds information that is otherwise available only through multicast. For example, when used in a sensor network, a new sensor doesn't need to send a broadcast through the network to discover some service, but it can ask the RD (trusting that the server will have registered there).

  2. It can serve to discover hosts across the Internet. If sensor devices are connected through some unknown uplink (say, in a remote WiFi, or over a cellular link), they don't have a static IP. But if they register at an RD, clients that want to connect to them can find their addresses through the RD.

  3. When extensions such as proxy= are used, they can also double as a proxy to reach devices whose address as per 2. would be firewalled (but because the server opened the connection by registering, it'll stay open).

In a practical example, the way I've used an early version of it for some years was that I had sensor/actuator hubs deployed through different networks (sometimes even within customer LANs). The devices connected to the RD, and a data aggregator monitored which new addresses popped up in the resource lookup, and started collecting data from them. In parallel, a firmware update service monitored the same resource lookup (just with a different filter -- querying for firmware update resources) and started sending firmware to devices that were not up to date.

Another example is OMA LwM2M, which uses the RD very similarly (but there, they don't use the resource lookup as specified, but their RD is directly part of a larger piece of software, and it gathers the data on its own).