Kraus Achim (INST/ECS4)
2017-04-10 07:49:55 UTC
Hello CORE,
I have some questions according the intended message flow for an observe (RFC7641) which uses CON notifies and the resource is changing while retransmitting the notify and waiting for the ACK. I got aware that (at least one) implementation just modifies the payload in that case leaving the MID an retransmission time from the already pending notify.
Sequence:
CoAP client CoAP server
---------- GET R, CON, MID 1, TOKEN ABCD, Observe 0 ------------>
<-------- 2.05, ACK, MID 1, TOKEN ABCD, Observe 10, "state 1" -------------
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------ (R changed from "state 1" to "state 2")
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------ (retransmission, because ACK missing)
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 14, "state 3" ------------ (R changed from "state 2" to "state 3")
---------- ACK, MID 65 ------------>
So:
Is it intended to (re-)use a MID with a modified message? (I personally would say, this is a NO GO!).
Should the retransmission timing/counter from the first notify be continued?
Should this continuing also prevent the second change to be send delayed with the next retransmission?
Or should the second change simply wait until the first timeout all retransmission?
There may be even different answers/intended usage, depending on the usage of the CON notify:
If it's used the test the liveliness of the observe or
If it's used to ensure (in my opinion a pseudo) safe state transfer
My personal favorite would be, just cancel the first CON notify and start a new one with the updated payload
immediately (new MID, new retransmission setup with reset counter and timeout).
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ECS4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 711 811-58139
***@bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
I have some questions according the intended message flow for an observe (RFC7641) which uses CON notifies and the resource is changing while retransmitting the notify and waiting for the ACK. I got aware that (at least one) implementation just modifies the payload in that case leaving the MID an retransmission time from the already pending notify.
Sequence:
CoAP client CoAP server
---------- GET R, CON, MID 1, TOKEN ABCD, Observe 0 ------------>
<-------- 2.05, ACK, MID 1, TOKEN ABCD, Observe 10, "state 1" -------------
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------ (R changed from "state 1" to "state 2")
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------ (retransmission, because ACK missing)
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 14, "state 3" ------------ (R changed from "state 2" to "state 3")
---------- ACK, MID 65 ------------>
So:
Is it intended to (re-)use a MID with a modified message? (I personally would say, this is a NO GO!).
Should the retransmission timing/counter from the first notify be continued?
Should this continuing also prevent the second change to be send delayed with the next retransmission?
Or should the second change simply wait until the first timeout all retransmission?
There may be even different answers/intended usage, depending on the usage of the CON notify:
If it's used the test the liveliness of the observe or
If it's used to ensure (in my opinion a pseudo) safe state transfer
My personal favorite would be, just cancel the first CON notify and start a new one with the updated payload
immediately (new MID, new retransmission setup with reset counter and timeout).
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ECS4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 711 811-58139
***@bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn