On 20 September 2016 at 15:03, Vinicius Costa Gomes
Just a little background: when I wrote sol-coap, for the Soletta
project, I took the opposite way, I tried to handle everything inside
sol-coap. In the end, some users were coding around some of the
zoap, for now, will stay out of users way, at the cost of some repeated
code. Later, hhen we have a couple of concrete use cases, zoap will
become more opinionated.
- corrupt packet, header incomplete (no message id)There are a couple of points that should be taken into consideration:
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.
Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
- zoap is largely independent of the network stack (by design) and it
doesn't have any buffers of its own;
- zoap doesn't have all the information to handle that correctly, for
example, an application may choose to ignore all invalid packets from
a multicast address, to avoid increasing the noise;
Thanks, I appreciate you taking the time to explain some of the
relevant back ground issues.
But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.
... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?