Ask Your Question
2

Are ROS2 messages guaranteed to be received by a Subscriber in the same order they were published?

asked 2018-01-18 00:03:33 -0500

edw gravatar image

According to https://github.com/ros2/ros2/wiki/Abo... it's possible to vary the QoS settings of History, Depth, Reliability and Durability. However, I can't find any mention anywhere about the Ordering of messages.

My understanding is that RTPS guarantees that messages are published in the order they are queued but I couldn't work out whether this also means that all subscribers are guaranteed to receive those messages in the same order as well.

Moreover, the ROS2 node's callback that is registered to process a message that has been subscribed to on a given topic must also be called in the same order that the message was published (i.e. not necessarily in the same order it was received at least in my understanding..).

This is obviously essential for applications such as transmitting audio or video where we most likely want to ensure subscription of all data messages in the same order they were published - possibly with the option of dropping data messages along the way if latency becomes excessive, but nonetheless preserving the chronological ordering in all cases.

Another case I want to confirm is whether messages published and subscribed to by ROS2 intra-process nodes (i.e. which do not use the DDS for transmitting the data) are also guaranteed to both publish messages and subscribe to them in the same order.

Thanks. -Ed

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
4

answered 2018-01-22 18:14:47 -0500

William gravatar image

updated 2018-01-22 18:20:52 -0500

However, I can't find any mention anywhere about the Ordering of messages.

That's correct, we don't expose that QoS setting from DDS, but if it's something you need repeatedly and there's a compelling reason to move it out of "user space" and into the "middleware space" (like performance), then we can consider adding it. To start that process I'd make an issue on the ros2/ros2 or ros2/rmw issue trackers explaining your case for it.

My understanding is that RTPS guarantees that messages are published in the order they are queued but I couldn't work out whether this also means that all subscribers are guaranteed to receive those messages in the same order as well.

My understand is that they are not guaranteed to be received in order. This is basically a performance trade-off. Especially if you're using "reliable" rather than "best effort". For example, consider you received sequence number 1, 2, and 4. How long do you wait for 3 before you deliver 4?

This is why DDS let's you configure the behavior. For example, here's the RTI Connext documentation for the ordered access kind of "presentation" QoS:

https://community.rti.com/static/docu...

I link to their documentation only because it's easy to link to, but the other DDS implementations also support it I believe (though I'm not sure about pure RTPS implementations).

There is also some flexibility as to how this is implemented. For example, this page on the CoreDX DDS implementation's page says that they will not deliver messages out of order in best effort:

http://www.twinoakscomputing.com/core...

So I think the best bet (and we should clarify this in our API documentation -- something else we could use help with :D) is to assume they are not delivered in order.

We also removed the "sequence number field" from the standard ROS Header message type ( https://github.com/ros2/common_interf... ), with the idea that it was ill formed and that the middleware should give this information outside of the message data. Unfortunately we haven't exposed this information from the middleware yet either (something we could use help with perhaps), but ideally the sequence numbers would be unique and monotonic for each separate publisher (part of the reason a sequence number in the message data was ill formed).

Moreover, the ROS2 node's callback that is registered to process a message that has been subscribed to on a given topic must also be called in the same order that the message was published (i.e. not necessarily in the same order it was received at least in my understanding..).

I don't understand why you think it "must also be called in the same order that the message was published". As far as I know, that's not a requirement or guarantee of the ROS callbacks. Delivery in order is the typical behavior, but again not required. In general they are ... (more)

edit flag offensive delete link more

Comments

Any update on this? In many applications the performance is good enough without the need for the best effort DDS mode, having also a mode which guaratees the order might prevent a lot of boilerplate code, sending int in a complex message just to transfer a time stamp with it etc.

uthinu gravatar imageuthinu ( 2018-11-07 09:34:25 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-01-18 00:03:33 -0500

Seen: 745 times

Last updated: Jan 22 '18