🙏 Your most needed features ?💡

[sbernard31]

trafficstars

Hi all,

@JaroslawLegierski would like to propose some student projects based on Leshan which could be part of Msc / Eng thesis. :man_student:

We would like to take this opportunity to try do something useful for Leshan and its community. So we create this brainstorming discussion aiming to collect any ideas :bulb: about feature/tools that are missing around Leshan :

• What is currently missing in Leshan ?
• What would you like to change ?
• What new feature do you need ?
• Any tools missing around LWM2M when using Leshan ?

Anything which could be directly included in Leshan or new project based on it.

Do not hesitate to share ideas even if you think this does not perfectly match for a student project. This is brainstorming ! :slightly_smiling_face: And even if some ideas will not fit for student projects, it may be used to improve Leshan anyway.

[jvermillard]

in leshan demo r/w/o at the object level (we only have it at instance level)

[sbernard31]

Maybe some works around Interoperability tests.

• This could just be about adding interoperability tests in Leshan.
• OR maybe more about a new project where anyone could contribute its LWM2M implementation to pass interoperability tests all together.

There is some discussion about that at Wakaama repository : https://github.com/eclipse/wakaama/issues/617

Note that currently Wakaama seems not so active anymore... so maybe we should first identify against what we can do this interoperability tests... :grin:

[sbernard31]

By the past, I implemented a kind of "LWM2M client simulator" based on Leshan : https://github.com/sbernard31/benchmark-clients.

I know that currently @jvermillard used it. But maybe it should be improved ? :shrug:

[sbernard31]

I guess a common use case for LWM2M developer is to write tests. (either to tests client or server implementation) Maybe, we could create/provide a component with an API oriented for tests ? (not sure it makes sense :thinking: )

[sbernard31]

Maybe out of scope but for now we have not so much documentation. And the documentation is stored in wiki. That was fine when we had only 1 version and so only 1 API. But with future release, I think we should find another way to manage documentation.

[jvermillard]

By the past, I implemented a kind of "LWM2M client simulator" based on Leshan : https://github.com/sbernard31/benchmark-clients.

I know that currently @jvermillard used it. But maybe it should be improved ? shrug

Would be cool to make it a first class module in the project with a server counter part so we can easily start and get baseline values quickly

[JaroslawLegierski]

We have one more idea from @Warmek. For MQTT protocol we can find in Internet MQTT clients with graphical user interface such as mqtt-explorer maybe good idea would be to add GUI to leshan-client-demo ? (or create LwM2M client with GUI based on Leshan).

[jvermillard]

Another idea: integrate a fuzz testing solution, like: https://google.github.io/oss-fuzz/

[eabase]

DTLS 1.2 was officially released 2012. DTLS 1.3 was officially released 2022.

Maybe time to update and future proof. The list of advantages of DTLS 1.3 over 1.2 is huge and important, in particular in regard to security and power saving.

So fully supporting LwM2M 1.2 is an absolutely minimal expectation.

[Sylphe88]

We do have a need in the coming weeks/months around EST and the fact that long thread #1135 was stale made us sad when we decided to settle for LwM2M with Leshan!

[JaroslawLegierski]

By the past, I implemented a kind of "LWM2M client simulator" based on Leshan : https://github.com/sbernard31/benchmark-clients.

I know that currently @jvermillard used it. But maybe it should be improved ? 🤷

Maybe we can develop this tool in and implement as a plugin for Apache Jmeter ?

[sbernard31]

I vaguely remember that @msangoi tried to implement a Jmeter plugin by the past but If I remember well he doesn't reuse Leshan but Californium directly.

It exists a lwm2m-jmeter project and they did same choice.

So not sure Leshan client is really adapted/ready to do that :shrug: but maybe this is related to https://github.com/eclipse/leshan/issues/1386#issuecomment-1405056003

[JaroslawLegierski]

I vaguely remember that @msangoi tried to implement a Jmeter plugin by the past but If I remember well he doesn't reuse Leshan but Californium directly.

It exists a lwm2m-jmeter project and they did same choice.

If there is already exitst a plugin for JMeter then it doesn't make sense to create next one such project

So not sure Leshan client is really adapted/ready to do that 🤷 but maybe this is related to #1386 (comment)

When it comes to API based test tool are you thinking of something like this:

?

[sbernard31]

When it comes to API based test tool are you thinking of something like this:

Nope. I was thinking about an oriented test Java API which could be easily used in automatic tests. A more low level API than current one which could be used to write tests. E.g. If you want to test a LWM2M server maybe you need this kind of API :

response = clientTest.register(... .. )
assertThat(response).is... ... ;

response = clientTest.update(... ... )
assertThat(response).is... ... ;

coapResponse = clientTest.send(aMalformedCoapRequest) // to test server behavior
... ...

clientTest.onRequest(new ReadRequest()).return(new ReadResponse( ....));

I didn't think too much about it, so this is clearly not a specification but more example to try to share the idea. Maybe If you want to discus more about this we should create a dedicate issue ?

(Note that: I don't think reusing demo for real automatic test is a good idea, even if I know that some people do that)

[jakubsobolewskisag]

I'd love to see SNI support both in Server and in the Client.

[Nick-The-Uncharted]

During performance test, we surely need something like access-log to easily figure out problems. Some problems I have met so far:

1. Frequent gc leading to registration update time out. (our elb can only keep udp session for 10s, time out means offline).
2. We send msg to kafka synchronously, and one day kakfa has heavy load so it response slow (5ms), which leading to CoapServer thread blocked and unable to process registration update in time.

If I am able to provide a UplinkRequestReceiver of my own, access log can be easily implemented.

[sbernard31]

@Nick-The-Uncharted maybe this could help : https://github.com/eclipse-leshan/leshan/issues/696

If this doesn't help or you think we can do better (like making possible to create custom UplinkRequestReceiver please create a dedicated issue and we will talk about it.

[Nick-The-Uncharted]

@Nick-The-Uncharted maybe this could help : #696

If this doesn't help or you think we can do better (like making possible to create custom UplinkRequestReceiver please create a dedicated issue and we will talk about it.

Thank you for reply, I think I can use a ip->request cache to calcuate the duration of request handling.

[Nick-The-Uncharted]

@sbernard31 org.eclipse.californium.core.network.interceptors.MessageInterceptor#sendResponse don't have exchange as parameter, makes it really hard to find out the corresponding request.

If we use a ip->request cache and want to filter some request out (eg. register update request), this becames impossible to log request time.

[sbernard31]

@Nick-The-Uncharted like I said at https://github.com/eclipse-leshan/leshan/issues/1386#issuecomment-1972831336, please if you want to talk about a particular issue. Create a new one or use an already dedicated existing one. (This issue is just to identify most needed feature not to discuss about it)