### Navigation

- index
- next |
- previous |
- RnR API Reference »

# 6. Impact on DDS Domain

This section describes additional aspects of the Record and Replay Service and its interaction with other systems.

## 6.1. Intrusiveness

Relevant characteristics of the Record and Replay Service with respect to ‘intrusiveness’ for an existing system are:

- The service can be optionally configured on any DDS node in the system.
  - When run as part of an existing federation of applications, it utilizes the federation’s shared-memory segment to obtain the data (so locally-published data is not required to travel over the network to be recorded by the service, and vice-versa for replaying towards co-located subscribers).
  - When run on a dedicated RnR node, data to be recorded is transparently forwarded to that RnR node, typically using multicast network features (and so not inducing extra network traffic).
- Services are controlled in ‘the DDS way’, i.e. a data-centric way where command and status topics allow DDS-based ‘remote control’ over the service from anywhere in the system.
  - A dedicated `RecordAndReplay` partition is utilized by RnR to bound (contain) the control/status flows.
  - In the case of a dedicated RnR node, this partition can be configured to be a so-called ‘local Partition’ thus bounding (containing) all control/status traffic to the RnR node.
- Replaying (subsets) of recorded data ‘by definition’ has impact on an existing system:
  - It can induce unanticipated traffic-flows towards subscribing applications
  - It typically triggers application-processing of such replayed data...
  - which can be considered ‘intentional’ and inherent to the purpose of replaying recorded data

Summarizing, it can be stated that when dedicating a specific computing node for Record and Replay and confining the control and status traffic to control the service to stay ‘inside’ that node, recording of data in a multicast-enabled network is non-intrusive.

Note that the few shared topic-definitions (definitions only, not actual samples of these topics when these are ‘confined’ to the RnR node) that would be visible system-wide when inspecting the built-in topics of the system (for instance with a tool like the Vortex OpenSplice Tuner) are considered non-intrusive as they only imply a small and static amount of data occupied by the related built-in topic samples.

### Navigation

- index
- next |
- previous |
- RnR API Reference »