Skip to content

Rework of message and option parsing #21

@pulsastrix

Description

@pulsastrix

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 CoapOption type so that it acts as a wrapper around a raw CoAP option (similar to the changes to CoapUris 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_t during PDU setup, coap_opt_t during PDU parsing)
    • Additionally, lifetime issues need to be considered. coap_opt_t instances are basically a view into the underlying PDU, and therefore must not outlive it.
  • Separate CoapMessage, CoapRequest and CoapResponse into a read-only wrapper around coap_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_t and 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_t for basic attributes as well as a coap_optlist_t for setting option values.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions