OpenSplice DDS has been architected from the ground-up to offer maximum performance (in terms of scalability and determinism) for large scale distributed real-time systems. Depending on application needs and development lifecycle, OpenSplice DDS now supports two deployment architecture models that can provide ease-of-use (with regard to configuration) and maximum performance.
OpenSplice DDS v6 introduces a runtime configuration parameter to select between a federated and standalone deployment option. When deployed standalone OpenSplice DDS is a library that manages application-wide communication. When deployed federated OpenSplice DDS is a set of libraries and daemons that manage node-wide communication.
The deployment mode can be changed by a simple configuration parameter. No recompilation or re-linking!:
<SingleProcess>true</SingleProcess>
The deployment options can be mixed at will (even within a single computing node). The same application can be deployed in federated and standalone mode (even on the same system).
-
To take advantage of modern computing architectures is has become increasingly more important to be able to exploit multicores. OpenSplice DDS provides a shared-memory deployment option that facilitates the federated architecture by offering ultra-low latency inter-core communication along with maximal nodal scalability.
Recognizing the difficulty of choosing the right architecture upfront in the system design and development cycle, OpenSplice allows you to run exactly the same application, meaning the same executable, in different architectural styles by simply changing a runtime parameter. This makes OpenSplice the only DDS implementation that gives you the choice of selecting, as well as easily adapting, the deployment architecture that best suits you.
Shared-Memory Scalability:
When configuring OpenSplice for the Federated deployment architecture, data is physically present only once on a machine’s federation, and smart administration still provides each subscriber within the federation with his own private 'view' on this data. This allows a reader’s data cache to be perceived as an individual 'database' that can content-filtered, queried, etc. (using the content-subscription profile as supported by the OpenSplice core). The shared-memory architecture results in an extremely low footprint, excellent scalability and optimal performance when compared to other DDS implementations where each reader/writer are ‘communication-endpoints’ each with their own storage (i.e. historical data both at reader and writer) and where the data itself still has to be moved, even within the same platform.
