EMA message arrival ordering

Is it possible for messages to arrive from a Reuters service out of order at the application layer - via an OmmConsumerClient callback - or is this handled lower down the stack?

For example, can message fragments arrive out of order or interleaved with another, also possibly fragmented, message?

Find more posts tagged with

c++

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

Accepted answers

Gurpreet

The messages are delivered to application in the order they are received, so I would say they can arrive out of order or interleaved with one another.

Here is an internal discussion on same subject:

Whilst transmitting a large Multi-Part Refresh for MarketByPrice or
MarketByOrder domains and before the Final Refresh Complete is sent, If there was a change which affected one of  the previously sent Orders what
happens? Would an UpdateMsg get sent out in between the multi part RefreshMsgs?


Yes, it is possible when consuming Level 2 data from both Elektron and TREP to receive update messages prior to the final refresh complete.

All comments

Gurpreet

The messages are delivered to application in the order they are received, so I would say they can arrive out of order or interleaved with one another.

Here is an internal discussion on same subject:

Whilst transmitting a large Multi-Part Refresh for MarketByPrice or
MarketByOrder domains and before the Final Refresh Complete is sent, If there was a change which affected one of  the previously sent Orders what
happens? Would an UpdateMsg get sent out in between the multi part RefreshMsgs?


Yes, it is possible when consuming Level 2 data from both Elektron and TREP to receive update messages prior to the final refresh complete.

brian.sandri

Although it is possible to recieve updates interleaved between parts of a multi-part refresh, the messages are still arriving in the order that the provider sent them in. Our underlying transports use TCP/IP which guarantees in order and reliable delivery, and in places through our networks (like the TREP RRCP backbones) these use a reliable multicast layer that sequences and retransmits packets to ensure the same in order delivery.

With the ETA/UPA API, sending applications can assign a priority to the content and this could result in the order changing between the app passing it to the API vs when it is actually pushed out to the network, but other than this (which would be intentional behavior invoked by the application) you should see your content in order.

EXPLORE OUR SITES