Closed qleisan closed 3 years ago
Observes don't guarantee that all changes will be received by the server.
But are they guaranteed to be sent or is it the latest available observation value that is sent when "pmin" expires? I.e. are they supposed to be queued so that (in this case) no state transition is lost (or rather not sent) due to fast transitions...?
The LWM2M 1.1.1 specification section 6.4.2 says "This operation includes the new value of the Object Instance or Resource." My interpretation of the "new value" would be the value when the notify is sent, but I suppose depending on the resource and implementation notifies could be queued.
For a highly constrained device it may not be possible to queue values, so the latest would be sent. For a continuously changing resource, I would also expect the latest value to be sent as the queue may not drain as fast as it is filled. The latest value is generally the most relevant.
For Wakaama I would prefer to keep it simple and always report the latest value.
For the specific case of firmware update, the Update Result resource should be checked when a notification of an Idle State is received to see what happened. A timeout or polling read may also be needed in case notifications are lost.
If I correctly understand the issue. This is about a LWM2M firmware update implementation at LWM2M server side based on observe to watch the state (/5/x/3) resource.
Notification is just best effort to synchronize a resource between CoAP client and server meaning that :
It is expected that all states are reported to the server however this is not the case.
So my understanding is that you can not rely on observe to receive all the state. Observe can just be used as a kind of optimization to reduce latency but the implementation must be designed to work even if you never receive any notification.
In my experience observation bring lot complexity and so I can imagine LWM2M device which does not support it and so this is another reason to not rely (exclusively?) on observe for firmware update.
But are they guaranteed to be sent
At LWM2M server side, we don't care if there are guaranteed to be sent as they are not guaranteed to be received :)
or is it the latest available observation value that is sent when "pmin" expires?
LWM2M pmin is inspired by draft-ietf-core-dynlink-13#section-3.2.1 and it says that :
When present, the minimum period indicates the minimum time, in
seconds, between two consecutive notifications (whether or not the
resource state has changed) ...
A (CoAP) server MAY update the resource state with the last sampled value
that occured during the pmin interval, after the pmin interval
expires.
The author described it like this : ""Regardless of whether the value of the resource changes or not, do not send me its value any quicker than what I have specified for pmin"."
And knowing that CoAP observation spirit is more about trying to sync the "most recent state" than caring about a "complete history" (see https://github.com/eclipse/leshan/wiki/LWM2M-Observe#the-spirit-of-observe-feature), I would say that this is the lastest available observation value.
I.e. are they supposed to be queued so that (in this case) no state transition is lost (or rather not sent) due to fast transitions...?
For reason exposed above, I think queuing it does not make so much sense.
I can see another problem with queuing it. Imagine a pmin set to 10s and the resource state change each 5s. You can send only 1 notify each 10s but you will queue 2 value each 10s, it sounds not so good.
Thanks for your input, it has been useful. Summary of facts relevant to both wakaama and the discussion that initiated this issue are listed below. At this point it is not clear if there is a wakaama code related problem left to solve, I will keep this open some time to get feedback (share with additional people)
lwm2m_resource_value_changed()
and then lwm2m_step()
.lwm2m_step()
is called. This can be altered by using pmin, pmax and other attributesJust some details about CON : Using CON instead of NON notify allow devices to be aware that notify are well received by the server. But this does not resolved the reordering "issue". (relative to see rfc7641#section-3.4) I don't know if every body interpret the CoAP spec like Californium project but the current behavior of this CoAP stack is to ACK the too old notify and then just drop it. By dropping I mean that it is not returned to the application layer. (see https://github.com/eclipse/californium/blob/2.6.1/californium-core/src/main/java/org/eclipse/californium/core/coap/ClientObserveRelation.java#L328)
This issue is reported to me verbally I will investigate and update this issue description if needed. Sharing now to allow fast feedback from others
During firmware update observed resource "state" might make quick transitions from Downloading->Downloaded->IDLE due to failed checksum check. It is expected that all states are reported to the server however this is not the case.
1.1.1 spec §5.1.2