Re: zoap architecture question...


Vinicius Costa Gomes
 

Hi,

Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes:

On 19 September 2016 at 19:37, Vinicius Costa Gomes
<vinicius.gomes(a)intel.com> wrote:

Hi, Thanks for responding. Its good to see coap moving forward in zephyr.

The plan is that the error handling would live in the layer above. So
yeah, the zoap-server sample right now is lacking in the invalid
messages handling department.

What I see that could be done in the zoap layer is to add a few helper
functions for building the most common types of messages, including
RESET.

This choice implies multiples consumers of the coap protocol, both
client and servers would all duplicate the logic of detecting various
error conditions and responding in an appropriate way. This logic is
reasonably simple, but none trivial. I believe they all need to detect
and deal with the at least the following cases:
I agree that this has a cost in repeated code.

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
"features".

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)
-> 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
upwards?
There are a couple of points that should be taken into consideration:

- 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;

But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.


Cheers
/Marcus
Cheers,
--
Vinicius

Join devel@lists.zephyrproject.org to automatically receive all group messages.