A true zero-copy inter-process-communication (IPC) middleware for high-performance data transfer between processes.
Eclipse iceoryx is a high-performance inter-process-communication (IPC) middleware that enables true zero-copy data transfer between processes using shared memory. It solves the problem of efficiently moving large data volumes in real-time systems, such as automotive driver assistance or robotics, without the latency overhead of traditional copying methods.
Developers building real-time, data-intensive systems in automotive, robotics, or gaming where low-latency, high-throughput IPC is critical. It is also suited for framework integrators needing a transport layer for larger middleware stacks.
Developers choose iceoryx for its true zero-copy architecture, which guarantees constant latency regardless of data size, and its multi-platform support. It provides a robust, efficient foundation for high-performance IPC without the serialization bottlenecks of conventional approaches.
Eclipse iceoryx™ - true zero-copy inter-process-communication
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses shared memory to transfer data without copying, ensuring constant latency regardless of payload size, as emphasized in the introduction for real-time applications like automotive systems.
Supports Linux, macOS, QNX, FreeBSD, and Windows 10, making it suitable for embedded, desktop, and automotive environments with diverse OS requirements.
Provides a typed C++ API for ease of use and low-level plumbing APIs for custom implementations, facilitating integration into larger frameworks like ROS 2 and eCAL.
Originated in automotive industry with defined quality levels (e.g., target level 1+ for QNX), ensuring reliability for safety-critical systems as per the quality declaration.
Access rights for shared memory are not supported on macOS, FreeBSD, and Windows, and command line parsing is pending on Windows, limiting security and ease of use on those OSes.
Focuses solely on the transport layer; lacks built-in serialization, service discovery, or advanced messaging patterns, requiring additional layers for full middleware solutions.
The distinction between plumbing and porcelain APIs means developers must handle low-level details or integrate with frameworks, increasing initial setup complexity compared to all-in-one IPC libraries.