9.9. Migrating from Anjay 3.0

9.9.1. Introduction 

Since Anjay 3.0, some minor changes to the API has been done. These change are breaking in the strictest sense, but in practice should not require any changes to user code in typical usage.

9.9.2. Changes in Anjay proper 

9.9.2.1. Behavior of anjay_attr_storage_restore() upon failure 

Deprecated behavior of anjay_attr_storage_restore() which did clear the Attribute Storage if supplied source stream was invalid has been changed. From now on, if this function fails, the Attribute Storage remains untouched. This change is breaking for code which relied on the old behavior, although such code is unlikely.

9.9.2.2. Default (D)TLS version 

When the anjay_configuration_t::dtls_version field is set to AVS_NET_SSL_VERSION_DEFAULT (which includes the case of zero-initialization), Anjay 3.0 and earlier automatically mapped this setting to AVS_NET_SSL_VERSION_TLSv1_2 to ensure that (D)TLS 1.2 is used as mandated by the LwM2M specification.

This mapping has been removed in Anjay 3.1, which means that the default version configuration of the underlying (D)TLS library will be used. This has been done to automatically allow the use of newer protocols and deprecate old versions when the backend library is updated, without the need to update Anjay code. However, depending on the (D)TLS backend library used, this may lead to (D)TLS 1.1 or earlier being used if the server does not properly negotiate a higher version. Please explicitly set dtls_version to AVS_NET_SSL_VERSION_TLSv1_2 if you want to disallow this.

Please note that Mbed TLS 3.0 has dropped support for TLS 1.1 and earlier, so this change will not affect behavior with that library.

9.9.2.3. Persistence of disabled servers 

Core Persistence API (anjay_new_from_core_persistence(), anjay_delete_with_core_persistence()) now also persists disabled servers (either by execution of /1/x/4 or call to function from anjay_disable_server*() family) and the time at which the client shall reconnect them. Previously those disabled servers weren’t persisted at all and freshly initialized client was automatically connecting to them without any regard for specified timeout.

9.9.3. Changes in avs_coap 

9.9.3.1. Changed flow of cancelling observations in case of errors 

CoAP observations are implicitly cancelled if a notification bearing a 4.xx or 5.xx error code is delivered.

In Anjay 3.4.x and earlier, this cancellation (which involves calling the avs_coap_observe_cancel_handler_t callback) was performed before calling the avs_coap_delivery_status_handler_t callback for the specific notification. Since Anjay 3.5.0, this order is reversed, so any code that relies on this logic may break.

This change is only relevant if you are using avs_coap APIs directly (e.g. when communicating over raw CoAP protocol) and in case of notifications intended to be delivered as confirmable. The LwM2M Observe/Notify implementation in Anjay has been updated accordingly.

9.9.4. Changes in avs_commons 

9.9.4.1. Refactor of time handling in avs_sched and avs_coap 

It is now enforced more strictly that time-based events shall happen when the clock reaches at least the expected value. Previously, the tasks scheduled via avs_sched were executed only when the clock reached a value later than the scheduled job execution time.

This change will have no impact on your code if your platform has enough clock resolution so that two subsequent calls to avs_time_real_now() or avs_time_monotonic_now() will always return different values. As a rule of thumb, this should be the case if your clock has a resolution no worse than about 1-2 orders of magnitude smaller than the CPU clock. For example, for a 100 MHz CPU, a clock resolution of around 100-1000 ns (i.e., 1-10 MHz) should be sufficient, depending on the specific architecture.

If your clock has a lower resolution, you may observe the following changes:

anjay_sched_run() is now properly guaranteed to execute at least one job if the time reported by anjay_sched_time_to_next() passed. Previously this could require waiting for another change of the numerical value of the clock, which could cause undesirable active waiting in the event loop. This is the motivating factor in introducing these changes.
Jobs scheduled using AVS_SCHED_NOW() during an execution of anjay_sched_run() before the numerical value of the clock changes, will be executed during the same run. The previous behavior more strictly enforced the policy to not execute such jobs in the same run.

If you are scheduling custom jobs through the avs_sched module, you may want or need to modify their logic accordingly to accommodate for these changes. In most typical use cases, no changes are expected to be necessary.

9.9.4.2. Removal of avs_unit_memstream 

avs_unit_memstream was a specific implementation of avs_stream_t within the avs_unit module that implemented a simple FIFO stream in a fixed-size memory area.

This feature has been removed. Instead, you can use an avs_stream_inbuf/avs_stream_outbuf pair, or an avs_stream_membuf object.