Client and Service Interfaces

This library is designed to simplify how complex systems talk to each other. It uses a decentralized Publish-Subscribe architecture, which means components don't need to know each other's addresses beforehand. Instead, they find each other automatically during a "discovery" phase and exchange data based on the Data Model.

To keep the communication organized, every interface in the library is defined as either a Service or a Client. This distinction is about the "ownership" of data and tasks, not just the direction of the flow.

• The Service Interface: Think of this as the Provider. It usually belongs to an application that manages a resource, such as a hardware sensor, a database, or a physical device. A Service is designed to share its status with all of its clients.
• The Client Interface: Think of this as the Consumer. It belongs to the application that wants to use a resource. A Client "subscribes" to a Service to get updates or send instructions.

Important: These roles define how they talk, not who can speak. A Client can send data to a Service (e.g., a command), and a Service can push data to many Clients (e.g., a report).

Example: A Speedometer Service reads sensor data. Multiple Client Applications (e.g., a Dashboard and a Data Logger) implement the Speedometer Client Interface to receive speed updates. If a client needs to trigger a sensor calibration, it calls a method on the Speedometer Service Interface.

Client to Service

Service to Client(s)"

Operation Types

To handle different real-world requirements—like ensuring a command arrives safely or managing high-speed data—the library provides specific Operation Types. These are reflected directly as prefixes in the function definitions.

When you look at the classes, you will see methods starting with these prefixes. These tell you exactly how the data is being handled "under the hood."

Service interface

Client interface

Key Technical Concepts

• Guaranteed Delivery (Reliability): The library ensures that all data arrives. If a packet is lost, it is retransmitted. The only exception is Stream...(), which is optimized for speed over reliability.
• Late-Joiner Support: In a dynamic network, some components might start later than others. For operations like Report...() or Config...(), the library automatically "remembers" the last sent value and delivers it to the new component as soon as it connects. Most late-join functions provide a IsRemoved flag to indicate that the message is no longer available. During shutodwn of a actor the IsRemoved flag is automatically set to true, it can also be set manually. All function parameters which start with Key are called keyed topics. Every unique key is handled as separate indepented data and can be individually controlled via its IsRemoved flag.