9.9. Migrating from Anjay 3.0
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.
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.
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
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.
Core Persistence API (
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.
CoAP observations are implicitly cancelled if a notification bearing a 4.xx or 5.xx error code is delivered, or if an attempt to deliver a notification times out.
In Anjay 3.4.x and earlier, this cancellation (which involves calling the
avs_coap_observe_cancel_handler_t callback) was performed before calling
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.
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_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.
avs_unit_memstream was a specific implementation of
the avs_unit module that implemented a simple FIFO stream in a fixed-size memory
This feature has been removed. Instead, you can use an
avs_stream_outbuf pair, or an