Key concepts

To write applications that use PiPS, you need to understand its key concepts related to data exchange.

The PiPS framework is based on the following concepts:

Providers: Providers are stub components that encapsulate publish-subscribe services. Each provider exposes an interface that allows the PiPS client library to initialize the transport mechanisms and manage namespaces, topics, and publications in the underlying service.
Namespaces: Namespaces logically group topics. Each provider has a single root namespace. This way, similarly named topics defined in different providers aren't ambiguous.
Topics: Topics represent particular data types that are exchanged between endpoints (i.e., processes that publish or subscribe to data updates).
Publications: Publications support data exchange for particular topics. For a given publication, applications can subscribe to updates for the associated topic (to receive data), or publish updates (to send data in broadcast style), or both.

Providers

Each provider interacts with a specific publish-subscribe service by doing the following tasks:

Initializing the service so clients can start using it.
Creating and deleting namespaces within the provider (i.e., sub-namespaces). If the encapsulated service doesn't support the creation of these topic groups, this capability can be implemented by the provider itself, or not supported at all.
Creating and deleting topics. If sub-namespaces aren't supported, topics may be created only in the root namespace.
Creating and deleting publications.
Reading and writing topic data.

Encoding schemes

Provider implementations must define encoder and decoder routines for each associated topic. When data are read from the encapsulated service, they must be decoded, that is, converted to the format expected by the clients that subscribed to the topic. When data are written, they must be encoded so they can be published in the proper format. Currently, there are two supported encoding schemes:

PPS — This uses structured string data that conforms to the format expected for the PPS service.
CSTRUCT — This offers more flexibility because it directs PiPS to operate on a C structure's member fields directly. The layout of this structure must be known in advance to both the client and the provider, and will be bound to a particular topic.

Registered providers

Providers must be registered with the PiPS framework for them to be visible to client applications. Some providers are registered automatically while others are supported but must be loaded and registered explicitly. Also, PiPS does allow for third-party provider implementations, so you can support additional publish-subscribe services.

Each provider has a marketing name and a software name. The latter is used to refer to the provider in the configuration and in the pips_get_provider() API call. The following list explains the providers included in this release, with their marketing name followed by their software name in brackets:

Native (QNMP): The native provider uses QNX Neutrino Message Passing (QNMP) as its communication mechanism. This allows the PiPS framework to function without any dependencies on networking hardware, and allows for earlier and faster startup of services that use PiPS. When deployed, the native (or QNMP) provider is the default one used by the framework.
Note: QNMP doesn't support IPC between applications on different machines. Here, the interconnect layer is kernel message passing and the medium is local memory.
eProsima Fast RTPS (FASTRTPS): A C++ implementation of the Real Time Publish Subscribe (RTPS) protocol, which provides publish-subscribe communications over UDP transport.

Namespaces

All namespaces logically group topics and prevent topic name collisions between providers. Some providers support sub-namespaces, so you can further organize the topics into functional groups.

From the PiPS client's perspective, a namespace exposes functions to enumerate its contents, which consist of either topics or sub-namespaces, and functions to define new topics. If the provider supports sub-namespaces, multiple topics with the same name can exist. However, if the underlying publish-subscribe service does not support grouping topics in this way, name collisions might occur across sub-namespaces—provider implementations must account for this possibility.

Topics

Topics don't represent actual data, but rather data types and hence, describe the data arrangement. To support reading and writing specific data types, the provider must define encoder and decoder routines for each topic. How this is done is an implementation detail. For example, the Fast RTPS provider associates a data type definition with each topic, and this definition supplies these routines.

Data are exchanged for a given topic using samples, which represent updates to the topic that are expressed as change-sets.

Publications

To exchange data samples, client applications must create publications for the associated topics. In the PiPS framework, each publication has:

one or more publishers, which write samples
zero or more subscribers, which read samples
an associated topic (i.e., the object of the publication)
zero or more data samples (updates)

Note that an application can both publish and subscribe to updates for a given topic. Data can be exchanged for the topic only so long as the publication exists.