net/gcoap: Add detailed message init options #7700
Closed
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
Add support for a confirmable request and standardize token match.
Also, create resend_bufs array to store PDU for resend.
Supports handling an empty message response.
Supports new uses where a coap_pkt_t PDU is not available.
Required if no ACK received, or if a reset (RST) received.
smlng
added
Type: enhancement
|
Closed in favor of #9156. For options, he flexibility and integration with nanocoap overrides the API simplicity. It still might be useful to define a compile-time macro for default messaging type. If you always send messages confirmably, it would save setting the message type. |
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.
This PR implements the fifth step in the confirmable messaging plan in #7192, and depends on #7548. Presently, the gcoap_xxx_init() functions accept parameters that can change from message to message, for example the message code (GET, PUT, etc). On the other hand, some parameters, like message type, expect a default value and are not included in the init functions.
For control over all useful parameters, this PR adds gcoap_req_init_opts() for requests and gcoap_obs_init_opts() for observe notifications. The init opts functions accept a gcoap_send_opts_t structure, which includes all of the available attributes. The documentation for each function describes which attributes are read. This infrastructure will be used in the remaining PRs for confirmable messaging -- synchronous messaging and separate ACK response PRs.
My approach with this PR has been to keep 'simple things easy' while allowing 'difficult things to be possible'. The existing (easy) ...init() functions are unchanged and still useful for many use cases, but when you need full control (difficult), all of the parameters are available to be set in ...init_opts(). The ...init() functions were refactored to use the ...init_opts() functions.