1

I'm trying to understand the RTPS and DDS Specification a bit better.

The RTPS Specification talks about "data changes" and how they are propagated, but does not exactly specify "what" is propagated (as in does it know what is transmitted and sends only the changes, or does it see the data as black box and always sends the whole thing). Now I assume that this is implementation specific.

But I want to know what behavior is dictated specifically for the built-in Topics. The DDS Specification defines the Data Types (i.e. the Data Field Names, Type, and meaning) of several built-in Topics. Can we assume that if a single Data field is changed, all other unchanged Data Fields are also sent?

Greek64
  • 13
  • 2

2 Answers2

0

The specification[s] define default values for some fields of the builtin Topic types. A sender is allowed to omit fields, and the receiver shall assume the default value for these omitted fields. Some fields are required for proper processing, even though there may be an implicit default value.

For example, a sample on the Subscription builtin topic may omit the 'deadline' field, and the receiver[s] will use the default deadline.period value of 'infinite'.

So, to answer your question:

"Can we assume that if a single Data field is changed, all other unchanged Data Fields are also sent?"

Not necessarily: if the other (unchanged) fields are at their default values (and are not required), they "may" not be sent. It is perfectly legal to send them, but an implementation may choose to not send them for optimization purposes.

C Tucker
  • 301
  • 1
  • 8
  • Hi Clark, you beat me by a minute and I expanded on my answer after reading yours too :-) I just wanted to point out that the default value for `minimum_separation` is `0` (which is equal to the default value for integer types according to the XTypes spec and does not have to be communicated for that reason indeed), not infinite. – Reinier Torenbeek Jun 02 '20 at 19:38
  • Indeed, I started with time_based_filter, then changed mid-thought to deadline... leaving the answer inconsistent... will fix. – C Tucker Jun 02 '20 at 22:30
0

The RTPS Specification talks about "data changes" and how they are propagated, but does not exactly specify "what" is propagated

Although it may not be immediately apparent, the RTPS specification does exactly specify what is propagated, in "Chapter 10 Serialized Payload Representation". It mentions the different standardized types of representations like CDR and CDR2 which have several variations including big endian and little endian versions. None of these formats are implementation specific, because that would hamper the desired interoperability between different DDS implementations.

The details of the formats are further explained in the DDS-XTYPES specification, specifically section 7.4 which is referenced in several places in that Chapter 10 that I mentioned. On its turn, the XTypes spec references some older specification that defines CDR.

That said, it is complicated to read through all those specs so let me answer your other question

Can we assume that if a single Data field is changed, all other unchanged Data Fields are also sent?

That is mostly correct. Updates to DDS data, for both built-in types as well as user-defined types, are done with all the fields communicated "atomically". This means that receivers of the updates will not have to worry about maintaining some kind of state to which some partial updates have to be applied to determine the actual current state.

However, an exception to this are values that are defined as "optional". The reason for this is not so much because those values have not changed since the previous update, but because those fields are considered non-mandatory. As far as I know, the built-in types do not have such optional fields defined. Indeed XTypes Annex D: DDS Built-in Topic Data Types has updated the built-in Topics definitions and includes some optional fields.

Also, some of the encodings allow omission of values if they are equal to the specified default value. In this case too, it is not the "unchanged" aspect that causes the omission(s), but the fact that they are equal to the default value.

Sometimes the approach of atomic updates poses a concern, typically when certain fields in a type are updated much more frequently than others. This is usually a sign that the data model has not been designed in the right way.

The built-in Topics specifically that you mention do not have this problem though. They are not expected to be updated frequently, if at all.

Reinier Torenbeek
  • 16,669
  • 7
  • 46
  • 69