CoAP road map thread

I think we should have a higher-level-than-single-PR discussion on where we want to go with CoAP in RIOT.

Rough points that are missing are:

  • Handlers don’t have access to the remote the request came from. That’s good separation of concerns when it comes to network addresses (it’s nice to be able to implement phpinfo(), but bad practice to depend on), but with DTLS suddenly that does become relevant because authentication will be derived from the authorization with that socket. shows this is current once more.

  • Protocol extensibility. CoAP-over-TCP has been around for years now, and has its place in the IoT ecosystem, especially when it comes to competing with MQTT over traversing NATs. (Sure UDP does the same, but the keepalives are way less predictable and more costly).

    For beefier devices, CoAP-over-WS may even be an option to talk to browsers on the LAN directly. (Hard part here is that that practically entails TLS as you don’t want your sites to be shipped over HTTP and a HTTPS site can’t access a non-TLS web socket).

    CoAP-over-TCP has a different header struct, so just doing as with CoAP-over-DTLS and stil just writing to whatever socket impl comes along doesn’t cut it.

    OSCORE support requires a bit more, but once there is a dispatch on how to access the request’s code, MID or token (with consideration for that some of these may not apply to some transports), fanning append-option operations out isn’t much of a change any more.

The hard part is that the Gcoap/nanocoap split isn’t helpful here, as Gcoap not only uses nanocoap’s pkts unwrapped, but also reuses its handler format.

So either we change things in nanocoap, making it not so nano any more, or we make Gcoap pluggable, and nanocoap is one (probably default) backend, but CoAP-over-TCP or OSCORE-on-nanocoap become additional options.

It doesn’t help that even after years of working with this, I still don’t have a good grasp on who is involved in which parts of the stack, how much nanocoap is used without Gcoap, and why we have this separation in the first place.

(We’ve talked about this at the 2019 summit in a short side meeting, AFAIR with Ken, Cenk and Koen around – to my dismay I’ve both failed to follow up there and find any notes I’ve taken :frowning: )


  • Where should we have this discussion?

    I propose we start here, and if it becomes difficult and we have a better overview, I can try to schedule a remote workshop with the stakeholders.

  • Whom to involve?

    [leaving this blank because I have no clue how @-mentions work here and what the user names are; if this were still a mailing list I’d CC a bunch of people but that likely doesn’t translate well]

    [edit: @sssemil because I’ve missed Liboscore: basic OSCORE client example and a good solution there depends on this; also @smlng @hauke @Kaspar @benpicco and @cgundogan now that I have autocompletion]

BR chrysn

PS. apologies for the redundant “thread” in the title; quoting mail reply: “Title is too short (minimum is 15 characters)”


Maybe nanocoap could be left as a not-so-compliant demo and gcoap becomes the maintained normal. Resources are not so scarce any more :wink:

I don’t see this so much as a resource scarcity problem – I’d like to have the ability to run on devices that only have a single MTU-sized buffer that’s used for sending and receiving (which AFAICT neither library can right now).

It’s more a topic of finding the right APIs, which ideallly support both very-constrained and not-so-constrained devices; ideally, all security modes should be supportable with all constraint sets (given that they are designed to be usable with the smallest devices CoAP can be used on).