Hey @AchimKraus
I was looking at your repo and was curious, does the server keep the UDP/DTLS connection open when using something like the Connection Identifier?
I’ve been playing around with the OpenSSL bindings in Rust a bit and trying to figure out the best way to maintain the connection and keep handshakes to a minimum. Looks like this isn’t implemented in OpenSSL anyway. (Looks like it is implemented in mbedtls)
does the server keep the UDP/DTLS connection open when using something like the Connection Identifier?
Yes, that’s a very simple and effective trick. Usually the ip-address/port is used to identify the encryption-context of the other peer. RFC 9146 replaces that by the “Connection ID”.
Californium uses that for even more: graceful dtls server restart. Once you use it, you will never miss it again ;-).
Currently there are two implementations I know:
and there is a feature branch in
and very recently, pion (GO), starts to implement it (see Plans for DTLS 1.2 Connection ID)
Beside of the saving not using that much DTLS handshakes, the most impressive improvement is the reliability.
If mainly only two messages are required, that works even in bad signal conditions, where exchanged a couple of flights (TCP or DTLS handshakes) fails.
The new mfw 1.3.5 comes now with:
*** New functionality
For those, who want to test it:
stores and fetches the data in to and from a S3 bucket.
skeleton for other backends.
Nice! Steady progress on improvements.
Looks like the work is complete on Pion! Whenever I look this up you’re everywhere @AchimKraus 
you’re everywhere
That’s the advantage, if you only focus on one extension. Then you’re author, implementer, tester, user, and evangelist ;-).
I had already a short test successful with the pion implementation, but then I had to leave for vacation ;-).
That was my next question! Haha. Glad to see this shaping up!
Exciting stuff. 
These are the types of posts I like to see! Thanks for sharing @AchimKraus
