Highlights | Mender Client 6.1.0 makes robust delta updates significantly more practical for constrained devices; delta updates are now dramatically smaller and require much less RAM on the device. Docker-compose applications can also be updated with delta updates. Additionally, the Mender Client 6.1.0 release adds per-server Tenant Tokens, leaner networking on IPv4-only devices, and a faster file transfer and port-forwarding protocol for mender-connect.
A new feature release is now available: Mender Client 6.1.0. Mender Client 6.1.0 also includes all the reliability improvements shipped in Mender Client 6.0.1 and 5.0.6, which were previously covered in New in Mender: Zephyr 4.4 support and reliability improvements.
Robust delta updates can now be dramatically smaller while using far less memory on the device. In one customer use case, the delta update shrank to about 2 MB from approximately 200 MB — a 99% reduction in download size.
Previously, xdelta3, the delta engine inside mender-binary-delta, misclassified a block-device source as a non-seekable stream, such as a first-in, first-out (FIFO) stream. As the decoder could not seek back into the source partition, it had to allocate a source window in RAM equal in size to that of the encoder. For example, an 8 GB encoder window required an 8 GB RAM allocation on the device, which, in turn, caused memory-constrained IoT hardware to crash.
The updated decoder now treats block devices as seekable and reads directly from the source partition as needed. Its memory use remains small, regardless of the encoder window used to generate the delta update.
The updated decoder also removes previous trade-offs for the generation side of delta updates. Encoder and decoder window sizes are now decoupled; the encoder window no longer has to be capped to the device's RAM. Delta updates can be generated using a sufficiently large window to find matching data anywhere in the image, resulting in significant size reductions.
The updated decoder is tracked upstream as jmacd/xdelta#284. mender-binary-delta now builds against xdelta3 3.2.2, which includes the updates.
Note: Devices must run the updated mender-binary-delta before they receive delta updates generated with a large encoder window. Earlier versions of mender-binary-delay allocate a decoder window equal in size to the encoder window.
Mender Client 6.1.0 ships the first release of mender-delta-container-modules, bringing delta updates to docker-compose applications. mender-delta-container-modules follow the same practice as mender-binary-delta for root filesystems; instead of sending a full composition with all its container images, both processes send only the difference based on what the device already runs.
The mender-delta-container-modules release contains two parts:
./gen_delta-docker-compose old_artifact.mender new_artifact.mender
To go deeper, the --layer-deltas option adds a step that computes xdelta3 deltas between layers of similar images. The --layer-deltas option can further shrink the Artifact; however, it is more expensive to apply on the device and requires xdelta3 to be installed as well. To determine which approach is best, compare the results with and without the option before choosing which Artifact to deploy.
Note: mender-delta-container-modules is available to Mender Professional and Mender Enterprise plans. The generator requires docker-compose Artifacts created with gen_docker-compose 1.1.0 or newer. Devices need to have both the docker-compose and delta-docker-compose Update Modules, as the first deployment needs to be a full docker-compose update, and it accepts deltas after the initial containers are in place.
To get started, see Create a delta docker-compose update Artifact, and the integration guides for Yocto and Debian family devices.
Each entry in the Server’s configuration options can now carry its own TenantToken. When the TenantToken is set, it takes precedence over the global TenantToken for that server. With per-server Tenant Tokens, a single device can authenticate against servers that belong to different tenants.
The same ServerURL can also be listed several times with different tokens. Utilizing the same ServerURL allows a device to fail over between tenants on the same Mender Server. The failover behavior is particularly useful when moving devices between organizations, splitting a fleet across tenants, or migrating from one hosted region to another without a window where devices can't check in.
{
"Servers": [
{ "ServerURL": "https://eu.hosted.mender.io", "TenantToken": "<new-tenant-token>" },
{ "ServerURL": "https://hosted.mender.io", "TenantToken": "<old-tenant-token>" }
]
}
Note: Existing Server configurations will continue to perform without any changes. Entries without their own TenantToken default to the global TenantToken.
The Mender Client no longer requests IPv6 (AAAA) records on devices that have no IPv6 address configured. On IPv4-only devices, removing IPv6 (AAAA) record requests halves the number of DNS queries the client makes and removes connection attempts to unreachable IPv6 addresses on every request.
For fleets on cellular or metered networks, the optimized DNS behavior reduces overhead traffic and faster connection setup — with no configuration required.
mender-connect now implements version 2 of both the filetransfer and port-forwarding protocols. Version 2 builds on the reliable WebSocket interconnection between device and server. Delivery is now guaranteed by the transport itself, so the per-message end-to-end acknowledgments of version 1 are no longer required.
The per-message end-to-end acknowledgments of version 1 were redundant and a bottleneck; every chunk had to make a full round trip before the next one could move. Removing the acknowledgments improves throughput when uploading or downloading files to a device, and when tunneling traffic through port forwarding — especially over high-latency links such as cellular or satellite.
The new protocols are fully backward compatible. When file transfer is enabled, the device announces support for both version 1 and version 2; older Mender Servers continue to work with version 1 while newer ones negotiate version 2 automatically.
Share your feedback about the new Mender updates and suggestions for future improvements in the Mender Hub General Discussions forum. If you encounter any issues with the new release, please report them in the Mender JIRA issue tracker with detailed reproduction steps and system information.
The full list of changes is available in the Mender Client changelog.