DDS — DDS ISSUE# 15] Semantics of register and unregister instance

Ref-13 Semantics_of_register_unregister_instance

The semantics of the register_instance and unregister_instance methods
are not entirely clear. From section 2.1.2.5.1 it seems that both
methods have, apart from their local memory management purpose on the
Publisher side, also a purpose with respect to determining the
LIVELINESS of a DataWriter on the Subscriber side. This means that
these methods will probably result in network communication as well

**PROPOSAL**

Clarify the semantics by adding the following paragraphs as needed to
sections 2.1.2.5 and to 2.1.3:

The need for registering/unregistering instances stems from two use
cases: (1) Ownership resolution on redundant systems, and (2)
Detection of loss in topological connectivity and the consequent
difference in the semantics of unregister and dispose (3).

(1) Ownership resolution on redundant systems

It is expected that users will use DDS to set up redundant systems
where multiple DataWriters are "capable" of writing the same
instance. The data-writers are either configured such that both are
writing the instance "constantly" or else they use some mechanism to
monitor each other and only write when they detect that the primary
"writer" is no longer writing.

Either of the above two cases uses the OWNERSHIP policy "Exclusive"
and arbitrate themselves by means of the OWNERSHIP_STRENGTH. The
desired behavior is that when the "primary" writer stops writing, the
application should start to receive data from the secondary subscriber

This approach requires some mechanism to detect that the "writer" is
no longer "writing" the data as it should. There are several reasons
why this may be happening and all must be detected (but not
necessarily distinguished):

The writing process is no longer running (e.g. the whole application
has crashed)

Connectivity to the writing application has been lost (e.g. network
got disconnected)

Application logic that was writing the data is faulty and has stopped
doing so.

Arbitrating from a writer to one of a higher strength is simple and
the decision can be taken autonomously by the reader. Switching
ownership from a higher strength writer to one of a lower strength
requires that the "reader" application can make a determination that
the "writer" application is "no longer writing the instance".

(1.1) Case where the data is periodically updated

This determination is reasonably simple when the data is being written
periodically at some rate. The writer simply states its offered
deadline (maximum interval between updates) and the reader monitors
that the writer indeed updates the instance at least once per
deadline_period. If the deadline is missed, the reader considers the
writer "not alive" and gives ownership to the highest-strength writer
that is alive

(1.2) Case where data is not periodically updated

The case where the writer is not writing data periodically is also a
very important use-case. Since the data is not being updated at any
fixed period, the "deadline" mechanism cannot be used to determine
ownership. The liveliness neatly solves this situation. Ownership is
maintained while the writer is "alive" and for the writer to be alive
it must be fulfill its "LIVELINESS" contract. The different means to
renew liveliness (automatic, manual) combined by the implied renewal
each time data is written handle the three conditions above (a), (b),
or (c) ( note that to handle (c) Liveliness must be
MANUAL_BY_TOPIC). Now the writer can retain ownership by periodically
writing data or else calling assert_liveliness() if it has no data to
write. Alternatively if only protection against (a) or (b) is desired,
it is sufficient that some task on the writer process periodically
writes data or calls assert_liveliness() on the participant.

However, this scenario requires that the reader knows what instances
are being "written" by the writer. That is the only way that the
reader can maintain ownership of specific instances from the fact that
the writer is still "alive". Hence the need for the writer to
"register" and "unregister" instances. Note that while "registration"
can be done lazily the first time the writer writes the instance,
"unregistration" in general cannot. Unless we are willing to say that
once a writer writes an instance it will forever write the instance
until the writer is deleted. Similar reasoning will lead to the fact
that unregistration will also require a message to be sent to the
readers

(2) Detection of loss in topological connectivity

There are applications that are designed in such way that their
correct operation requires some minimal topological connectivity, that
is, the writer needs to have a minimum number or readers or
alternatively the reader must have a minimum number of writers.

A common scenario is that the application does not start doing is
logic until it knows that some specific writers have the minimum
configured readers (e.g the alarm monitor is up).

A more common scenario is that the application logic will wait until
some writers appear that can provide some needed source of information
(e.g. the raw sensor data that must be processed).

Furthermore once the application is running it is a requirement that
this minimal connectivity (from the source of the data) is monitored
and the application informed if it is ever lost. For the case where
data is being written periodically, the DEADLINE QoS and the
on_deadline_missed() listener provides the notification. The case
where data is not periodically updated requires the use of the
LIVELINESS in combination with register/unregister instance to detect
whether the "connectivity" has been lost, and the notification is
provided by means of the "NO_WRITERS" lifecycle state.

In term of the required mechanisms the scenario is very similar to the
case of maintaining ownership. In both cases the reader needs to know
whether a writer is still "managing the current value of an instance"
even though it is not continually writing it and this knowledge
requires the writer to keep its liveliness plus some means to know
which instances the writer is currently "managing" (i.e. the
registered instances).

Note that the need to notify the reader that a particular instance has
no writers does not imply that the mechanism is the use of a
"NO_WRITES" lifecycle. We could just as well use a listener. The
listener mechanism has the problem that there is no way to know which
instances are the ones that have no writers. But this is also a
problem for the "on_deadline_missed" listener so we think it would be
a good idea to refractor these two mechanisms to that they are similar
in nature and both provide the means to determine which instances have
the problem.

(3) Difference between unregister and dispose

Dispose is different than unregister. The "dispose" indicates that the
data-instance no longer exists (e.g. a track that has disappeared, a
simulation entity that has been destroyed, a record entry that has
been deleted, etc.) whereas the "unregister" indicates that the writer
is no longer taking responsibility for updating the value of the
instance.

Deleting a data-writer is equivalent to unregistering all the
instances it was writing, but is not the same as "disposing" all the
instances.

For a topic with EXCLUSIVE ownership if the current owner of an
instance disposes it, the readers an instance will see the lifecycle
as being "DELETED" and not see the values being written by the weaker
writer (even after the stronger one has disposed the instance). This
is because the owner of the instance is saying that the instance no
longer exists (e.g. the master of the database is saying that a record
has been deleted) and thus the readers should see it as such.

For a topic with EXCLUSIVE ownership if the current owner of an
instance unregisters it than it will relinquish ownership and thus the
readers will see the value updated by another writer (which will then
become the owner). This is because the owner said that it no longer
will be providing values for the instance and thus any other writer
can take ownership and provide those values

see below