Jump to content
OpenSplice DDS Forum

Guarantee message reception order


Recommended Posts

Hi everyone,

I would like to understand what is the best way of guarantying that messages are received in the same order in which they are pubblished.

In our system we have publishers and subscribers on different nodes, communicating wirelessly. Nodes communicate over different topics. All the messages sent on the same topic have the same value for the key (i.e. #pragma keylist).

What are the right configurations for these two problems:

  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)

Is it enough to use the quality of service BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS on the topic and then inherit it for publisher and subscriber or are there more configurations involved?

 

Thanks in advance,
Luca

 

 

Link to post
Share on other sites
  • generic
    • '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' .. its just how its configured to behave correctly
    • old data will never 'overwrite' new(er) data
      • so this 'downsampling' affects old(er) data
      • thats 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)
  • on (1) ordering of samples of the same topic
    • ordering (at a single destination) of data from a single-source is guaranteed by the protocol so nothing needs to be done for that
    • 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
      • yet there is a QoS to select whether the source-timestamp or the arrival-time is exploited for this ordering
      • where 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 .. which is acceptable in many cases (and thus relieving the system of proper time-alignment which can be challenging)
  • on (2) ordering of samples of different topics
    • this implies using the 'transactional behavior' of coherent-updates
      • which exactly does what is requested i.e. allow a set of updates of (potentially) different topics to be delivered as an atomic set (from the perception of the receiver)
      • where these groups-of-updates are within the BEGIN/END_COHERENT_UPDATE markers
      • see the documentation on details/examples
Link to post
Share on other sites

Hi Hans,

Thanks for your answer, as usual very detailed and very clear!

This means that in a system with one publisher and multiple subscribers (assuming that the readers can keep the pace of the writer) there should be no manual configuration required to order the incoming messages on a single topic (case 1). Is that correct?

Thanks,

Luca

Link to post
Share on other sites

Indeed thats correct.

Just don't confuse 'ordering' with 'delivery' as - as explained - not all (ordered-) data may show-up at the reader-side for the following reasons:

  • data was downsampled at the (KEEP_LAST) writer .. for reliable data this is also often called 'last-value-reliability' meaning that in this pattern, the latest data for each instance will be reliably delivered (note 'for each instance' as the 'overwrite behavior', both at sending as well as receiving side' is 'per instance')
  • data was downsampled at the (KEEP_LAST) reader, which should be not a suprise and actually a 'feature' as the reader will always get the greates/latest samples for each instance i.e .key-value in the data
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...