Why do DTLS_CONNECTOR_THREAD_COUNT and DTLS_RECEIVER_THREAD_COUNT default to 1?

[ghost]

Background

One of our customers recently got into trouble with his DTLS devices after updating from a LWM2M solution based on Californium 2.0.0 to a new version which internally uses Californium 3.7.0. They have a rather high load on their DTLS endpoints. More specifically, they observed very slow procesing times of DTLS requests, resulting also in handshakes to break:

`2023-08-02 06:32:24.149 WARN 17325 --- [DTLS-Timer-0.0.0.0/0.0.0.0:5784#1] o.e.californium.scandium.DTLSConnector : Handshake with [/X.X.X.171:25815] failed after session was established!

org.eclipse.californium.scandium.dtls.DtlsException: Received new CLIENT_HELLO from X.X.X.X:25815 at org.eclipse.californium.scandium.DTLSConnector.getConnectionForNewClientHello(DTLSConnector.java:2531) at org.eclipse.californium.scandium.DTLSConnector.processNewClientHello(DTLSConnector.java:2463) at org.eclipse.californium.scandium.DTLSConnector.access$1400(DTLSConnector.java:257) at org.eclipse.californium.scandium.DTLSConnector$14.run(DTLSConnector.java:1889)`

After an intensive day, we figured out that Californium as a default only uses only a single DTLS Connector Thread and a single Receiver thread. By increasing those values to a higher number (50 in our case), Californium worked like a charm. The issues with the handshakes dissappeared.

We simply have the question now why 1 is the default of these values?

[boaks]

That depends on the number of CPU cores when creating the "Californium3.properties" file.

CORES = Runtime.getRuntime().availableProcessors()

and then

Defaults

config.set(DTLS_RECEIVER_THREAD_COUNT, CORES > 3 ? 2 : 1);
config.set(DTLS_CONNECTOR_THREAD_COUNT, CORES);

The receiver threads are mainly used for offloading the packets from the UDP stack and parse the records. The connector threads are the used for crypto functions.

Though the use-case are sometimes very different, e.g. small simple client or fat high-performance server, the default is just a first guess. You may adapt it according your needs, either in the "Californium3.properties", using the set-API or using application specific defaults. What's best in your case depends on the intended functionality. If the "Californium3.properties" should be kept functional, then the application specific defaults are the best match. If the "Californium3.properties" is created on a different machine, then just editing and replacing that file works well.