Queue mode change following last spec changes

[jvermillard]

Now

Queue Mode offers functionality for a LWM2M Client to inform the LWM2M Server that it may be disconnected for an extended period of time and also when it becomes reachable again.

So the LWM2M spec doesn't specify the need to keep a queue of messages as part of the protocol implementation.

How we change that?

We should plug the "message queue" implementation on top of leshan API. Also Leshan API could provide an API for being informed of the online/offline status of queue mode devices and also to directly fail requests which are sent to offline devices (in place of trying for 2 minutes to send a CoAP message).

[balsmn]

hi Julien,

As Queue Mode is not explicity defined for any queued messages, I propose to complete remove the Queue Mode implementation from Leshan and let the application layer decide what it wants when it receives a timeout for a request (indicating the device is offline) and when it receives an registration-update (online).

[sbernard31]

it sounds good to me.

[sophokles73]

@jvermillard,

I agree that we should remove the queue mode implementation from leshan's core and (if at all) move it on top of it. However, I agree with @balsmn in that we should probably better remove it completely from leshan and instead make sure that an application gets all the information it needs to implement desired behavior for Q devices. My understanding is that this is what you intend to do with

Also Leshan API could provide an API for being informed of the online/offline status of queue mode devices and also to directly fail requests which are sent to offline devices (in place of trying for 2 minutes to send a CoAP message).

I am struggling though with how the leshan server can know about the online/offline status of the device. It seems obvious that it can call back the application about the fact that the device has updated its registration and will therefore be online for at least some time now. However, how does the server know when the device is going to be offline? I can imagine that the leshan server caches the outcome of its latest request to the device and use that information to tell the application that it currently thinks that the device is offline. But for how long would you consider this information valid?

[sbernard31]

I suppose this should be a configurable value and the default value should be something at least equals to MAX_TRANSMIT_WAIT.

[sbernard31]

@balsmn did you start to work on this new (online/offline) API ?

[balsmn]

@sbernard31 yes I started but have not yet completed. I am integrating the new listener API in to RegistrationServiceImpl as an example to start the discussion. But I can also provide the API alone suggested earlier in PR #235 as a separate PR without any concrete use of it. what do you think?

[sbernard31]

I think a new PR with the new interface and your first implementation could be a good start for a discussion :)

[sbernard31]

@balsmn you can create a PR even if this works is not finished, just to start to discuss :)

[sbernard31]

@balsmn we will soon release a 1.0.0M1, I would like to integrate QueueMode in next milestone (M2)

[balsmn]

@sbernard31 After a lots of re-implementation/thinking, I have now pushed the initial API and implementation. It is not fully complete, but a start for our discussions. #265

[sbernard31]

Thx @balsmn, I will look at this.

[chuchiliusandc]

About the discussions, #265, I didn't see the queue that is used to store request ... It's more about discussing the state of the device. How is the term, "Q mode", defined now ?

[sbernard31]

Now the spec says :

"The Queue Mode offers functionality for a LwM2M Client to inform the LwM2M Server that it may be disconnected for an extended period of time and also when it becomes reachable again."

and

"Despite the title of the functionality, i.e. Queue Mode, this specification does not mandate an implementation to use queues nor does it specify where such a queue would exist (or any details of such queuing mechanism)."

You should discuss with OMA if this sounds strange to you.

[sbernard31]

The work in progress about queue mode is available in the queue_mode branch.

[sbernard31]

Thx to the great work of @carlosgp143 which revives the initial work of @balsmn, a first version of QueueMode support is available here #469 and will be soon integrated in master.

Feedbacks are welcomed.

[sbernard31]

A first version of QueueMode is now available in master.

This changes the behavior of lwm2mServer.send() for devices using QueueMode. If Leshan thinks that the device is not here it will not send the request and just raises an exception.

If you want to go back to previous behavior, you can disable this new feature using : LeshanServerBuilder.disableQueueModeSupport.

[chuchiliusandc]

Hi @sbernard31

How does leshan think a device is not here ? Currently, I treat a device is not there if the device didn't reply in time. e.g., the response didn't come back in 30 seconds. My app treats the device is offline.

Thanks

[sbernard31]

We do the same but we are using CoAP MAX_TRANSMIT_WAIT(93s) as "recommended" by the LWM2M spec.

But thanks to @carlosgp143 (1c322bf6efc077c433bc2cfbb6324cd2abce9571), you can now change this value or even use a more dynamic way.

// to set it to 30s
LeshanServerBuilder builder = new LeshanServerBuilder();
builder.setClientAwakeTimeProvider(new StaticClientAwakeTimeProvider(30000));

[chuchiliusandc]

Got it. Does the implementation also contain the queuing part (i.e., saving the requests for later) ? If not, do you think that will be provided later ? Thanks

[sbernard31]

Currently there no implementation about saving request for later.

I think @carlosgp143 want to introduce this kind of feature. From my side and because of my previous experience I'm a bit skeptical that we could do something which could be reused out of the box except maybe for simple use case or demos.

[sbernard31]

I think we can close this issue as queue mode is now integrated in master.

[chuchiliusandc]

Hi sbernard31, What can this new qmode mode do ? Thanks

[sbernard31]

No queue implementation, but a way to monitor the presence of the device to easily implement it on your own.