Communication Model: Node and Service

[ElliotHYLee]

After reading the book, I'd like to know more about the services: https://ekxide.github.io/iceoryx2-book/main/fundamentals/communication-model.html

1. How is max_pub/max_sub controlled? Is it just a control feature, or is it somehow related to memory allocation?

For instance, if max_subscriber(max), and during the mission, it happens to be that only 1 subscriber is using the service, is it a waste of execution time or ram resources?

2. What's the max number?

for both max_pub/sub?

3. multiple instances trying to set max_pub/sub

What's exactly going on when multiple instances create the same names services with different maxs?

I observed this, for example, max_pub=1, max_subs=1000, and the second instance has max_pub=1, max_subs=1. Then the second instance would run. But not vice versa. So I guess, whatever the instance runs first, the first instance's service definition is immutable?

4. Node

How to monitor the node to node graph? Node is an entry point for an app to use iox2 apis. And it seems it's possible to use multiple publihsers, subscriber, servers, etc.

From the discovery example, currently it seems node has no name..?

name: NodeName {value: FixedSizeByteString<128> { len: 0, data: "" },

Or, I just couldn't find the correct examples so far..

Anywyas, currently, I wonder if it would be a good pratice to handle multiple services in a node. Or, 1 node per 1 service maybe good? I just wanted to draw the relationship matrix.

[elfenpiff]

@ElliotHYLee your questions will be answered detail in the next months with several articles in the iceoryx2 book. For now, I can give you some brief answers:

As a foreword: iceoryx2 is also focusing on mission-critical systems and therefore pre-allocates all communication resources it requires to run so that it can guarantee that it never runs out of memory. Just assume a scenario where your car camera detects an obstacle and cannot inform your emergency brake, just because the system has no more memory left - to prevent this, we pre-allocate.

1. How is max_pub/max_sub controlled? Is it just a control feature, or is it somehow related to memory allocation?

The max number of subscribers, subscriber buffer size, history size and subscriber max borrow size are all related to pre-allocation, the larger the numbers are the more memory chunks a publisher must pre-allocate in its data segment where the payload is stored.
The max publisher and subscriber (or in general the max port numbers) are related to the size of the dynamic service segment, but here they have only a negligible impact.

2. What's the max number?

The max number is restricted by the memory you have available in your system.

3. multiple instances trying to set max_pub/sub

If you define any service configuration the rule is: If the service does not exist, the service will be created with the configuration you have provided, if the service exists the configuration is seen as requirement, and the existing service must support at least the configuration you have provided.

4. Node

From the discovery example, currently it seems node has no name..?

When you create a node you can set an optional node name for debugging purposes, see this here: https://ekxide.github.io/iceoryx2-book/main/getting-started/robot-nervous-system/publish-subscribe.html#publisher

Anywyas, currently, I wonder if it would be a good pratice to handle multiple services in a node. Or, 1 node per 1 service maybe good? I just wanted to draw the relationship matrix.

The relationship from a developer/architectural level is:

• The Node is a Service (PublishSubscribe, RequestResponse, ...) factory
• The Service is a PortFactory (Publisher, Subscriber, Server, Client, ...)
• A port is a Payload factory (Publisher can loan (produce) SampleMuts, that can be sent; Subscriber can receive (produce) Samples, ...)

Since by default the ports and the payload do not implement Send or Sync our recommendation is to have one Node per execution unit (which can be a process, thread or some RTOS call it task - it is something that executes things and multiple of those things can run in parallel).
It also makes sense to structure your code like this, since iceoryx2 can also be used for inter-thread communication in one process. But if you structure your code right, you can run the functionality either in a thread, in a different process or on a different machine that is connected via network with iceoryx2 and you use the tunnel (start the tunnel on every endpoint and iceoryx2 takes care of the rest):

cargo build --release
cargo run --release --bin iox2 -- tunnel-release zenoh

With this you can now build an ultra-robust system, where a functionality can be moved between machines or processes depending on the current load etc. And if a process or parts of the system crashes, the remaining system has the chance to take over the functionality - maybe in a degraded slower mode but it can at least continue.