Setting DTLS session timeout

[sonny82]

Hi,

First I would like to thank you for all your help so far. I really appreciate it.
I'm using Leshan-2.0.0-M5, which uses Californium 3.0.0-RC1 under the hood.
I would like to set DTLS session timeout to 24h but in Californium3.properties file I can see that there is a DTLS.SESSION_TIMEOUT setting, which currently not supported.

DTLS session timeout. Currently not supported.
Default: 1[h]
DTLS.SESSION_TIMEOUT=1[d]

In Californium code there is this comment:

/**
* DTLS session timeout. Currently not supported!
*
* Californium uses {@link #DTLS_MAX_CONNECTIONS} and
* {@link #DTLS_STALE_CONNECTION_THRESHOLD} in order to keep session as
* along as the resources are not required for fresh connections.
*/

I'm currently using the default settings (DTLS.STALE_CONNECTION_THRESHOLD=30[min], DTLS.MAX_CONNECTIONS=150000).
So, there is no direct way to set DTLS session timeout?
What is the "effective" DTLS session when using above configuration, or if I put it differently, what can I do to set DTLS session to 24h.
Client devices will run in queue mode, they will send registration update once per day.

Best regards,
Sonny

[boaks]

As far as I understand your requirement, you want to ensure, that a session last at least for 24h? Or do you want to have a session last for a maximum of 24h?

• at least: if that's the case, what should happen, if your 150000 connections are full, the least use one is stale for 23:55h, and a new handshake arrives? Fail that new one? Then set the DTLS.STALE_CONNECTION_THRESHOLD to 24h. Otherwise, if the most stale one should be removed, then chose a value less than 24h for DTLS.STALE_CONNECTION_THRESHOLD. You may also consider to increase DTLS.MAX_CONNECTIONS, if you have enough RAM/java heap.

• at most: until now, that was more theoretical requested. If you need that, DTLSConnector.startForEach() provides a callback for that (please obey the discussion in issue First feeback about "clean connection API". #1240).

[sonny82]

OK, I see.
I'm totally new in Californium, Scandium, DTLS and related technologies/frameworks, please forgive me if I'm asking stupid questions :)

My main point was that DTLS session should last at least 24h to reduce the number of handshakes (to preserve device batteries). In general devices will connect only once per day to send registration update.
In my case DTLS.MAX_CONNECTIONS (default value 150.000) is already much higher that expected number of devices (around 13.000).
Could there be more connections/sessions per device? I assume that if device requests a new handshake the old connection is removed?
If that is true than in my case the resources (connections) will never be full.
Please correct me if I'm wrong but in that case a new connection will only be created if the device will request a new handshake, otherwise DTLS session can last for several days (or even indefinitely long)?

BR, Sonny

[boaks]

My main point was that DTLS session should last at least 24h to reduce the number of handshakes

Do you use DTLS CID? If not, you will need (resumption) handshakes, if your ip-adresses are changing.

Could there be more connections/sessions per device? I assume that if device requests a new handshake the old connection is removed?

The point will be, how Scandium knows, that "this handshake" replaces an "existing connection"?
Applying LwM2M rules, e.g. unique "PSK identity" doesn't match the more general case of DTLS.
I'm not sure, if Leshan therefore "cleans up the connection by the principal.
Without such a principal cleanup, the only risk I see, may be, that some devices are executing handshakes much more frequently and so the devices, which complies to the 24h may get removed. Just try it out, you will see, what works better for you.

Please correct me if I'm wrong but in that case a new connection will only be created if the device will request a new handshake, otherwise DTLS session can last for several days (or even indefinitely long)?

Sure, a new connection requires a handshake. And using CID a connection may last for days and weeks.
The left pitfall are situations, where the device can't reach the server. In that case the device don't know, if the dtls connection is lost or not. So the device will try a handshake, and may so have more connections than expected.

[sonny82]

Thanks.
Yes, we use DTLS CID.

[boaks]

With DTLS CID (and no obsolete (resumption) handshakes) my experience is rather good.
Anyway, keep in mind that a couple of misbehaving devices (much more frequently handshaking than expected) and well-behaving client with much less frequent traffic, may result in a scenario, which can not be sorted out by Californium without making assumption about the intended identities. Just try it, and see, if it works.

[sonny82]

Ok, thank you.