Topics

zoap architecture question...


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

Neither the sample/zoap-server application nor the zoap implementation
itself appear to handle the generation of RST messages in response to
message format errors in an initial CON message (or did I miss
something?). Is the intention that the logic to generate such RST
messages will live within the zoap layer or is it intended to be
handled by the layer above?

Cheers
/Marcus


Vinicius Costa Gomes
 

Hi,

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

Hi!

Neither the sample/zoap-server application nor the zoap implementation
itself appear to handle the generation of RST messages in response to
message format errors in an initial CON message (or did I miss
something?). Is the intention that the logic to generate such RST
messages will live within the zoap layer or is it intended to be
handled by the layer above?
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.

But I am waiting for some real usage before adding this.


Cheers
/Marcus
Cheers,
--
Vinicius


Marcus Shawcroft <marcus.shawcroft@...>
 

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:

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

Cheers
/Marcus


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


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Vinicius

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

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;
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.
Understood ;-)

... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?

Cheers
/Marcus




Cheers
/Marcus
Cheers,
--
Vinicius


Nashif, Anas
 

Hi,
Vinicius can say more, but there was an early POC on top of the new stack a few weeks back, the plan is to move to new IP stack for 1.6 and ASAP. https://jira.zephyrproject.org/browse/ZEP-818 covers this.

As for LWM2M, there is no activity on this front yet, but intention and plan are there. See https://jira.zephyrproject.org/browse/ZEP-216.

Anas

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, September 21, 2016 3:33 AM
To: Gomes, Vinicius <vinicius.gomes(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: zoap architecture question...

Hi Vinicius

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

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;
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.
Understood ;-)

... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?

Cheers
/Marcus




Cheers
/Marcus
Cheers,
--
Vinicius