Handling Rssl states in ETA API

RAJ

Hi,

I'm using ETA API version 1.0.8 in Linux. The response message (RsslMsg) has three Rssl states (RsslStreamStates,
RsslDataStates and RsslStateCodes). These three states different set of possible values as defined in rsslState.h

I understand that these will have the following values as printed by example application in string format.

- Closed/Suspect/None for INVALID symol

- Open/Ok/None for VALID symbol requested part of batch

- Non-streaming/Ok/None for SNAPSHOT request.

It looks to me that different error scenarios need to be simulated in the server side to understand the combination of the states that can be sent to client.

As there could be a large number of combinations possible with these 3 states, I would like to know if there is any recommended mapping matrix to identify different use case (example: valid symbol, invalid symbol, suspect data, etc,..)

Thanks

umer.nalla

Hi @RAJ

Rather than a matrix or list of combinations, an understanding of the RsslState structure members should help you determine how best to respond based on your requirements and application implementation.

Firstly you have streamState - which represent the state of the event Stream your application has established with the server. The actual enum values for RsslStreamState are all listed in the rsslState.h file but a few key ones:

• Open - the stream is open and you will receive information as and when the data for the related item changes e.g. when the price of an instrument changes
• Non-Streaming - you made a snapshot request and once you receive the (final - if multipart) refreshMsg, the stream will be auto closed and you will not get any further updates.
• Closed - data is not available for this and not likely to be available. e.g. invalid item was requested or item no longer exists/has expired
• Closed Recover - data is not available right now, but if the application tries again later it may become available

Next you have dataState which represents the state of the actual data itself. The enum values for RsslDataStates are as follows:

• OK - Data is OK - i.e. healthy and current
• Suspect - cannot be sure the data for this item is current and accurate e.g. stale data
• No Change - no changes since previous dataState

The RsslState.code member contains RsslStateCodes - which actually provide aadditional information to try and explain the current streamState or dataState - a few possible values:

• Timeout - e.g. you received a streamState of Closed because there was a timeout somewhere upstream
• Not Entitled - you received a streamState of Closed because you are not permissioned for the item you requested
• Gap Detected - you may get a dataState of Suspect because a gap was detected in the data

So, the key members to act on are streamState and dataState - the code member along with the text member provides additional information to try and explain why the streamState or dataState are in a particular state. For example if you have Stream OK and Data Suspect, you would warn the user the data is suspect and not to be trusted. Once the Data State changes to OK again , you could update the user that the data is no longer suspect. Or if you get a Stream Closed / Data Suspect / Code Not Found - you could advise the user that the item they requested does not exist.

The RsslState.text member should only be used for alerting or logging purposes and not for decision making.