Meaning of DDS::LivelinessChangedStatus::alive_count_change

[mm318]

(This issue was initially discussed here: ros2/rcl#408 (comment))

It seems as though in OpenSplice, the meaning of DDS::LivelinessChangedStatus::alive_count_change is the number of times that DDS::LivelinessChangedStatus::alive_count has changed state.

In the DDS spec, alive_count_change is defined as "The change in the alive_count since the last time the listener was called or the status was read", which is probably more likely to instead mean the change in the literal value of alive_count.

Can you please confirm our understanding?

[dirk-thomas]

@MarcelJordense Can you please take a look at this issue. We found this inconsistency while working on adding support for that QoS setting to ROS 2 and different vendors behaved differently.

[MarcelJordense]

@dirk-thomas In OpenSplice the behaviour of the DDS::LivelinessChangedStatus::alive_count_change is implemented according to the DDS spec. The DDS::LivelinessChangedStatus::alive_count_change counts the changes of the DDS::LivelinessChangedStatus::alive_count. For example when the alive_count is increased by n then also the alive_change_count is incremented by n. The alive_change_count maintains the absolute value of the changes of the alive_count since the last read or listener notification. When the listener is called or when the Liveliness status is read the alive_count_change and the not_alive_count_change are reset to 0.

[mm318]

If alive_count is increased by n and decreased by m, will alive_change_count be n+m or n-m?

[mm318]

I wonder if #79 also affects the correctness of the counting.

[MarcelJordense]

If the alive_count is increased by n and decreased by m then the alive_change_count will be n+m.
No #79 will not affect the correctness of the counting.

[mm318]

If the alive_count is increased by n and decreased by m then the alive_change_count will be n+m.

This is the point of contention. It looks like RTI Connext's implementation will return n-m.

[hansvanthag]

Indeed. The specification leaves room for interpretation and we've decided (many years ago) that 'our' interpretation is 'the right one', especially as it provides more information of 'what happened in the mean time'.

For the below exploration, lets call Alive Count=AC, AliveCountChange=ACC, NotAliveCount=NAC and NotAliveCountChange=NACC and retain 'n' and 'm' for new and disappearing writers respectively:

If you'd 'ignore' some edge-cases w.r.t. not-alive-writers re-asserting their liveliness then if our counters would be ACC=n+m and NACC=m, that would imply that RTI's interpretation of ACC being 'n-m' would equal the value of 'our' ACC-2*NACC (i.e. n+m -2m) .. but as said somewhat tricky w.r.t. 're-assertions'.

W.r.t. changing 'our' behavior: We do have a user-base that's hugely relying on backwards-compatibility, so we can't simply change our logic.

So perhaps the most obvious solution is that if you're interested in the delta of the previous and current values of AC, you could maintain the previous value yourself .. (which by the way would work with any DDS implementation) .. not sure if that's a feasible solution for you guys though ..

If that's totally unfeasible or unacceptable, the only thing remaining would be for us to add a new (differently named) counter for ACC that 'mimic' RTI's behavior .. not something that we fancy that much though :)