-
Key: DDS15-254
-
Status: open
-
Source: ZettaScale Technology ( Mr. Erik Hendriks)
-
Summary:
The DDS specification is very clear what happens in case of a disconnect: the receiver will behave as if the sender unregistered all its instances. But what should the behavior be in case of a reconnect?
For VOLATILE cases the behavior might still be intuitive: an instance stays NOT_ALIVE_NO_WRITERS until an update has been received, in which case it goes back to ALIVE. And because VOLATILE data is typically periodic data, eventually all my instances will come back alive.
But what about non-volatile data, that is typically not periodic, or is periodic but with a very low update frequency? Consider the following scenario:
- Writer A writers 10 samples belonging to 10 different instances.
- Reader B takes all samples.
- Writer A disconnects from Reader B.
- Reader B receives invalid samples indicating all instances are now NOT_ALIVE_NO_WRITERS.
- Reader B takes these samples.
- A reconnection is established, and none of the instances have been updated by Writer A.
You would expect that all instances in Reader B would go back to the ALIVE state, but how do I get them back into the ALIVE state? Since there are no more samples to piggy-bag this instance state change on.
A couple of approaches are conceivable:
- Use an invalid sample to bring the instance back alive.
- Republish the last available sample
- Do nothing.
Every approach has its pro's and cons, but the DDS spec should clearly describe which behavior is intended here.
-
Reported: DDS 1.4 — Wed, 19 Jun 2019 12:15 GMT
-
Updated: Wed, 19 Jun 2019 12:15 GMT
DDS15 — Specify the behavior of instance state machine in case of a disconnect-reconnect scenario
- Key: DDS15-254
- OMG Task Force: Data Distribution Service 1.5 RTF