|
|
||
|
This article is a short description of the new features and changes introduced in the YAMI4 2.0.0 release.
YAMI4 was designed with portability in mind and this mindset influenced all early architectural decisions, including the choice of supported data types. It appeared, however, that the lack of unsigned integers proved to be a limitation for the more demanding users.
The new version introduces unsigned integers in both 32- and 64-bit variants in the type system, and at the same time extends the wire protocol to support them. This change is the first in the history of YAMI4 that introduces incompatibility at the wire level, but the following are still guaranteed:
That is, the new unsigned data types can be used only between new agents.
This single change justified the increase of major version number - hence 2.0.0.
The previous library version became an unintended victim of changes introduced in the set of header files used in newer compiler version (notably Clang on FreeBSD), where unfortunate name conflicts prevented the library from building properly.
The new version fixes that problem. In addition, the remaining references to the Boost library were all removed, so that only features of the standard C++ library are used in the source code.
The YAMI4 code was also lifted to respect more recent C++ variants, with C++11 set as the guaranteed base for the library code. The optional name service relies on <filesystem>, which is part of the standard library since C++17.
The memory allocator interface was improved to make it easier for users to provide their own custom allocators. In addition to the default unbounded scheme, the library includes both single-thread (non-synchronized) and locked implementations of basic allocator that can work within the provided memory area - these variants were already part of YAMI4, but now they can be entirely replaced with user-provided implementations.
The core library also offers the possibility to register custom frame acceptor callbacks that allow the user to individually accept or reject frames based on their source and size. This feature provides foundations for implementing simple firewall functions that can, for example, prevent memory exhaustion due to corrupted or malicious incoming frames.
It is also possible to inject and extract arbitrary metadata (in terms of regular parameters objects) into message headers, to provide high-level processing or routing hints and guides. The metadata fields are retained and forwarded by the broker service.
The YAMI4 2.0.0 package is intended to be a baseline for future developments and as such required some scope reduction in relation to previous versions. The following, least demanded components, were excluded from the new package:
Previous package versions are still available for download for those users that wish to evaluate these components and who might need them to be re-introduced in future versions.
Go to the YAMI4 homepage.