Order of received samples.

2 posts / 0 new
Last post
Offline
Last seen: 6 years 4 months ago
Joined: 05/05/2014
Posts: 4
Order of received samples.

Hello there

I have some concerns or questions about the ordering of samples in data reader queues.

It has always been my understanding that when sending data from one publisher, whether on one or multiple writers, that the samples sent will be received in the order they were written.

I've recently been looking at using ordered_access but have read some, for me, contraditory information. In some parts of the documentation (and in a number of forum posts), the ordered access is described as a way to guarantee that data on the publisher side is *read* in the order it was sent. But that the order it is received (and placed in the cache) is actually already guaranteed by the middleware to match the order in which it was sent. In other words, ordered access only ensures the order in which data is delivered to the application (The order in which it can be read).

But when I read the users manual for presensation QoS and ordered access, the example describes a case where the send and receive order is not the same. I am unsure why this would happen. Can I really not be certain when writing multiple samples, that the samples are in the reader cache in the order I wrote them?

Is this different for shared memory vs network? It was my understanding that even over network, samples written from the same thread would appear in the cache in the order they were written.

I would appreciate if someone could clear this up for me.

Offline
Last seen: 2 years 1 month ago
Joined: 01/31/2011
Posts: 37

Hi,

I can see how you were confused.  The Presentation QoS does indeed govern how data is *presented* to the user; that is, the order in which samples from the DataReader's cache are returned to the user in a call to read() or take().  I'll confirm whether there's an issue with the table (I believe it's table 6.25 in the User's Manual), but I believe it's meant to show how the DataReader will store the samples in its local cache.  So rather than the "Order received", maybe the better term is "Order stored". 

To be clear - with UDP, there is no guarantee the packets will arrive in the order they are sent.  If you send packets 1, 2, 3, 4, 5 in that order, you may actually receive them as 3,2,1,4,5.  However, RTPS uses sequence numbers to order the packets so that the sending order is preserved.  I mention this because the network may introduce this behavior, though it's rarely observed.

To summarize: the samples are sent in the order they were published.  The DataReader will process the samples in the order they were sent, but may store them in a different order.  When the application calls take() or read(), the actual order returned will be governed by the Presentation QoS.

There is no difference for shared memory or network; all of this logic applies above the transport layer, so the underlying transport has no effect.

Hope this helps, and let me know if you still need help understanding the behavior.