RIOT support - why GNRC specific

[maribu]

I saw that https://github.com/obgm/libcoap/blob/develop/src/coap_io_riot.c support for RIOT was added. This raised two questions:

1. Why is that implementation specific to the GNRC network stack?
   • RIOT provides with the SOCK API a stack independent network API that is very similar to the BSD / POSIX socket API. This would directly allow using libcoap with any network stack supported by RIOT
   • The SOCK API is stable and breaking API changes are unlikely and carefully handled. I don't think that the same is true when interfacing with the GNRC stack on that level.
2. There is a package for libcoap on RIOT, which is horribly out of date. With native RIOT support added to libcoap, it should be pretty straight forward to update it. Is there any interest in maintaining this? It would make use of libcoap much easier for RIOT users.

[obgm]

@maribu Thank your for bringing this up! The reason for using GNRC was that I had to pick something instead of the BSD socket wrapper as that turned out to cause some issues that would have required changes to the socket wrapper itself (i.e., would have required adding more socket-layer options). I do not mind moving to the SOCK API if you think this is the proper way forward.

Regarding the libcoap package in RIOT: I have started updating this in my own branch but did face some issues—possibly related to my use of GNRC. Therefore, I did not yet finish that work. I take it from your request that the work on the DTLS SOCK API has stabilized and is ready to use (this would be prerequisite for me as not having DTLS for CoAP is a dead end IMO).

[maribu]

I take it from your request that the work on the DTLS SOCK API has stabilized and is ready to use (this would be prerequisite for me as not having DTLS for CoAP is a dead end IMO).

@pokgak and @miri64 should be able to give a more definite answer to that than I am. As far as I can see, only TinyDTLS currently implements that API - I personally would wait for a second implementation of that API before counting on it to be stable. (By "stable" I mean "not subject to API changes" here.)

That said, I personally don't think that interfacing with the GNRC network stack below the SOCK API is more stable than DTLS SOCK API is. (Again, "stable" as in "not subject to API changes".) But @miri64 should be able to give a definite answer to that.

[miri64]

That said, I personally don't think that interfacing with the GNRC network stack below the SOCK API is more stable than DTLS SOCK API is. (Again, "stable" as in "not subject to API changes".) But @miri64 should be able to give a definite answer to that.

The GNRC NETAPI basically did not change since my master thesis, while the SOCK API changed significantly (it did not even exist and there was its predecessor conn back than), so in general I would call the GNRC NETAPI more stable in that sense ;-). That said, and also with regards to DTLS (which is not part of GNRC, but uses external libraries), I think sock should be used regardless. I would not however call sock_dtls stable yet, and agree with @maribu that we should at least wait until (or if someone finds the time try to) wolfssl or another DTLS library is ported to sock_dtls and credman.

[obgm]

My experimental update of the libcoap package uses tinydtls via its internal bindings (configured via a pseudo module in RIOT). Would this be a useful contribution to RIOT? (Note that this is not only outdated since I have worked on that code but also has some flaws I would have to investigate.)

[maribu]

Would this be a useful contribution to RIOT?

I'd say yes :-)

[mrdeep1]

There is now support for the latest RIOT code, including a client and server example using TinyDTLS in (waiting to be merged) #1086. It makes use of posix_sockets where possible.