Best way to test queue mode with Leshan server and leshan client demo 2.0 ?

[EmbGangsta]

Question

Hi,

I am evaluating the LwM2M protocol and I am testing the case the client is no longer sending updates during long time and then when back to life on internet and sending an update to server I would like to see the server able to send queued request(s).
I rebuilt the leshan demo client from build under Linux in 2.00 version from commid id afeb712

I can see that in /3/0 device resource the binding mode is U and not UQ. If I put UQ the server tells me that this binding is not supported...
I am testing with the online leshan server at https://leshan.eclipseprojects.io/

I need to make sure this feature works fine because I would like to use LwM2M on some beacons that are travelling at different places, hence they are not always under cellular coverage and sometimes unable to register for a long time.

Please advice

[Ozame]

AFAIK, the queue mode is not yet supported on Leshan client side (see wiki).

Also, on Lwm2m 1.1 specification, the queue mode is indicated as part of the registration parameters (see spec). It was separated from the transport bindings, where it was in 1.0. Note that while this may be communicated to the server, in practice setting the queue mode here does not change the client's behavior.

My understanding is that the client support for queue mode is on the roadmap, but currently you will have to implement it yourself. I have been able to do this by utilizing the Client's start and stop methods with timers, but it has not been without its issues (#1574 )

[sbernard31]

@Ozame thx for your answer.

Some more answer here : #1598 (comment)

I'm not sure we need this issue and #1598

Maybe we can close one and continue discussion on the other ?

[EmbGangsta]

Thanks for your reply.
Indeed the queue mechanism shall be handled by server when client is sending a registration update after a long sleep period, the server shall be able to send the queued requests to the client...
On server side, is there a spec maximum of requests that can be stored until the clients refreshes registration ?

[sbernard31]

Indeed the queue mechanism shall be handled by server when client is sending a registration update after a long sleep period, the server shall be able to send the queued requests to the client...

At as said at #1598 (comment), there is no queue mechanism, it's just a bad naming in specification.

On server side, is there a spec maximum of requests that can be stored until the clients refreshes registration ?

AFAIK, there is no limitation like this. I think this is mainly because LWM2M specification doesn't define if server should store or how it should store request. This is up to implementation.

Maybe we can close one and continue discussion on the other ?

I ask to avoid to talk on 2 different issue and you just continue the discussion on 2 different issues... 😞 #1598 (comment)

[EmbGangsta]

Sure please close this one :)

[sbernard31]

Thx 🙏