5.5. Network error handling

Like any software that needs to communicate with other hosts over the network, Anjay needs to be prepared to handle communication errors. This page documents the library’s behavior during various error conditions.

5.5.1. Outgoing request error handling table

The following table describes the behavior of Anjay when various error conditions happen while performing each of the client-initiated operations.

	Request Bootstrap	Register	Update	De-register	Notify (confirmable)
Timeout (DTLS) [1]	Retry DTLS handshake [2]	Retry DTLS handshake [2]	Fall back to Register	Ignored	Cancel observation
Timeout (NoSec) [1]	Abort all communication [3]	Abort registration
Network (e.g. ICMP) error			Fall back to Client-Initiated Bootstrap [4]		Fall back to Client-Initiated Bootstrap [4]
CoAP error (4.xx, 5.xx)			Fall back to Register		n/a
CoAP Reset			Fall back to Client-Initiated Bootstrap [4]		Cancel observation
Internal error					Cancel observation if “Notification storing” is disabled

5.5.2. The “Abort registration” condition

This condition corresponds to the registration failure as used in the Bootstrap and LwM2M Server Registration Mechanisms section of LwM2M Core TS 1.1.

If the ANJAY_WITH_LWM2M11 compile-time configuration option is enabled, the retry procedures as described in that section of the 1.1 TS will be performed, with respect to settings stored in the appropriate Server object instance, or the defaults values listen in the “Registration Procedures Default Values” table. According to this configuration, further failures may result in the “abort all communication” [3] or “fall back to Client-Initiated Bootstrap” [4] condition.

In builds of Anjay that do not support LwM2M 1.1, the “abort registration” condition is equivalent with the “fall back to Client-Initiated Bootstrap” [4] condition.

5.5.3. Other error conditions

• DTLS handshakes are performed by the DTLS backend library used. This includes handling non-fatal errors and retransmissions. In case of no response from the server, DTLS handshake retransmissions are expected to follow RFC 6347, Section 4.2.4. Timeout and Retransmission. The handshake timers can be customized during Anjay initialization, by setting anjay_configuration_t::udp_dtls_hs_tx_params.

  In case of the ultimate timeout, network-layer error, or an internal error during the handshake attempt, Anjay will fall back to Client-Initiated Bootstrap [4] or, if the attempt was to connect to a Bootstrap Server, cease any attempts to communicate with it (note that unless regular Server accounts are available, this will mean abortion of all communication [3]).

• Errors while receiving an incoming request, or any unrecognized incoming packets, will be ignored

• Errors during anjay_download() data transfers will be passed to the appropriate callback handler, see the documentation to anjay_download_finished_handler_t for details.

Footnotes

[1] (1,2)

Retransmissions, as specified in RFC 7252, Section 4.2. Messages Transmitted Reliably, are attempted before performing the actions described above. The transmission parameters that affect specific retransmission timing can be customized during Anjay initialization, by setting the udp_tx_params and sms_tx_params (in versions that include the SMS feature) fields in anjay_configuration_t.

[2] (1,2)

To prevent infinite loop of handshakes, DTLS handshake is only retried if the failed operation was not performed immediately after the previous handshake; otherwise the behavior described in “Timeout (NoSec)” is used.

[3] (1,2,3)

Communication with all servers will be aborted and anjay_all_connections_failed() will start returning true. Operation can be restored by calling anjay_transport_schedule_reconnect() or anjay_enable_server().

[4] (1,2,3,4,5,6)

Client-Initiated Bootstrap will be performed only if all the following preconditions are met:

• a Bootstrap Server Account exists

• no other LwM2M Server has usable connection

• the Bootstrap Server Account has not aborted due to previous errors

Otherwise, further communication with the server with which the operation failed will be aborted. This may cause anjay_all_connections_failed() to start returning true if that was the last operational connection. Connection can be retried by calling anjay_enable_server() or anjay_transport_schedule_reconnect().