documentation: how it works

[tamird]

It would be great to have something like a design document: what problems does this library solve, how does it solve them, how does it avoid various pitfalls, etc.

I came across this reply from @elBoberido on HN and it's emblematic of what's lacking; the parent talks about shared memory challenges in the presence of process death and the response simply states

We found a few ways on how to make this feasible, though.

Another point of confusion for me: how does this work without a central broker? According to https://iceoryx.io/ there is no need for one.

Anyway, something that describes the design of the software would go a long way in increasing (at least my) confidence in it.

[elfenpiff]

@tamird I appreciate and completely get it.

Just to give you some context, we have all been working together for the last seven years. Starting with a Bosch research project, the predecessor of iceoryx, then we fought for over a year to make it open source. In the last years, we have certified parts of iceoryx1 according to ISO 26262 and realized that some things make the zero-copy communication hard to certify - one key element was the central broker.

We started redesigning iceoryx again and came up with the iceoryx2 architecture. It just took us five years to realize that everyone has a central broker - it is the operating system. So we founded ekxide to realize the next generation of iceoryx.

At the moment we have the goal to reach feature parity with iceoryx and complete the user documentation with a good getting started guide. When this is done, we will present the iceoryx2 design in detail. Maybe it would be a great topic for a FOSDEM 2025 talk but I think we need a bit more than just one hour.

Just out of curiosity, what topic would you be most interested in:

• Architecture without a central daemon
• Decentralized process monitoring and resource cleanup
• Decentralized communication and service discovery
• Zero trust approach for shared memory communication
• Indestructible processes
• Incorruptible data structures

[tamird]

All of these would be interesting topics. I would probably start with the first 3 which sound least fantastical 🙂 .