Request cannot be sent in the class that implements *Listener class

[chuchiliusandc]

Hi,

I have a class that implements RegistrationListener and
try to send the request in the methods, registered and updated.

I found that sending the request there will cause some unstable issues which result in
the devices being cancelled/unregistered.

Can someone send the request in the class or someone must do it through redis channel ?

Thanks :)

[sbernard31]

Hi,

I found that sending the request there will cause some unstable issues which result in
the devices being cancelled/unregistered.

Could you be more precise ? Which kind of issue ?

Can someone send the request in the class

I already do that without issue.

someone must do it through redis channel ?

I do not understand which redis channel ?

[chuchiliusandc]

If one overrides updated and registered methods and sends request in these method,
might cause the devices to be deregistered (this is the issue).
It's easy to spot that if there are many devices and sending in updated method.

You can try to register 500 devices and sending a write request in the updated methods.
You can set the update period to be 27 seconds and you can check if you are able to run it for one day.

I believe one needs to listen LESHAN_REG_UP and, then, send the write request to LESHAN_REQ,
instead of doing it through the overriden updated method.

[sbernard31]

If one overrides updated and registered methods and sends request in these method,
might cause the devices to be deregistered (this is the issue).

Without logs or more details about that this will be difficult to do anything.

You can try to register 500 devices and sending a write request in the updated methods.
You can set the update period to be 27 seconds and you can check if you are able to run it for one day.

What clients implementation are you using ?

I believe one needs to listen LESHAN_REG_UP and, then, send the write request to LESHAN_REQ,
instead of doing it through the overriden updated method.

You seems to talk about LeshanClusterServer. Just to let you know, this is just an experimental work.

[chuchiliusandc]

I feel the issue may be because

1. Q mode is removed from leshan sever
2. UDP is used (order is not guaranteed)
   Then, when sending requests in the overrriden registered and updated methods too frequent and too many (many devices), the order is totally messed up and, then, somehow, the server is in a bad state or something. Finally, cleaner kicked out all the devices whose update requests are not reached in time.

I guess this is why the deregistration happened ...
Is my reasoning making sense ? or ...

Thanks :)

[sbernard31]

FMPOV,

I don't think removal of Q mode was involved in this issue.

About UDP you're right : order is not guaranteed and message can be lost.
=> About registration, this can involved some issue with "bad" client implementation. see eclipse-wakaama/wakaama#24 (comment) for more details about how this should behave (be aware that LWM2M role(client/server) and CoAP role is not alway synchronized). To work around that you could try to send your request several ms later (using timer or scheduled task)

=> About update, the server will clean registration when "lifetime" is out of date. This is up to the client to update before this "lifetime" expired. Some "bad" client implementation" try to send update request with a period of "lifetime" value. This is a mistake because the update request could take time before server receive it (because of packet lost and retransmission). A client should use a period as : LWM2M LIFETIME - CoAP EXCHANGE_LIFE_TIME MAX_TRANSMIT_WAIT.
If you faced clients like that you should implement your own registrationStore and be more lax about registration expiration. (see)

HTH

[chuchiliusandc]

For the client, we are using Java's simulator, not wakaama.

I don't feel client having issue because I can see the log from client.
The client is still trying to send the update.
Just the server doesn't seem to see it.
Hence, the server's cleaner kicked it out. (unregister it)

What do you mean by "client/server and CoAP rolw is not always synchronized" ?
Could you elaborate more on this ?
Why delay sending request will help here ?

I think the client has no issue according to the log.
The client simulator is trying to send update every 27 seconds.
When the server behaves still normally, it will wait for at most 3 times of 27 seconds for the update request.

One more thing, I created many clients in one container in the docker env.
They are sharing one JVM and the same IP address.
Do you think this might cause this unstable issue ? for the underlying communication protocol or impl.

Thanks :)

[sbernard31]

I don't feel client having issue because I can see the log from client.
The client is still trying to send the update.

What I'm saying is : Client can send request too late.

E.g. the client have a lifetime set to 3 minutes. Thats means the server will dropped the registration, after 3 minutes without receiving update request.

Imagine a client which send its update request each 3 minutes or even 2 minutes 30 seconds.
With packet lost + retransmission an update request could take CoAP MAX_TRANSMIT_WAIT(93s) seconds to be sent.
So the update could be received too lately and so the sever will drop the registration.

What do you mean by "client/server and CoAP rolw is not always synchronized"

This is just an hint to better understand the link provided. e.g. A LwM2M client behave as a CoAP client when it send a update request and as a CoAP server when it receive a read request.

When the server behaves still normally, it will wait for at most 3 times of 27 seconds for the update request.

Where do you get that ?

They are sharing one JVM and the same IP address.
Do you think this might cause this unstable issue ? for the underlying communication protocol or impl.

I don't think so.

Are you using security ? and are you in a changing IP environment like behind a NAT ? (see #345)
(I ask this but I'm don't think this could be the problem as you seems to say that update request is sent each 27seconds)

[chuchiliusandc]

Hi sbernard31,

I decided to send out the requests through redis channel, LESHAN_REQ, instead.
It seems to be more reliable than sending it in the overriden registered and updated method.

I have a question.
In order to send it through LESHAN_REQ, I need to have a JSON string.
Could you provide an example of the observe request in JSON string ?

For example, for the write request, it will look like something below.
PUBLISH LESHAN_REQ "{"ep":"DEVICE_123", "ticket":"dalksjlkdfjdlsajdfla", "req":{"kind":"write", "path":"/12345/0/1", "contentFormat":1543,"node": {"kind":"singleResource","type": "STRING","value": "11:59"}}}"

Thanks :)

[sbernard31]

1. Cluster server and so redis channel, is really experimental (we're not working on it, it's not in the short/mid term priority)
2. The redis channel use the internal listener API. So if it's behave better with it, it's just because of lucky timing. Using Listener with delay will probably do the same thing...
3. About json, it should be something like this : "{"ep":"DEVICE_123", "ticket":"dalksjlkdfjdlsajdfla", "req":{"kind":"observe", "path":"/12345/0/1"}}"
   You can look at this DownlinkRequestSerDes.java for more details.

I don't know what is your use case, but there is poor chance than using redis channel was a good idea.

[chuchiliusandc]

Got it :) Thanks :D