Server Failover
This page aims to explain how Leshan Server behave after a restart/crash or reboot.
Here is a short description of what could be persisted or not with Leshan.
- At DTLS/Scandium level : By default there is no persisted state. DTLS session or connection is not persisted. Scandium provide a way to persist Session but we have never tested it. (see below for more details)
- At CoAP/Californium level : The only state which can be persisted is about observation. MID/Token for short living request cannot be persist.
- At LWM2M/Leshan level : we can persist registrations, observations, bootstrap configuration and security information by implemented corresponding store.
What exactly does it mean?
A connection in DTLS contains all the information needed to decrypt a message. Without any DTLS extension a connection is identified by address/port of foreign peer.
So when an encrypted packet is received, server will search if there is a connection associated to this packet, if there is no connection or if the available connection does not allow to decrypt packet, packet will be dropped/ignored. So after restart, all encrypted packets will be dropped. Meaning that clients need to established a new connection by doing a full or abbreviated handshake.
What happens if a server sends a request to a client after restart?
- For queue mode, this should not really happen as it is always client who initiates the connection.
- For "standard/connected" mode, the LWM2M specification is not clear about that but currently Leshan server will try to established a connection to the client : So Leshan server will act as DTLS client.
A session contains a set of negotiated cryptography parameters from which a connection can be created. 1 connection is linked to only 1 session but 1 session could be used to create several connections.
A full handshake create a new session with a corresponding connection. A session can be reused to create new connection using abbreviated handshake (also called session resumption). Session resumption allow to save some cryptographic parameters transfer and computation (saving some latency, CPU and bandwidth). The bandwith benefits is mainly present for X509 where certificates can be very large.
By default session is not persisted. But Scandium provides a way to do that. Look at SessionCache and if your server will act as DTLS client (as explained above), you should probably implements ClientSessionCache too.
Californium handles some states in memory like MID and token. CoAP MID is used to detect duplicates and for optional reliability. CoAP Token is used to match request with response.
Currently Californium does not provide any way to persist this state (except token for notifications).
So what happen after a restart ?
Short answer : "all short living exchange are lost" and "long living exchange(notification) could still be handled".
Detailed answer :
- deduplication of old messages is not possible. Generally this is not an issue as duplicate messages do not cross the DTLS layer as connection is lost...
- retransmission(reliability) of outgoing messages is lost.
- response of request sent before the restart can not be handled.
- for observe, once the relation is established, notification could be handle after a reboot. (see more detailed below)
Registration could be persisted and so could survive to a restart.
Observation could be persisted with registration.
To better understand what happen for observation/notification you could have a look at this.
