Comments (7)
Hi David,
I'm pretty sure that I understand your question but let me point the use cases, because I managed the same doubt in the past.
I work mainly on LwM2M 1.0.2
the client registers to the server with lifetime 3600
...
the client sends reg update near 3500
...
after 1000, the server sends a READ/WRITE/EXEC/... to the client
the client doesn't receive the message due to offline (usually NAT block) and the undelivered message is stored in the queue of the server
...
at lifetime time, the client sends reg update (can be seen as "come back online")
the server detects the reg update and sends the messages from the queue (with a delay at application level...for some application is acceptable, for others not)
the max delay is the lifetime
[this is the normal behaviour, lets continue on the flow]
...
after 1000, the server sends a READ/WRITE/EXEC/... to the client
the client doesn't receive the message due to offline (usually NAT block) and the undelivered message is stored in the queue of the server
...
after 200 the client sends a notify to the server.
Can this notify be considered as "come back online"?
For what we understood in the past from the specs, the only way to detect the "online" status is the reg update.
if anyone can review my thoughts and give me a feedback, it would be great.
Sincerely, if also the notify would trigger the sending of the queue, I would be happy because I would reduce the max delay to the distance between the notifies
Since usually the applications send notifies more often than reg updates, this would help to reduce the delay between the sending of the message and its apply
does this use case match your question?
from oma_lwm2m_for_developers.
@giuseppe-melis I think @davidahoward talk about the new Send Operation from LWM2M v1.1 and you are talking about Observe/notify not exactly the same.
But more generally, I see 2 questions here :
- Is Registration Update the only way to refresh registration ?
- Using Queue mode, Is Registration Update the only way to trigger server to send "queued" requests ?
My understanding is :
- Yes. LWM2M-v1.1.1@core§6-2 Client-Registration-Interface
- Yes and more than that each "wake-up" should start by a Registration Update. (So you should not just send a notify without update before) LWM2M-v1.1.1@transport§Figure-6.5-2-Example-of-an-Information-Reporting-exchange-for-Queue-Mode
Why ?
-
I don't know ? Maybe because initially LWM2M Registation Interface is largely inspired by a draft of RFC9176 - CoRE Resource Directory ? (which will be a not so good reason as feature are really different)
OR we can also consider that this brings better separation of concerns. All registration process is handled by Client Registration Interface. So maybe this simple/clearer design justifies the cost of sending an update request from time to time. Knowing that you can have very large Registration lifetime and Update Request is very small, I guess you will not optimize so much by avoiding it. -
Pretty much same answer as for 1)... except that maybe there is most to save if your client wake-up very often to send notification (but if this is a very verbose client, saving an update is maybe not so important ?)
In case of Queue Mode, if you're behind a NAT this also means that each time the device wake-up, it could have a new socket address and if server uses notify as event to send "queued" requests, it should update the registration to change the client socket address too (See #391)
So at the end :
- EITHER, we have a simple way to manage registration like define in current specification.
- OR we could have a more "optimized" way which should be something like : "any data send by a client should refresh registration and eventually update its address if it changes" and is also a sign that client is awake. This will be at cost of more complexity and probably more WRITE access to Registration Store used at server side to persist registration. (as you will update registration much more)
(Note that for coap+tcp brings even more question around all of this : https://github.com/eclipse/leshan/wiki/CoAP-over-TCP)
from oma_lwm2m_for_developers.
Thanks Simon,
very brilliant explanation and sorry for my misunderstanding
from oma_lwm2m_for_developers.
(Note that I'm not part of specification authors, so I maybe missed something)
sorry for my misunderstanding
No problem, I think your answer/question is totally complementary with the original one.
from oma_lwm2m_for_developers.
I'm not sure I understand 2.
- Pretty much same answer as for 1)... except that maybe there is most to save if your client wake-up very often to send notification (but if this is a very verbose client, saving an update is maybe not so important ?)
In case of Queue Mode, if you're behind a NAT this also means that each time the device wake-up, it could have a new socket address and if server uses notify as event to send "queued" requests, it should update the registration to change the client socket address too (See #391)
Are you saying that the client waking up and sending NOTIFY/SEND to server won't work behind a NAT because the server doesn't get the socket address from the received packet?
from oma_lwm2m_for_developers.
Are you saying that the client waking up and sending NOTIFY/SEND to server won't work behind a NAT because the server doesn't get the socket address from the received packet?
This is not what I'm saying. I try to rephrase.
I understand the specification :
- as each wake-up should start by a "Registration Update",
- and requests are "dequeued" on "Registration Update".
I guess that :
- almost all server store client socket address in "registration",
- "Registration update" will update this client socket address in "registration",
- when you send request to a client you use "client socket address" store in "registration".
So if you dequeue on "Registration Update" all works as excepted.
Now, if you use "notify" as event "wake-up" event when you're behind a NAT , I just say that you should not forget that you should also probably update "client socket address" in "registration".
I don't say it's impossible technically, but at least for now I understand this is out of the spec : #391.
I imagine you can use "client socket address" from NOTIFY/SEND packet as destination for "queued request" without updating "client socket address" in "registration" but honestly that smell not so good design to me.
from oma_lwm2m_for_developers.
@davidahoward did you succeed to get more clarification about all of this maybe via other channel ?
from oma_lwm2m_for_developers.
Related Issues (20)
- Object Versioning or Object and Object Instance Versioning? HOT 8
- Does deleting an object instance implicitly delete observations under the instance? HOT 1
- Change of resource type and instance number confirmation HOT 1
- Error in description of resource `DTLS/TLS Ciphersuite` of `Security` Object ? HOT 1
- Core Object implicit versioning between LwM2M patch releases HOT 8
- LWM2M object and resource definition questions HOT 1
- Using negative value in write attributes ? HOT 4
- Does alternatePath be present in payload for SenML ?
- CORS origin issue faced while trying to pull XML response from JS based application HOT 4
- LWM2M Security: SNI with PSK - what does this mean? HOT 2
- Extend or clarify use cases for SenML timestamped values HOT 1
- Overlapped Ressource in Composite Operation HOT 6
- Proposition for more advanced notification class attributes gt and lt HOT 3
- Reporting no known location through the Location object (/6) HOT 21
- how to get the source code of version 1.2 HOT 1
- Does ["notification Storing" when Server is Disabled] really works ? HOT 2
- Report client "unbootstrap" or factory reset reason to the server HOT 3
- SVE Test case 2000 - CoAP POST or CoAP PUT? HOT 1
- SVE Test case 756 - clarification| Is Object Instance allowed in the payload HOT 1
- Installation Issue
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oma_lwm2m_for_developers.