Queue mode doesnt seem to work when testing Leshan client 2.0 + server 2.0

[EmbGangsta]

Version(s)

2.00

Which components

Server

Tested With

Leshan client and servers on 2.00

What happened

I am testing the queue mode in this scenario:

• The client is sending updates every 5 min but client is behind a NAT and as it's using UDP, the server is sometimes losing the trace of the client because IP is changing on client side.
• A Read operation is setup on server side with "no timeout" option on a /3/0/9 resource for example.
• When client updates registration, then the read operation is not sent and marked as failed on web interface.

I am missing something ?

How to reproduce

No response

Relevant Output

No response

[sbernard31]

Hi,

At client side

Leshan Client doesn't really implement queue mode.

But with leshan-client-demo you can simulate it with :

-cp, --communication-period=<comPeriodInSec>
                             The communication period in seconds
                             It should be smaller than the lifetime.
                             It will be used even if -b is used.
-q, --queue-mode           Client use queue mode (not fully implemented).
 -r, --rehanshake-on-update Force reconnection/rehandshake on registration
                               update.

This should partially solve your NAT issue. (expect for observations)

At server side

Leshan Server implement queue mode but it does not provide facility to Queue/Store requests.

Note that LWM2M specification says :

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).

This is more a "client initiated mode" than a "queue mode".

Leshan server provides :

• a PresenceService which help to know when the device should be awake/online or not. (This is heuristic because there is no way to know exactly if the client is reachable or not)
• a ClientSleepingException when you try to send a request to a not reachable client.

Then user can build their own way to queue/store request if needed.

[EmbGangsta]

So you are saying that even if queue mode is enabled at client side using the -q parameter, then the server still have to really implement it ??

For now with the -q option a client side (leshan client demo 2.0), if I set a long lifetime of 600s for example, then I see the "zzzzz" sleeping state of the device in the top left corner in server webpage interface, then if I send a read request on some resource I have an error message in the right bottom corner like this :

However I set a timeout of 30min, I would expect that the server will wait for next registration and queue the read request to then send it when client is sending it's registration update ...

[sbernard31]

Yep this is the expected behavior of leshan-server-demo.

Note that leshan-server-demo is just a demo not a production ready server.

then the server still have to really implement it ??

Yes if you are using Leshan Library to create your own LWM2M server; it's up to you to use to store requests how you want and when presence service say your client is awake, just send this requests like you want.

[EmbGangsta]

Ok ! Thanks for confirmation.

Do you know an example of production server that handles queue mode today in the "IoT industry" ?

Actually I am interested to "benchmark" this mode and see if there are some limitations etc ...

Then if we are interested reusing Eclipse Leshan we will use code and update code for our case

[sbernard31]

However I set a timeout of 30min, I would expect that the server will wait for next registration and queue the read request to then send it when client is sending it's registration update ...

Note that it would be very easy to implement an in memory version for leshan-server-demo but I 'm not sure it would be very useful.

Because :

• either people will think this is production ready and will use it where it should not.
• or they understand this is not production ready and so will need to implement in their own way anyway.

Do you know an example of production server that handles queue mode today in the "IoT industry" ?

You mean a library which store request out of the box ? Nope I don't know (but I never searched)
At Semtech/Sierrawireless we are using Leshan in our platform where most of our clients are using QueueMode.

Actually I am interested to "benchmark" this mode and see if there are some limitations etc ...

I'm not sure which kind of limitation you have in mind ?

Then if we are interested reusing Eclipse Leshan we will use code and update code for our case

I'm not sure I get you.
But you should just create your own Java Application with Leshan library as dependency (probably using maven, graddle) and just implement the needed behavior for queue mode on top of the Leshan API. You don't need to update Leshan code.

If you are talking about leshan-server-demo, you should not reuse it for production use case : https://github.com/eclipse-leshan/leshan/wiki/F.A.Q.#could-i-reuse-leshan--demo-

[EmbGangsta]

About limitations, ok there are no limitations in the queue mode concept, this was more on the way it would be implemented by the people who produce/code the server.

Yes I was not planning the change the library code but the leshan demo to add queue mode support for testing, anyway I have to look on some already production platform that supports LwM2M + queue mode (like Vodafone or others).
The goal at the end is to add LwM2M "support" for 2000-10000 beacons connecting with cellular...

[jvermillard]

The goal at the end is to add LwM2M "support" for 2000-10000 beacons connecting with cellular...

I implemented queue mode on top of Leshan for a customer's cellular applications with a larger number of devices, and it worked as expected.

I can understand Simon's concern about queuing in Leshan demo memory, but, well, if people deploy the Leshan demo in prod, they are already doomed.
It would make sense for people like you to try to understand how/when to use queue mode, especially if they aren't aware of UDP/NAT timeout issues.

[sbernard31]

I can understand Simon's concern about queuing in Leshan demo memory, but, well, if people deploy the Leshan demo in prod, they are already doomed.
It would make sense for people like you to try to understand how/when to use queue mode, especially if they aren't aware of UDP/NAT timeout issues.

When I found time, I could try to think how it could looks like. 🤔