sys/net/nanocoap: Add CoAP over TCP support #21048
Draft
+5,204
−903
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
Area: network
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
2 times, most recently
from
ec3b453 to
765fdf1
Compare
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
from
765fdf1 to
ec5a1f7
Compare
fabian18
reviewed
Jan 9, 2025
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
2 times, most recently
from
eca9688 to
647a436
Compare
github-actions
bot
added
Area: doc
benpicco
added
the
CI: ready for build
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
10 times, most recently
from
a8d54ba to
e374672
Compare
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
from
e374672 to
5dfd557
Compare
Using a constant is easier than explaining where the magic 1 came from in size estimations.
Co-authored-by: mguetschow <[email protected]>
This changes the API of nanocoap with the goal to reduce the expose of
UDP specifics in the API. The plan is to eventually support transports
such as CoAP over TCP and CoAP over WebSocket directly in nanocoap
while sharing most of the code, as e.g. the CoAP Option processing
remains identical. Specifically, the plan is to unlock a transport with
modules and introduce overhead for dispatching to specific transport
only when multiple transports are actually in use.
Support for OSCORE directly in nanocoap is probably not sensible, as
the serialization is very much unlike the other transports. A unified
CoAP API for multiple transports including OSCORE is probably best
implemented on top. But when limited to the boring set of CoAP
transports, we probably can support them well with nanocoap with less
overhead.
Breaking API Changes:
=====================
- `coap_parse()` now returns `ssize_t` instead of `int`
- This function is not really user facing, so the impact should
be limited
- This is useful for stream transports where the buffer may
contain data of more than one packet. The return value contains
the number of bytes actually consumed, which will match the
buffer size for non-stream transports.
API Changes:
============
- `coap_pkt_t` now contains a `uint8_t *buf` pointer instead of a
`coap_hdr_t *hdr` pointer to the beginning of the buffer
- This will also work when the buffer is used by non-UDP
transports
- A deprecated `coap_udp_hdr_t *hdr` has been crammed into
an unnamed `union` with `uint8_t *buf`. For architectures
where pointers have the same memory layout regardless of type
(e.g. all of the supported ones), this will make `hdr` an
alias for `buf`.
- The alias will only be provided if no transport besides UDP is
used in nanocoap. So existing apps will continue to work, new
apps that want to support other transports need to move to
adapt.
- `coap_hdr_t` has been renamed to `coap_udp_hdr_t`
- A deprecated alias was created for deprecation
- `coap_hdr*()` functions have been deprecated
- Equivalent `coap_pkt*()` functions have been created that work
on `coap_pkt_t *` instead of `coap_hdr_t *`
- If non-UDP transports are used, the deprecated `coap_hdr*()`
will probably not be exposed to avoid footguns.
- `coap_build_hdr()` has been renamed to `coap_build_udp_hdr()` and
that works on an `uint8_t *` buffer with a given length, rather than
on a `coap_hdr_t *` with a *figers crossed* length
- a deprecated `coap_build_hdr()` function was added that calls
to `coap_build_udp_hdr()` and has the same signature, so that
users have time to update
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
5 times, most recently
from
e2d9153 to
51ce848
Compare
This allows using and compiling the URL handling functions of sock_util without a network stack used.
This changes the Makefile to easily setup lwIP as network stack, while keeping GNRC as the default. If lwIP is used on one of the larger boards, the app will be build with CoAP over TCP support enabled.
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
from
51ce848 to
3f83cd1
Compare
And test this on native with CoAP over WebSocket+YOLO
And hook up CoAP over WebSocket+YOLO
This implements a trivial reverse proxy that can translate between different transports for CoAP. The proxy is relatively limited in that each proxy instance can only forward one request at a time, reducing throughput and increasing latency significantly. It also strips the forwarded reply of any CoAP options (or sends an error if the response contained critical options).
This proxy allows using CoAP over YOLO with regular CoAP over WebSocket clients by forwarding binary messages received via WebSocket to a given UDP endpoint and the replies back to the WebSocket.
maribu
force-pushed
the
sys/net/nanocoap/transport-tcp
branch
from
3f83cd1 to
d45cae1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This PR adds CoAP over TCP support to nanocoap. It is still work in progress, with many rough edges. This will get updated and filled in with more details as the PR evolves.
Testing procedure
Run
sudo ./dist/tools/tapsetup/tapsetupServer
Wait for the IPv6 address to show up
Client
Then in the RIOT shell run e.g.
Issues/PRs references
Depends on and includes: #20900