... | @@ -1288,6 +1288,58 @@ build and install icd-demo: |
... | @@ -1288,6 +1288,58 @@ build and install icd-demo: |
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
### Topic History a.k.a. late joiners \[MAL DDS\]
|
|
|
|
|
|
|
|
Many PubSub topics need to cater for late joining subscribers. That is, subscribers typically need to receive that last value published, and then all values published from the time of joining, on.
|
|
|
|
|
|
|
|
There are a few key aspects of DDS that must be configured to enable this:
|
|
|
|
1. The topic must publish a type that has a key. History is stored in the publisher on an instance (i.e. key value) basis (i.e. one sample per instance). In ICD XML, the type struct must contain a member with key="true" set, e.g.:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<struct name="Sample" trace="true">
|
|
|
|
<member name="daqId" type="int64_t" key="true" />
|
|
|
|
<member name="value" type="double" />
|
|
|
|
</struct>
|
|
|
|
```
|
|
|
|
2. The topic QoS must be set to have historyQos set to KEEP_LAST, with depth 1. For example:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<topic profile_name="MyApp_Default_Topic">
|
|
|
|
<historyQos>
|
|
|
|
<kind>KEEP_LAST</kind>
|
|
|
|
<depth>1</depth>
|
|
|
|
</historyQos>
|
|
|
|
</topic>
|
|
|
|
```
|
|
|
|
|
|
|
|
3. Both data_writer and data_reader QoS must be set to reliability RELIABLE. Reliable communications is required to receive historical data.
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<reliability>
|
|
|
|
<kind>RELIABLE</kind>
|
|
|
|
<max_blocking_time>
|
|
|
|
<sec>1</sec>
|
|
|
|
</max_blocking_time>
|
|
|
|
</reliability>
|
|
|
|
```
|
|
|
|
|
|
|
|
4. The data_reader QoS must be set durability to TRANSIENT_LOCAL. This means it will request missed data samples, but not beyond the life of the system (i.e. no persistence to disk). Without this setting the subscriber will not inquire about missed data.
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<durability>
|
|
|
|
<kind>TRANSIENT_LOCAL</kind>
|
|
|
|
</durability>
|
|
|
|
```
|
|
|
|
|
|
|
|
With the above settings in place, late joining subscribers should receive the last data published for each instance, for each topic, from connected publishers.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
### Discovery over multiple NICs \[MAL DDS\]
|
|
### Discovery over multiple NICs \[MAL DDS\]
|
|
|
|
|
|
**Problem**
|
|
**Problem**
|
... | | ... | |