-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Milestone
Description
The current way that messages and options are handled is rather inefficient, as it requires cloning most CoAP options when converting from and to raw messages.
A main reason for why this is necessary is that the message types are mutable, which requires message construction to only happen at the very end.
In order to reduce this overhead and get closer to a "zero-cost abstraction", I propose making the following changes:
- Rewrite the
CoapOptiontype so that it acts as a wrapper around a raw CoAP option (similar to the changes toCoapUris in feat: improve URI handling by basing it on the libcoap type #18).- This might require some more involved changes, as CoAP options are represented in two different structs inside of libcoap (
coap_optlist_tduring PDU setup,coap_opt_tduring PDU parsing) - Additionally, lifetime issues need to be considered.
coap_opt_tinstances are basically a view into the underlying PDU, and therefore must not outlive it.
- This might require some more involved changes, as CoAP options are represented in two different structs inside of libcoap (
- Separate
CoapMessage,CoapRequestandCoapResponseinto a read-only wrapper aroundcoap_pdu_t(again, similar to feat: improve URI handling by basing it on the libcoap type #18) and a write-only builder structure.- The read-only wrappers will read option values as references from the underlying
coap_pdu_tand not store them as copies (as is currently done).- There should be methods both for getting specific options (which would require a search through the option list each time) and for iterating over the list of options (maybe even supporting filters)
- The write-only builders will be a wrapper around an internal
coap_pdu_tfor basic attributes as well as acoap_optlist_tfor setting option values.
- The read-only wrappers will read option values as references from the underlying
JKRhb
Metadata
Metadata
Assignees
Labels
No labels