CoAP future brainstorming breakout session 2023

Here are the (rather abridged) notes from the CoAP brainstorming session at the RIOT summit 2023

Summit 2023 breakout: CoAP future brainstorming

Notetaking: emmanuel

  • chrysn: Presents his assorted ideas about driver-based CoAP, possibly on top of existing implementations
  • martine: I need to check in the app if the context format is what I expect. THat’s not good
  • chrysn: the level of abstraction we have is responsible for that. Would be good to have a higher level abstraction. However the dispatch should benefit from being at lower level.
  • martine: yes, in my dns over coap implem it would help quite a bit
  • chrysn: the question is how to do that best, have no concrete ideas yet on that.
  • martine: ideas? input on that? Anyone?
  • chrysn: had a precursor discussion on that in helsinki, but since then, nanocoap and gcoap have drifted farther apart
  • martine: will you use C or Rust? Traits could be a benefit here
  • chrysn: I expect to do some prototyping in Rust, but should also have a non-Rust version. Most importantly we need a concrete proposal
  • Michel: is there a concrete/strong reason to have these interfaces separated?
  • chrysn: gcoap and nanocoap fundamentally differ on client side for instance.
  • Ben: one confusion is about the fact that nanocoap is message parser for… gcoap
  • chrysn: not too much a fan of nanocoap sock approach
  • Ben: could keep the nanocoap sock open and pass around
  • chrysn: but this does not really work for the server side
  • Karl: so downside of gcoap is it requires an extra thread. downside of nanocoap is it is not so practical for server side
  • Ben: seems to me that gcoap is a lot less maintainable than nanocoap
  • chrysn: have different experience, I get timeout if I send a too large message to nanocoap, whereas it is fixed in gcoap (get proper error message) since quite some time
  • chrysn: should we deprecate some stuff here? Do we still have the tools to do that? (We used to do that at some point, although not so easy in C)
  • martine: a macro or something?
  • Emmanuel: need to wrap up
  • chrysn: key takeway: if you use coap, watch out for deprecation messages.
  • martine: session was meant to be more brainstorming anyways :wink:
  • chysn: can Michel send over a pointer to his student exercices with CoAP?
  • martine: maybe we could partly work on that for the upcoming Prague IETF hackathon? With willing students too?

@chrysn where are these slides/ideas?

No slides; my opening point was that

a) the current situation of having two popular CoAP stacks that have highly ambiguous borders and compatibility lines is confusing (and getting worse because while there is some unification going on, at the same time features are added without regard for any unification attempts), and

b) to do any transports outside UDP and DTLS (and the DTLS is already subtly non-compliant), we’ll need some more driver-ish access to messages. As elaborated in my CoAP plumbing talk, lots of things can differ by transport, so all access to messages needs to go through functions that can eventually dispatch to a driver that serializes messages the way the transport needs it. There have been some changes already that reduce how often CoAP users need to reach into a coap_pkt_t struct (rather than treating it as an opaque item), but eventually those will all need to be gone before we can support CoAP over TCP, over BLE or OSCORE – at least without the applications specializing on the transport in the code, which is possible but I’d consider that an abomination (and am deeply saddened that that’s still the only way to use libOSCORE).

1 Like

One point that I was only reminded of again on this weekend: We have a similarly invisible divide between “parsed CoAP packet” and “written CoAP packet”, which both use the same coap_pkt_t, but have different invariants, so that only some functions work with them. That, too, could need some cleanup; unlike on the nanocoap/gcoap side where I advocate unification, I’m unsure as to whether a clear distinction (different types, even if in the implementation it boils down to the same struct) wouldn’t be the better choice.

I agree, I’ve attempted to do this before but because nanoCoAP and GCoAP use coap_pkt_t in subtly different ways, this would solidify the divide between the two implementations (or require an even larger undertaking at unification).