[question] How safe is it to use leshan demo server in production

[oz117]

Hello guys,

We are reworking our implementation of a lwm2m server due to some issues.

We are currently asking ourselves how safe the demo server is and if it can be used in a production environment (with a few changes to feet our needs)?

Thank you 😃

[sbernard31]

This is probably not what you want to hear but I don't advice to use it in production.

See F.A.Q. for more details.

[oz117]

To be honest I am against using it. However, other than saying it is a demo I have no good arguments.

And from What I see you simply say that it is a toy, but a working toy. So I am not sure I understand what it is the reason against using it like so 🤔

[sbernard31]

And from What I see you simply say that it is a toy, but a working toy. So I am not sure I understand what it is the reason against using it like so

A working toy generally doesn't fit production use cases. I would not try to start a taxi carrier with that :

even if it works !

More seriously, my point is : As this is just a demo, this would be very unlikely that the quality level and feature scope match your needs.

As I didn't know your required level of quality or your feature needs, it's hard to me to concretely say what doesn't match.

But there is at least some technical point which seems obvious :

• This is probably not scalable (especially the UI)
• You probably want to use a framework you know and you like at browser side (and surely not a very old version of AngularJS (v1.2.17))
• You probably don't want to use an old version of Bootstrap too.
• Demo uses Gson where Leshan-core library uses minimal-json... so you will bring 2 different json libraries.
• MagicLwM2mValueConverter use in leshan-server-demo is probably not a good idea.
• Most of rest API are probably not really well thought.
• For event from server to browser we use Server sent Event. I'm not sure this is the better choice maybe websocket makes more sense. This maybe deserves more thoughts.
• We don't guarantee any API stability on demo so we could break anything from one release to another.

[oz117]

Ok. I will see what I can do to prevent it from happening.

Thank you for your help :)

I have one last question that has nothing to do with this: where can I find the documentation for the Californium.properties file?
Thanks for the help 😃

[sbernard31]

I have one last question that has nothing to do with this: where can I find the documentation for the Californium.properties file?

I'm not sure a documentation like this exists. The best I find is the code itself. Take a look at NetworkConfig.java

Thanks for the help

You're welcome 😃

[oz117]

Not all of them are commented. For example what do this ones do:

• PROTOCOL_STAGE_THREAD_COUNT
• NETWORK_STAGE_RECEIVER_THREAD_COUNT
• NETWORK_STAGE_SENDER_THREAD_COUNT

From my understanding if I change PROTOCOL_STAGE_THREAD_COUNT it has an impact on how many clients can connect at the same time. However I am uncertain about this. Do you have any insights ?

Thanks

[sbernard31]

Yep,

PROTOCOL_STAGE_THREAD_COUNT is the number of thread used by the CoAP layer. (see #756 (comment))
NETWORK_STAGE_SENDER_THREAD_COUNT and NETWORK_STAGE_RECEIVER_THREAD_COUNT is the number of thread used by UDP connector .
(There are pretty much the same thing for DTLS in DtlsConnectorConfig)

I would not say this is equal to the number of clients which can connect at the same time. This is more the number of task which could be done in parallels.
Generally tasks executing by CoAP layer or connectors threads should not be blocking. (there is some exception like the issue with slow PSKStore: eclipse-californium/californium#878)

[sbernard31]

Should we close this issue now ?

[oz117]

Yes. Thank you for the answers. Closing it now 😃

[sbernard31]

I don't know if you plan to reuse the leshan-bsserver-demo too, but #322 (comment) is a reason to not use it.