You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: