Expose the full life cycle of a LwM2M client

[TerenceYi]

In our project, we need to monitor the lifecycle processing time from the client side. org.eclipse.leshan.client.observer.LwM2mClientObserver is a unique option for us to implement this feature. So we request to enhance this interface to provide the below methods: void onBootstrapStart(ServerInfo bsserver); void onRegistrationStart(DmServerInfo server, String registrationID); void onUpdateStart(DmServerInfo server, String registrationID); void onDeregistrationStart(DmServerInfo server, String registrationID);

[TerenceYi]

Another option is to enhance the org.eclipse.leshan.core.request.LwM2mRequest and org.eclipse.leshan.core.request.LwM2mResponse recording the request timestamp. On top of that we can calculate the RTT.

[sbernard31]

You could try to play with :

client.getCoapServer().getEndpoints().get(0).addInterceptor(new MessageInterceptor() { ...});

This could allow you to measure RTT at CoAP level. Keep in mind that 1 request at LwM2M level could mean several request at CoAP level (because of CoAP retransmission or blockwise transfer) (There is a Response.getRTT() available in californium don't know if it is reliable)

Tell me if this is enough for you or if you still need modification in Leshan.

[TerenceYi]

thanks for your comments. This is just what I have implemented. What I expected is the Leshan will support those RTT.

Another topic is very limited metrics are exposed by Leshan/Californium

[sbernard31]

What I expected is the Leshan will support those RTT.

How do you see this RTT support ?

Another topic is very limited metrics are exposed by Leshan/Californium

Could you be more specific about what you expect or like to see in Leshan/Californium ?

[TerenceYi]

First Leshan is the best Lwm2m framework that's why we choosing for our start point.

For RTT of register is timestamp2-timestamp1 , Here is one example: timestamp1, CON-POST MID= 2948, Token=9EDA961605EAC3FA, OptionSet={"Uri-Path":"rd", "Content-Format":"application/link-format", "Uri-Query":["b=U","lwm2m=1.0","lt=30","ep=CN-00014028"]}, "</>;rt="oma.lwm2m", </1/".. 53bytes timestamp2, ACK-2.01 MID= 2948, Token=9EDA961605EAC3FA, OptionSet={"Location-Path":["rd","kyEnIQ5Pts"]}, no payload

all confirm message(bootstrap,register-update,de-register,notification) can calculate the RTT. No idea for None-Con message.

For metrics, here is what I'm looking for:

1. The total message sent out from the view of LwM2M/CoAP. Better if we can provide the register/register-update/notification.
2. The total message received from the view of L2M2M/CoAP.
3. How many messages got retrans from the view of CoAP.
4. The bandwidth usage.

If anyone can help on this that's really appreciated.

[sbernard31]

Thx for the feeback. I feel most of the use cases you express are "implementable" with CoAP interceptor. But I will keep this in mind to see if we can improve this. Maybe I should create a dedicated issue for this :thinking:

[TerenceYi]

Thanks for your comments. That's sure RTT/Metrics is not mandatory for Leshan/Californium but is useful from the view of monitoring/troubleshooting. You know especially for UDP. When there are argues of message lost, it is really difficult to work out which side goes wrong.

As a sophisticated framework, will Leshan consider to simplify the monitoring, etc?

[sbernard31]

As a sophisticated framework, will Leshan consider to simplify the monitoring, etc?

This could make sense, but I can guarantee you this will be done at short term, especially because most of monitoring is doable with Californium. Maybe this is more about documentation than code itself ?

[sbernard31]

I create a new issue about that #696 so we can close this one. Thx for your feedbacks !