Home / , , / What is the best way of guaranteeing messages are received in the same order in which they are published?

What is the best way of guaranteeing messages are received in the same order in which they are published?

Two scenarios

  1. Making sure messages on the same topic are received in the order they are published (i.e. publisher send messages 1, 2, and 3 on topic A → subscriber receives messages 1, 2, and 3 on topic A in this exact order)
  2. Making sure messages of different topics are also received in the same order in which they are published (i.e. publisher send msg 1 on topic A, msg 2 on topic B, and msg 3 on topic A → subscriber receives msg 1 on topic A, msg 2 on topic B, and msg 3 on topic A in this exact order)

Configuration features

To control the order and reception of messages there are a number of factors and configuration features that can be adjusted.

General Configuration for topic reception

This is controlled by the Reliability and History settings which work in a complementary manner. A general  article is linked to here

https://kbase.zettascale.tech/article/whats-relationship-reliability-history/

In summary

‘What’ is being received (independent from ordering) is driven by multiple aspects such as reliability and history. History settings at both the sender and receiver might impact what is eventually delivered

  • when a writer exploits a KEEP_LAST history and its writing faster than the system/network can handle, data will be ‘downsampled’
  • when a reader exploits a KEEP_LAST history and is reading slower than the data arrives, data will be ‘downsampled’
  • note that the above does not constitute ‘message-loss’ , it is just how its configured to behave

Old data will never ‘overwrite’ new(er) data

  • so this ‘downsampling’ affects old(er) data
  • this is why the spec states that in steady state (no new data being produced), its the newest data that will be delivered (reliably or best-effort)

Ordering of samples of the same topic

Ordering (at a single destination) of data from a single-source is guaranteed by the DDS protocol so no configuration is required.

Ordering (at a single destination) of data from multiple sources is driven by the timestamps (where again ‘old data’ will never ‘overwrite/replace’ newer data

  • The Destination Order QoS is used to select whether the source-timestamp or the arrival-time is used for this ordering
  • Using source-timestamps requires sufficient time-alignment in the system as otherwise ‘behind-nodes’ won’t be able to deliver data that was produced ‘later’ (yet has a timestamp of ‘sooner’)
  • The elegance of using source-timestamps is that delivery-time isn’t part of the ordering equation (as that will be fully driven by source-timestamps so the delivery-delay/speed isn’t a factor), which guarantees eventual consistency over a set of distributed destinations
  • Using the (default) ordering based on arrival/destination-time doesn’t require time-alignment yet also doesn’t guarantee eventual consistency when considering multiple destinations. This is acceptable in many cases (and thus the system of proper time-alignment is not required which can be challenging)

Ordering of samples of different topics

This implies using the ‘transactional behavior’ of coherent-updates