Dropping out of order messages

4 posts / 0 new
Last post
Offline
Last seen: 5 years 11 months ago
Joined: 08/25/2015
Posts: 5
Dropping out of order messages

Suppose that I am fine with messages being dropped but am not fine with messages arriving out of order.  That is, if a message is older than one I have already received, I want it to be ignored.

Is there anything in the RTI DDS API that would allow me to specify that that is what I want, or will I have to implement some check for this in the application?

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 12 hours ago
Joined: 06/02/2010
Posts: 601

What do you mean by "out of order"? Do you mean messages sent from a single DataWriter, a single DomainParticipant, or do you mean accorss different applicatios based on some "global time order"?

  • Messages from a single DataWriter always presserve their order when put into the DataReader cache. The middlware would drop a message rather than accept it out of order. This happens for all Qos setings. But one thing is to have the messages in order in teh DataReader cache and another that the application reads them in order.  If you call the regular read/take APIs then you will get them in the same order as they are in the cache which wil preserve the writer order. But if you start taking them using QueryConditions or read by insance etc. Then you will could be skipping some messages that are in the DataReader cache and access them later out of order.
  • Messages from different DataWriters even if i the same DOmainParticipants can arrive out of order. This is often desirable to be able to prioritize certain flows over others. But you can prevent that by placing the DataWriter ithe same Pubisher and cpnfiguring the PresentationQos to have access_scope set to GROUP.
  • Messages from DataWriters in differnt DomainParticipants can arrive to a DataReader out or order. This is because in general there is no easy way to define a total order. However if your clocks are sufficiently synchronzed you could set the DestinationOrderQos to "BY_SOURCE_TIMESTAMP" and that willl ensure messages are acceoted in "source timestamp" order.

So there are different mechanisms available which depend on the use-case.

Regards,

Gerardo

Offline
Last seen: 5 years 11 months ago
Joined: 08/25/2015
Posts: 5

I mean messages sent from a single DataWriter, a single DomainParticipant.

I am a little confused by your statement: "The middlware would drop a message rather than accept it out of order. This happens for all Qos setings."  It seems that it might contradict the RTI DDS 4.5d User's Manual, quoted below:

10.1.1 Best-effort Delivery Model
By default, RTI Data Distribution Service uses the best-effort delivery model: there is no
effort spent ensuring in-order delivery or resending lost samples.

I guess, then, that even though there is no effort spent ensuring in-order delivery, the middleware still drops out-of-order messages.  Is that correct?

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 12 hours ago
Joined: 06/02/2010
Posts: 601

Yes, you are right the statement "there is no effort spent ensuring in-order delivery or resending lost samples" is not entirely correct. 

In "Best efforts" there is a little bit of effort to ensure there are no duplicates or our-of-order samples. Basically the DataReader keeps the higuest accepted sequence number from each DataWriter. If a sample arrives with sequence number less or equal to that higuest accepted sequence number it will be dropped. This avoids both duplicates and out of order samples.

Gerardo