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.

In addition to the nice write up from Umer, I would strongly suggest looking at the documentation, particularly the ETA Developers Guide. The Appendix A chapter has a decision table that shows the various Item or Group state combinations that are valid, along with a description of what that means and what, if any, actions an application should take as a result.