Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message size discovery #33

Open
chrysn opened this issue Jan 19, 2024 · 0 comments
Open

Message size discovery #33

chrysn opened this issue Jan 19, 2024 · 0 comments

Comments

@chrysn
Copy link
Contributor

chrysn commented Jan 19, 2024

When assembling a message, the application may need to decide how much data it packs into a response -- be it because it is doing non-atomic blockwise, be it because it does pagination.

How can the application tell how much space there is available in a message? If that is dependent on the underlying transport: Can the application provide the transport's size (eg. path MTU), and coap-lite would tell it how much space there is? (The calculation is rather simple -- the delta is 4 + token length, but things do get a bit more complicated when extended token lengths are supported, and to some "4" is already too large of a magic number).

Context: Some applications rely on the coap-message method available_length() to decide how much of a message to populate; coap-lite somewhat correctly reports usize::MAX here -- after all, there's no hard limit and there might be jumbogram or IP fragmentation support. Then of course when they do pick that maximum, the allocation of the Vec fails... and I'm looking for ways to provide more sensible data before declaring this to be an error on the side of the application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant