Hi @danai.ongvuttivate,

The proper way to handle this is to use the stream ID. When you make a request, you will need to associated the stream ID you use with the corresponding RIC on the request within your own application. You can do this by creating a dictionary of streamID/RIC name/value pairs. When an update occurs, you can perform a single dictionary lookup to find the corresponding RIC.

The reason the RIC comes in with the original refresh is because there is a flag you can set RSSL_MKF_HAS_NAME which tells the Provider to include the RIC within the refresh. This is an optional flag but only meant for the refresh as far as I can tell. Because ETA is meant for applications that want to maximize throughput and minimize latency, you likely would not even want to carry the RIC for the million of updates when you can simply cross reference the stream ID within your own application to find out meta data details, such as a RIC.

Hope this helps.

Hi @danai.ongvuttivate,

You may need to elaborate what you mean by "monitor refresh message".

In general, when you request for data, whether 1 RIC or multiple RICs, the requests are sent asynchronously. You will have monitor all data events that are triggered within your ETA application and match up the request with the response. You match up request/response messages using the streamID you provided when you make a request. Not all requests will result in a refresh. For example, if you make a request for an invalid RIC, you will receive a Status message indicating why the request failed.

So to summarize:

1. Request for 20++ RICs but keep track of the stream ID for each request.
2. For each event arriving, match up the stream ID in the response to determine which request.
3. A response to your initial request can either be a Status or Refresh.

Please note, depending on the type of data you request, may require additional processing. For example, MarketPrice data (level 1) will usually always provide the complete refresh message in one response. However, MarketByPrice, MarketByOrder messages are much larger and thus refreshes will be in multi-parts. Refer to the ETA Developers Guide, Chaprter 13.1 - Multi-Part Message Handling for more details.

Hi @nick.zincone.1

Many thanks for explaination. Actually, I would like to refer to update message..Sorry for wrong initial question.

I have monitored the callback and found that the RIC doesn not attach in the update message which is not the same as refresh message.

Without the RIC in message seems we cannot know each update comes for which ric. Do you have any comment on this case?