Hello,
I was looking for a CoAP implementation to use with RIOT. Having looked at both microcoap and nanocoap (gcoap), as far as I could tell both lack observe support. Are there difficulties with implementing this? If there are no blocking issues with it, I might be willing to spent some time trying to get it working.
Koen.
Hi Koen,
Thanks for your interest! I am working actively on Observe support for gcoap/nanocoap. I don’t see a technical difficulty – the biggest issue for me is time to work on it. :-/ My first goal is server-side support. I plan to create a WIP PR within a week or two, so at least there will be a place for discussions. You’ll see a new branch in my repository before then, and I’m happy to discuss at any time.
If you are generally interested in contributing to CoAP within RIOT, both nanocoap and gcoap could use some help. There are a couple of open PRs for work on nanocoap. Certainly it would benefit from more documentation and unit tests, which are a great way to get into the code. I also maintain a wiki about gcoap [1], and also have written up some issues as ‘notes to self’ [2] but would be happy for someone to move them to official RIOT issues. gcoap also needs full-on confirmable messaging support, which actually is a requirement for Observe.
Ken
[1] [2]
Hi Ken,
Sorry for the slow response. Time limitations are also an issue for me.
I'm going to look at the code in the next few weeks when I have time. Besides the work for coap observe, what would be the priority to work on?
Koen
No worries, Koen. I see you’ve been busy elsewhere in the tree. Congrats on the recent merges. Below are my thoughts on priorities, but of course the implementation emerges from everyone’s priorities.
Any CoAP implementation needs to include the base spec, and the Observe and Block extensions. I’m working on Observe for gcoap, and I’ll probably add the CON type with that. Both gcoap and nanocoap need Block support. The Observe spec includes some clever uses of URIs (section 1.4), so just adding Uri-Query option support would be valuable.
I like the choice of implementations within RIOT of nanocoap (class 0/1 devices) and gcoap (class 1/2) devices, so keeping them in sync is valuable, too.
On top of this base, security is critical. RIOT includes a DTLS implementation (transport layer), but interesting work is going into the OSCOAP draft (application layer), too.
Also see the documents in the IETF core working group – monitoring via CORE/COMI (which was my original reason for working on CoAP), pub-sub, HTTP mapping, multicast. Then there is the work from the thing to thing group (T2TRG) and ensuring a protocol like LWM2M works well. Carsten has posted a couple of messages recently about CoAP over serial that would be cool to implement, too. At this level, the priorities really depend on what you need CoAP to do.
Ken