Writing an RTPS type plugin

The Fast RTPS provider defines routines for encoding and decoding basic data types as they're written or read through the Fast RTPS service. Sometimes, these built-in types might not meet your application needs. For these scenarios, the provider supports pluggable type definitions, which let you define custom data types and load them into the runtime environment.

Note: You must have installed the Fast RTPS provider to follow the steps in this tutorial to write a custom RTPS data type. In this release, the client PiPS API component and a provider for the eProsima Fast RTPS middleware are shipped in the same package. But in future releases, these components might be shipped separately.

Built-in types

Before writing a pluggable type definition, consider if the data types supported by the provider are sufficient for what your application must do. The Fast RTPS provider has the following built-in types:
  • Boolean: Allows endpoints to exchange boolean values (true or false). The CSTRUCT encoding serializes and deserializes the field data to and from a buffer holding a standard C bool value. The PPS encoding allows the attribute name to be arbitrarily specified; this name is used internally by the provider.
  • Number: Supports exchanging double-precision floating point values. The CSTRUCT encoding serializes and deserializes data to and from a buffer holding a double value. The PPS encoding allows the attribute name to be arbitrarily specified.
  • String: Supports exchanging arbitrarily long character-string values. The CSTRUCT encoding serializes and deserializes data to and from a buffer of char values. The PPS encoding allows the attribute name to be arbitrarily specified.
  • JSON: Allows endpoints to exchange JSON-encoded strings. This is a special case of the String type that ensures that the data is a well-formed JSON string. The CSTRUCT encoding serializes and deserializes data to and from a buffer of char values. The PPS encoding allows the attribute name to be arbitrarily specified.
  • BLOB: Allows endpoints to exchange sequences of arbitrary bytes. The CSTRUCT encoding serializes and deserializes data to and from an arbitrary memory buffer. Note that structure preservation is not guaranteed when the memory alignments of the various endpoints is different. The PPS encoding uses Base64 strings to express the binary data in a printable form and allows the attribute name to be arbitrarily specified. The attribute type for BLOB data will be :b64:.
  • MultiMap: Allows endpoints to exchange a collection of name-value pairs where the values can be of any other built-in data type. The CSTRUCT encoding will populate a pips_multimap_t instance. The PPS encoding will express the MultiMap data as correctly encoded attribute-value strings.

The first chapter explains the supported PPS and CSTRUCT encoding schemes.

Note: The set of built-in types is still expanding. Future releases may support other types such as named lists that store each of the above types.

Custom data types

There are two main scenarios when custom data types are needed:
  • For publishing and subscribing to updates of data types defined by the underlying Fast RTPS service but not built into the provider.
  • For publishing and subscribing to updates based on C structures defined by your application.

When you define a custom data type, its implementation gets compiled into a type plugin, which you can link with the PiPS framework. In the next few topics, we provide tutorials on how to write a type plugin from an IDL file (for the first scenario) and from an existing C structure (for the second scenario). Finally, we explain how to link and load the plugin.