pkg: add yacoap, Yet another CoAP library #5830

smlng · 2016-09-07T09:04:57Z

YaCoAP is a fork of microcoap , but with extended features

provides server AND client functionality
supports separate ACK and response messages
refined (simpler) API, not microcoap compatible
no dependencies to transport or network layer
simply handles (create, parse) CoAP packets

Further this PR ships with sample code in:

tests/pkg_yacoap
and examples/yacoap_posix

YaCoAP is a fork of microcoap , but with extended features - provides server AND client functionality - supports separate ACK and response messages - refined (simpler) API, not microcoap compatible - no dependencies to transport or network layer - simply handles (create, parse) CoAP packets Further this PR ships with sample code in: - tests/pkg_yacoap - and examples/yacoap_posix

OlegHahm · 2016-09-07T09:07:14Z

no dependencies to transport or network layer

~~How so?~~
Edit: Ah, I see, it provides only packet handling, no protocol logic, right?

And can you tell us about the memory requirements of this implementation?

smlng · 2016-09-07T09:17:58Z

Right, similar to the existing microcoap package, it does not actually send or receive data, it only handles parsing or creation of CoAP packets given as byte buffers. However, besides adding client functionality it also changes the API, so its like microcoap 2.0 - that's why I changed the name and leaf microcoap as is, to not break any existing code or projects using microcoap.

Memory requirements are little higher compared to microcoap, as it provides client handlers. But I haven't done any solid comparison, yet. I was thinking about adding flags to disable code parts, for instance if only server or client functionality is used. But don't know if this is necessary with all the LTO optimization already in place?!

cgundogan · 2016-09-07T09:25:13Z

great one! I can take a peek at the example applications later. Should be interesting how you added the client part and how it is "invoked" by the user.

cgundogan · 2016-09-07T09:25:34Z

examples/yacoap_posix/README.md

@@ -0,0 +1,22 @@
+# examples/yacoap_client_server
+
+This examples shows basic usage of YaCoAP in RIOT. It shows CoAP client and


/examples/example/

cgundogan · 2016-09-07T09:31:23Z

@smlng do you intent to keep yacoap independent from RIOT? Otherwise we could get rid of those patch files by integrating the changes directly into your fork.

smlng · 2016-09-07T09:35:10Z

Yes I'd like to keep it separate, so one can used with non-RIOT-OS projects. The patches delete examples and tests for real Unix/Linux-OS.

However, is it possible to specify a remote branch (not master) instead of commit to pull from?

OlegHahm · 2016-09-07T09:39:04Z

Thanks for the explanation. I didn't realize that basically the whole package is your contribution. Nice one, indeed. 😄

miri64 · 2016-09-07T09:51:49Z

Mh… before I open an issue: Given the fact that we now have a plethora of CoAP libs to choose from, what do you think about a sock_coap API, that would ease app development and make the apps independent of the library chosen.

smlng · 2016-09-07T10:00:40Z

@miri64 Actually I'm waiting for gcoap #5598, which points in that direction. Though its implementation is currently toward gnrc, it should be easily adaptable to conn or future sock API, or not?!

But in the meantime I need something that provides CoAP client functionality, which microcoap doesn't and libcoap is - well ... to be honest I never tried it with RIOT, though on Linux I use it a lot for testing.

cgundogan · 2016-09-07T10:05:37Z

However, is it possible to specify a remote branch (not master) instead of commit to pull from?

the commit that is pointed to by your desired branch should be enough, or did I misunderstand something?

smlng · 2016-09-07T10:07:43Z

@cgundogan yeah, did not thought about that carefully - should work. So we could use that, provided I keep the branch in place, but why not?! That way we get rid of those patches, would you like that better?

miri64 · 2016-09-07T10:20:58Z

@miri64 Actually I'm waiting for gcoap #5598, which points in that direction. Though its implementation is currently toward gnrc, it should be easily adaptable to conn or future sock API, or not?!

I thought the whole idea behind gcoap is that it uses GNRC directly... I guess you misunderstood what I meant: sock_coap wouldn't be a CoAP implementation that uses sock_udp to send CoAP messages, but an API to send CoAP messages independent of the underlying library (similar how sock_ip, sock_tcp and sock_udp aim to be stack independent).

But in the meantime I need something that provides CoAP client functionality, which microcoap doesn't and libcoap is - well ... to be honest I never tried it with RIOT, though on Linux I use it a lot for testing.

I'm all for trying different approaches ;-). But something like sock_coap would take pressure from the users having to decide on an implementation early on.

kaspar030 · 2016-09-07T10:32:47Z

Nice, competition. ;)

smlng · 2016-09-07T11:15:38Z

@miri64 ah yes my fault, I didn't get what you meant in the first place.

Regarding gcoap: I thought there was some discussion on getting it separated from gnrc (later on)? So it would be possible to used it with conn or sock, too?

kb2ma · 2016-09-07T15:30:36Z

Yes, we have discussed separating gcoap from gnrc in that PR. I have been using GNRC because it provides a stable and useful API for my purposes. However, my server reimplementation on nanocoap isolates the interface with the stack. I just added a note on the code to show where/how this happens now.
I have started working on a client implementation because I think that is where the GNRC vs. sock issues will be more important, particularly for handling message timeouts. I really like GNRC's asynchronous messaging for this purpose. I understand some thought and prototyping has been done on this for sock, but the implementation has been deferred. I plan to get the GNRC-based client working, and then we can see how to isolate the stack specifics. I had a working client before the reimplementation for nanocoap, so I hope it won't take too long to get it working again.

@smlng, I am happy to work with you to see how gcoap can be useful for yacoap. Of course, I'm happy to work with everyone to get a good-fitting CoAP in RIOT, including observe, block, and confirmable messaging. :-)

kb2ma · 2016-09-22T16:48:12Z

@smlng, now that I have added client functionality to gcoap, I reviewed how to support use of yacoap within gcoap. I definitely think this is possible, but I'm not sure when is the best time to do it.

gcoap uses nanocoap, so I compared how nanocoap works vs. yacoap. They are quite similar, which makes sense since both have evolved from microcoap. The main differences I see are in the structs -- coap_pkt_t vs. coap_packet_t. Also, yacoap includes a coap_resource_t that nanocoap lacks, but may include at some time in the future.

As @miri64 suggested, I can imagine a common interface. There could be opaque pointer types to hide the struct differences, and some common functions that use those pointers. Maybe some/most of these common functions could be inlined in a header to adapt to implementation specifics.

I'm not sure it makes sense for me to work on this common interface at the moment though. I sense that @kaspar030 's work still is evolving, especially on the client side. You two may want to work through some of those differences in the context of your posix implementations (yacoap.c), kind of like what has happened with sock and conn.

Now that I see an outline for a common interface, I plan to adapt gcoap so there are no roadblocks to it. Then maybe we can revisit farther on down the road.

kaspar030 · 2016-09-22T16:54:23Z

gcoap uses nanocoap, so I compared how nanocoap works vs. yacoap. They are quite similar, which makes sense since both have evolved from microcoap.

Well, nanocoap has been written from scratch. It might look similar to microcoap as that was the only library that I had used before.

biboc · 2016-09-29T12:35:19Z

Hi,

I don't see in any of those CoAP implementation an OBSERVE capability? Why?
https://tools.ietf.org/html/rfc7641
I find this features very useful. Imagine a client subscribing to a resource /temp, if the temperature go over a threshold the client is notified so you don't need any pulling.

smlng · 2016-09-29T12:42:56Z

Hi @biboc, the implementations discussed here are mostly WIP and/or aim for simplicity, implementing the bare standard first. However, libcoap (which is a pkg in RIOT) does support OBSERVE I think? So have a look there for now. I plan to implement observe in the future and I think @kb2ma will do this for gcoap as well. Observe is clearly very useful in a typical sensor scenario, so we need that (and many things more) in RIOT 👍

kaspar030 · 2016-09-29T12:47:33Z

I don't see in any of those CoAP implementation an OBSERVE capability? Why?

I plan on adding OBSERVE to nanocoap. I didn't yet because it increases the complexity a lot. A CoAP server is completely stateless, a client too if it just resends a request until it gets an answer. As soon as OBSERVE comes into play, there's a state somewhere.

kb2ma · 2016-09-29T13:01:43Z

Yes, I plan to add Observe to gcoap. This capability is high on my list
of TODOs.

On 09/29/2016 12:43 PM, Sebastian Meiling wrote:

Hi @biboc https://github.com/biboc, the implementations discussed
here are mostly WIP and/or aim for simplicity, implementing the bare
standard first. However, libcoap http://libcoap.net (which is a pkg
in RIOT) does support OBSERVE I think? So have a look there for now. I
plan to implement observe in the future and I think @kb2ma
https://github.com/kb2ma will do this for gcoap as well. Observe is
clearly very useful in a typical sensor scenario, so we need that (and
many things more) in RIOT 👍

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5830 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ACzsOhGfdSECE94A_62J2acHKZkzn3Yjks5qu7JXgaJpZM4J2scD.

biboc · 2016-09-30T12:23:42Z

Great guys! Yes it increases the difficulty!
I'm looking forward to trying those implementations

miri64 · 2016-10-27T11:11:02Z

examples/yacoap_posix/Makefile

+# Specify the mandatory networking modules for IPv6 and UDP
+USEMODULE += gnrc_ipv6_default
+USEMODULE += gnrc_udp
+USEMODULE += gnrc_conn_udp


Please port to sock (see #6005).

miri64 · 2016-10-31T13:16:59Z

Postponed because of Feature Freeze.

miri64 · 2017-05-23T08:43:25Z

Any plans to continue on this?

smlng · 2017-05-23T08:56:30Z

Mhm, I switched to gcoap for most of my projects. Though this improves on microcoap, it does not provide more features than gcoap.

I'll close this as memo, but would rather work on improving gcoap than bring this into RIOT.

OlegHahm added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: pkg Area: External package ports labels Sep 7, 2016

OlegHahm added this to the Release 2016.10 milestone Sep 7, 2016

cgundogan reviewed Sep 7, 2016
View reviewed changes

smlng added 2 commits September 7, 2016 11:40

typos in README, update boiler plate

7849ee2

correct state on put response

f55dfd0

correct message type on get request

022c1e6

miri64 assigned cgundogan Sep 9, 2016

miri64 reviewed Oct 27, 2016

View reviewed changes

miri64 modified the milestones: Release 2017.01, Release 2016.10 Oct 31, 2016

PeterKietzmann removed this from the Release 2017.01 milestone Jan 13, 2017

smlng closed this May 23, 2017

smlng added the State: archived State: The PR has been archived for possible future re-adaptation label May 23, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pkg: add yacoap, Yet another CoAP library #5830

pkg: add yacoap, Yet another CoAP library #5830

smlng commented Sep 7, 2016

OlegHahm commented Sep 7, 2016 •

edited

Loading

smlng commented Sep 7, 2016 •

edited

Loading

cgundogan commented Sep 7, 2016

cgundogan Sep 7, 2016

cgundogan commented Sep 7, 2016

smlng commented Sep 7, 2016

OlegHahm commented Sep 7, 2016

miri64 commented Sep 7, 2016

smlng commented Sep 7, 2016

cgundogan commented Sep 7, 2016

smlng commented Sep 7, 2016

miri64 commented Sep 7, 2016

kaspar030 commented Sep 7, 2016

smlng commented Sep 7, 2016

kb2ma commented Sep 7, 2016

kb2ma commented Sep 22, 2016

kaspar030 commented Sep 22, 2016 via email

biboc commented Sep 29, 2016

smlng commented Sep 29, 2016

kaspar030 commented Sep 29, 2016 via email

kb2ma commented Sep 29, 2016

biboc commented Sep 30, 2016 •

edited

Loading

miri64 Oct 27, 2016

miri64 commented Oct 31, 2016

miri64 commented May 23, 2017

smlng commented May 23, 2017

		@@ -0,0 +1,22 @@
		# examples/yacoap_client_server

		This examples shows basic usage of YaCoAP in RIOT. It shows CoAP client and

pkg: add yacoap, Yet another CoAP library #5830

pkg: add yacoap, Yet another CoAP library #5830

Conversation

smlng commented Sep 7, 2016

OlegHahm commented Sep 7, 2016 • edited Loading

smlng commented Sep 7, 2016 • edited Loading

cgundogan commented Sep 7, 2016

cgundogan Sep 7, 2016

Choose a reason for hiding this comment

cgundogan commented Sep 7, 2016

smlng commented Sep 7, 2016

OlegHahm commented Sep 7, 2016

miri64 commented Sep 7, 2016

smlng commented Sep 7, 2016

cgundogan commented Sep 7, 2016

smlng commented Sep 7, 2016

miri64 commented Sep 7, 2016

kaspar030 commented Sep 7, 2016

smlng commented Sep 7, 2016

kb2ma commented Sep 7, 2016

kb2ma commented Sep 22, 2016

kaspar030 commented Sep 22, 2016 via email

biboc commented Sep 29, 2016

smlng commented Sep 29, 2016

kaspar030 commented Sep 29, 2016 via email

kb2ma commented Sep 29, 2016

biboc commented Sep 30, 2016 • edited Loading

miri64 Oct 27, 2016

Choose a reason for hiding this comment

miri64 commented Oct 31, 2016

miri64 commented May 23, 2017

smlng commented May 23, 2017

OlegHahm commented Sep 7, 2016 •

edited

Loading

smlng commented Sep 7, 2016 •

edited

Loading

biboc commented Sep 30, 2016 •

edited

Loading