iceoryx2: zero-copy IPC with a Rust core and four language bindings

What zero-copy buys you, stated plainly

The README's claim is a latency one rather than a throughput one: iceoryx2 provides consistently low transmission latency regardless of payload size. That is the whole argument for shared memory. A socket copies your bytes into a kernel buffer and often copies them again on the way out; shared memory hands the same physical pages to the reader, so a 400 MB point cloud costs no more to pass than a 400 byte message.

That is why the project describes itself as built for sending huge amounts of data and calls publish/subscribe ideal for large datasets that need to be shared. Four messaging patterns are named: publish/subscribe, request/response, events for signals, plus pipeline and blackboard which the README marks as planned rather than shipped.

The architecture underneath is service-oriented, which is a design decision with visible consequences. You open a node, create a service, and other nodes attach to that service by name rather than connecting to each other. Two of the features shipped in 0.10.0 are consequences of that model: associating services discovered on remote hosts with the hosts that offer them, and restricting the tunnel to a configurable allow list of services.

Events are the other half and they behave differently from pub/sub payloads. Version 0.10.0 adjusted the event API to guarantee that events can always be delivered, which is a stronger promise than publish/subscribe makes.

The workspace is forty crates and the tree tells you why

iceoryx2 is not a crate, it is a Cargo workspace, and the member list in `Cargo.toml` is the clearest description of the layering:

[workspace]
resolver = "2"
members = [

`iceoryx2-bb/` is the building block layer, itself split into `lock-free`, `threadsafe`, `concurrency`, `container`, `elementary`, `elementary-traits`, `memory`, `posix`, `system-types` and `flatbuffers`. Nearly every one of those has `tests-common` and `tests-nostd` members, which tells you the project tests its primitives in both a normal and a `no_std` configuration.

Above that sit `iceoryx2-cal/` for the communication abstraction layer with its own conformance tests, `iceoryx2-pal/` for the platform abstraction, and `iceoryx2-services/` for discovery and routing. Language surfaces are `iceoryx2-c/`, `iceoryx2-cxx/` and `iceoryx2-ffi/` holding the C and Python bindings plus `ffi-macros`.

The build is driven by `just` rather than plain make, with the recipes split across a `.just/` directory: `build.just`, `test.just`, `test-e2e.just`, `lint.just`, `coverage.just`, `publish.just`. The default recipe lists what you can run:

import '.just/paths.just'
import '.just/common.just'
import '.just/build.just'
import '.just/test.just'
import '.just/lint.just'
import '.just/coverage.just'
import '.just/publish.just'

Bazel sits alongside it, with `BUILD.bazel`, `MODULE.bazel` and a `bazel/` directory, and CMake for the C and C++ side through `CMakeLists.txt` and `iceoryx2-cmake-modules/`. A project that carries three build systems is telling you it has to be consumable from inside someone else's build.

Four languages, four published API references

The binding story is the practical reason to look at this rather than a Linux-only shared memory library. The README links a Rust API reference on docs.rs, plus Python, C++ and C API references, each hosted for the project. All four are generated documentation rather than hand-written guides, which means they track the code closely but read like API docs rather than a tutorial.

For learning, the tree lists an `examples/` directory with a `Cargo.toml` of its own, a README, a `bazel/` subdirectory, and separate example sets per language: `rust/`, `c/`, `cxx/`, `python/`, `nostd/`. There is also `examples/cross-language-end-to-end-tests/`, which is the interesting one, since it implies a test that runs a Rust process talking to a C process talking to a Python process over the same service.

The `nostd/` example directory and the bare metal proof-of-concept in the platform table are related. A `no_std` core is what makes embedded targets conceivable at all, and there is a dedicated platform abstraction layer to make that work.

The tooling for people who do not want to write code is `iceoryx2-cli/`, and the release notes for 0.9.3 mention a command named `iox2 service replay` with a fix in 0.9.2 to make it send the full payload for dynamic data. That is a debugging tool for replaying what a service sent, which tells you the project expects people to debug distributed systems by inspecting the traffic.

The platform table is the most useful thing on the README

Most middleware READMEs have a compatibility section that is optimistic. This one is a table with columns for Operating System, State, Current Support Level and Target Support Level, and an explicit note that the support levels can be adjusted when required.

Reading the current column: Linux on x86_64, aarch64 and 32-bit are all done at tier 2. Windows and Mac OS are done at tier 2. FreeBSD is done at tier 2. QNX 7.1 and QNX 8.0 are done but at tier 3. Everything else is not done: Android and bare metal are proof-of-concept, VxWorks is proof-of-concept, and FreeRTOS, ThreadX, iOS, RTEMS, Redox OS and WatchOS are planned.

The footnotes remove the ambiguity. The Android proof-of-concept currently supports only local, inter-thread communication. The bare metal one is a proof-of-concept with `no_std` support. So the two entries that look most attractive for embedded work are the two that do not yet do inter-process communication across machines.

The target column shows the direction of travel: Linux, Windows, FreeBSD, QNX, VxWorks, Android and bare metal all target tier 1 eventually, while iOS, WatchOS, RTEMS, FreeRTOS, ThreadX and Redox OS target tier 2. Several of the current tier 2 Linux entries target tier 1, so the table is a commitment, not a status report.

If you are deploying to QNX today, note that tier 3 is the only level it has reached. Everything else on your checklist would need to be verified against the release notes rather than the table.

Version 0.10.0 is about discovery, tunnels and backpressure

The three recorded releases are dense with the kind of detail that tells you what is actually hard about this project. Version 0.10.0, published 2026-09-18, is a feature release: allowing the tunnel to be restricted to a configurable allow list of services, associating services discovered on remote hosts with the hosts that offer them, guaranteeing events can always be delivered, exposing current service port counts through dynamic configuration in Python, making history configurable per subscriber, and adding `Node::force_remove_service` for removing corrupted services.

Version 0.9.3 from 2026-07-08 is bug fixes, and two of them are revealing. One enables running multiple iceoryx2 versions in distinct domains in parallel by adding a version suffix to the global management segment. The other closes an `ActiveRequest-PendingResponse` connection when a dead process is cleaned up. Version 0.9.2 from 2026-06-18 fixed a chunk leak when an offset cannot be translated to a dynamic data segment, and made delivery use `Backpressure::Retry` when the receiver is disconnected until the buffer is full.

`Backpressure::Retry` is the term to know. When a subscriber is slow or gone, the publisher is told rather than silently dropping, and the fix in 0.9.2 changed the behaviour to keep retrying until the buffer is full. That is a delivery guarantee question, and it is the kind of question that separates an IPC library you can build a sensor pipeline on from one you cannot.

The project is Apache-2.0 or MIT, dual licensed, with `LICENSE-APACHE`, `LICENSE-MIT` and a `NOTICE.md` in the tree. Stars sit at 2567 with 190 forks and 232 open issues. The last push was 2026-09-27, nine days after the 0.10.0 release.

Where the README stops and the book starts

The README is short, which is appropriate for a library this size, and it links out rather than explaining. Four things it points at: the iceoryx2 Book by ekxide as the user documentation, the `examples/` directory, release notes under `doc/release-notes`, and `FAQ.md` as the user FAQ. For contributors there is `FAQ_ICEORYX_DEVS.md`, and the tree also carries `BEST_PRACTICES.md`, `ROADMAP.md`, `SECURITY.md` and a `CODE_OF_CONDUCT.md`.

The roadmap badge at the top of the README is worth clicking, because it is where pipeline and blackboard will be described if and when they land. Both are named in the README as planned, and both are patterns a robotics or sensor-fusion architecture would want.

For benchmarking, the README publishes two plots generated from the project's own `internal/plots/` directory and names the machine they came from: an Intel i7 13700h, Linux 6.10.10-arch1, rustc 1.81.0 and gcc 14.2.1. Naming the hardware is more useful than most projects manage, and the `benchmarks/` directory in the tree means you can reproduce it rather than take it on faith.

The honest summary is that the README tells you what the project is, which platforms it runs on, which languages you can call it from and where the documentation lives, and stops there. Every decision you need to make, from which messaging pattern to how to structure a service, is in the book or the examples.

Editorial conclusion

iceoryx2 is the version of iceoryx to start on if you are starting fresh, because the Rust core is the reason the four language bindings can exist at all and because the architecture is modular in a way the original was not. Read the support table before you commit though: Linux, Windows, FreeBSD and Mac are done at tier 2, QNX is done but only at tier 3, and Android and bare metal are proof-of-concept with local inter-thread only. Version 0.10.0 from 2026-09-18 is where the transport story got interesting, with a tunnel that can restrict services to an allow list and associate discovered services with the hosts offering them. Start from the `examples/rust` directory in the workspace, then read the iceoryx2 book for the design decisions behind what you just built.

Frequently asked questions

Official sources

1. eclipse-iceoryx/iceoryx2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases