nanocoap_server: use zero-copy network buffer for parsing request#21652
Merged
crasbe merged 2 commits intoRIOT-OS:masterfrom Sep 4, 2025
Merged
nanocoap_server: use zero-copy network buffer for parsing request#21652crasbe merged 2 commits intoRIOT-OS:masterfrom
crasbe merged 2 commits intoRIOT-OS:masterfrom
Conversation
github-actions
bot
added
Area: network
crasbe
added
Type: enhancement
maribu
approved these changes
Aug 19, 2025
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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
Requests larger than
CONFIG_NANOCOAP_SERVER_BUF_SIZEwere previously silently ignored.But we can do better: With
sock_udp_recv_buf_aux()we don't need to copy the request into a separate buffer but can just use the buffer allocated by the network stack.We still need
CONFIG_NANOCOAP_SERVER_BUF_SIZEfor the response as otherwise the size of the request packet would be the limit for the response packet. But this is now both in control of the server, a good server implementation can only use this for the header and keep the payload in a separate buffer.The only problem is that several CoAP handler functions (e.g.
_sha256_handler()) expectpkt->hdrto point to the response buffer and usepkt->hdrandbufinterchangeably.As a workaround, this also sets
pkt->hdr = rbufincoap_build_reply()to accommodate those handler functions.Testing procedure
Issues/PRs references