Iceoryx - Iceoryx2 comparison doc

Nobody has claimed this yet.

## Brief feature description

As discussed in the latest developer meetup on 6.3.2025 I think it would beneficial to everyone if there were a comprehensive feature comparison doc comparing Iceoryx to Iceoryx2. This could be linked from the main README and be used to help encourage folks to migrate over to Iceoryx2, and can be a valuable resource in general for understand how each system works and what all features are available

## Detailed information

The plan is essentially to open a pull request linked to this issue to add a markdown document. So far I am in the note taking stage and have come up with a rough list of categories to discuss:

### Software Architecture

#### Iceoryx
- Centralized
- All runtimes are created through communication with the RouDi daemon
- All runtimes share read/write access to the same shared memory segment.
- Processes all allocate from the same shared memory pools. Limited capabilities to partition access

#### Iceoryx2
- Decentralized
- Runtimes require no communication with any central deamon
- Much tighter shared memory ownership model - no shared memory pools
- Modular architecture allows for extensibility without needing to fork the repo

### Memory Management

#### Iceoryx
- All shared memory is setup by RouDi and configured via the RouDi config
- There is a single `iceoryx_mgmt` shared memory segment containing data structures for runtimes, comms endpoints, and memory management
- There is a configurable number of data segments with variable read/write access
- Each data shared memory segment is divided into memory pools, each of which supports a chunk count and maximum chunk size
- Processes all share access to segment managers which contain memory managers for each memory pool.
- Loans will allocate free chunks from the memory pools, storing a reference count in a "chunk management object". When publication happens, the reference count is increased for each subscriber and then decreased for the publisher. Whenever the reference count reaches 0, the chunk is returned to the memory pool by which ever process was the last one to release it.
- Each comms endpoint additionally has a "used chunk list" to track their individual references (think of it as a pointer to the reference count). This lives in shared memory so that if the process terminates RouDi can release the references and decrement reference counts on behalf of the terminated process.
- Memory pools are thread safe and rely on a "multi-producer, multi-consumer lock-free-free-list" (or MpmcLoFFLi for short)
- Used Chunk Lists are not thread safe

#### Iceoryx2

- There is no centralized shared memory region. Instead the memory for each comms endpoint is managed by its owning process (TODO: Verify and characterize more of the details here)
- Publishers loan messages from their individual memory pools
- Publishers keep track of "borrowed loans" in subscribers via event messages. There is no "used chunk list".

### Configuration

#### Iceoryx

- Static global limits set in the build lead to high memory overhead - `/dev/shm/iceoryx_mgmt` allocates bookeeping for maximum number of publishers, subscribers, messages held per subscriber, etc... Same values also affect size of data structures in C++ leading to large stack usage
- Memory pools are statically configured via the "roudi config". Message size, frequency, etc... characteristics need to be known ahead of time, or grossly overestimated

#### Iceoryx2
- Supports static or dynamic memory configuration
- Isolation of memory pools per-publisher makes any preallocation much more precise and the overall configuration more flexible

### Language and Platform Support

#### Iceoryx
- C/C++, natively
- Limited support for Rust bindings
- MacOS, QNX, Linux, Windows

#### Iceoryx2
- Rust, natively
- C++ via bindings
- Python and Go bindings planned
- Linux, ThreadX, QNX
- VxWorks, Androind etc are planned

### Messaging Patterns

#### Pub Sub

#### RPC

#### Events

#### Additional Patterns

##### Iceoryx

No additional message patterns planned.

##### Iceoryx2
- blackboard
- pipeline
- resource and executor

### Event Notifications

### Events

### Concurrency

### Tooling

### Safety

#### Iceoryx
- May be able to achieve ASIL B, not higher.
- No support for mixed criticality
- Many issues have to do with the centralized architecture. Every process depends on RouDi as a central point of failure, and they all share read/write access to the same shared memory segment.

#### Iceoryx2
- Shall support ASIL D
- Shall support mixed criticality

### Error Handling

#### Iceoryx
- Mixture of result types (`iox::expected`) and contract checks. Contract failures always cause immediate termination
- Everything is `noexcept`. Even functions that may call code that is not `noexcept` (e.g. `iox::function`).

#### Iceoryx2

Feel free to suggest more topics and provide details informally in this issue. I will edit the above to capture more notes and subcategories so I have something to work off of when I create the pull request.

Start by reviewing the comparison notes in this issue and the repository's main README, then verify the Iceoryx and Iceoryx2 details before drafting the proposed Markdown document. Done means a comprehensive, accurate feature comparison covering the listed categories and a README link to the new document.

Written by the indexing model from the issue text.