Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [leshan-dev] Continuous data with Lwm2m

Hi,

   See my response below,

Simon

Le 10/03/2017 à 14:35, Martin Scheffler a écrit :
Hi all,

thanks for your replies!

So LwM2M is still in the running for us, the benefits of having a finished high level protocol definitely outweigh the costs of adding support for an acknowledgement chain to an existing implementation.

So after digging a bit through leshan it seems to me there is currently no support for confirmable observation on both client and server side, right?
Would this be an interesting addition?
Currently observation request (server side) is confirmable.
Leshan Server accept confirmable or unconfirmable notification.

Notification (client side) is unconfirmable most of the time. (there is a kind of magic in californium)
You can play with networkconfig to define when you want to send CON or UN but this is a global config.
https://github.com/eclipse/californium/blob/5ef638e341d7b5f6edd48a5ccbfc97a804034a79/californium-core/src/main/java/org/eclipse/californium/core/network/stack/ObserveLayer.java#L68
https://github.com/eclipse/californium/blob/5ef638e341d7b5f6edd48a5ccbfc97a804034a79/californium-core/src/main/java/org/eclipse/californium/core/observe/ObserveRelation.java#L170
If you want a per resource configuration there is nothing like this in Leshan Client for now.

On the server side, maybe the RegistrationListener::updated method could be changed to return a bool to show that the value was successfully consumed, causing the server to send an ack or nack.
Or the RegistrationUpdate class could get an accept() method?
I do not understand what could be the benefits of that ? The server use Piggy back on update this make sense to me.

On the client side things would be a bit different because multiple listeners can observe a resource. So maybe add a callback interface where users can register centrally to get informed about incoming acks?
Or maybe add an ackReceived method to BaseInstanceEnabler?
That way the client can make sure a value was received by an observer before deleting it from memory.
I don't understand, what do you want to delete from memory ?

Cheers,
Martin

2017-03-02 12:36 GMT+01:00 Simon Bernard <contact@xxxxxxxxxxxxxxx>:

In theory you should be able to do that with lwm2m :

* Our devices do continuous measurement of sensor values
 => you should use LWM2M observe
* All values have to be transmitted to the server.
=> you should use CON message for observe response (This is CoAP concept)
* Data should be transmitted in chunks to keep network traffic down.
=> you should use QueueMode + JSON + historical representations( also called notification storing) + CoAP block-wise
* All data chunks should be stored on device until receipt is acknowledged by server.
=> Already said, CON message for acknowledgement, QueueMode + json + historical representations for chunks, CoAP block-wise if your chunk is too large.

One detail, be aware that you can not observe several object in one request. And when you observe an object you should send the complete object on each notification (even if only one resource changed)
(see : https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/76)

There is a lot of specification wording. Please read specifications if its not clear :
http://openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf
https://tools.ietf.org/html/rfc7252
https://tools.ietf.org/html/rfc7641
https://tools.ietf.org/html/rfc7959
(sry about that :/)

In pratice :
=> I don't know if historical representations is well supported by lwm2m implementation. (At leshan this is only supported at server side)
=> There is some issue with observe + NAT. https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/171
=> Be aware that LWM2M currently run over UDP.

To conclude :
if you need interoperability, device management and the limitations above is not blocking for you, you can consider LWM2M.
If not, you should maybe consider to use MQTT over TCP (be aware I'm not an expert about MQTT). If you really need UDP, you can consider to just use a CoAP POST/PUT at client side (probably with block wise as your chunk can be large)

HTH

Simon

Le 02/03/2017 à 09:23, Martin Scheffler a écrit :
Hi folks,
sorry if this is not the right mailing list for this, maybe you can point me at a better place to discuss this?

I am currently evaluating Leshan for use in our upcoming projects, but I am not sure how to achieve this with Lwm2m:

* Our devices do continuous measurement of sensor values
* All values have to be transmitted to the server
* Data should be transmitted in chunks to keep network traffic down
* All data chunks should be stored on device until receipt is acknowledged by server. 

Can this be achieved with Lwm2m? Or would maybe a different protocol be a better fit here? 

Thanks for your help!
Martin Scheffler


_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________ leshan-dev mailing list leshan-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/leshan-dev 
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

Back to the top