RFA C++ Dictionary/Directory download related questionary

Question

Hello LSEG Team,

We are using RFA C++ 8.2 and have implemented a feature to download Source Directory + data dictionaries (RDMFieldDictionary + enumtype.def / RWFEnum) directly from the upstream server during startup (instead of relying only on local dictionary files). This aligns with the dictionary download approach described in the RFA/RDM documentation (Dictionary domain usage).

We have a few clarifications to make our implementation production‑robust:

1) StreamState/DataState coverage for Directory & Dictionary responses

In our current implementation, for both Directory and Dictionary responses we handle:

* StreamState: OpenEnum, ClosedEnum, ClosedRecoverEnum
* DataState: OkEnum, SuspectEnum

Do we need to handle any additional StreamState/DataState combinations for Directory and Dictionary responses (e.g., Redirected / NonStreaming / other states)?

If yes, what are the expected actions per state (reissue vs fallback vs ignore)?

2) What to do if we receive a Directory UPDATE after dictionaries are loaded successfully?

If the Directory is updated after we already finished dictionary download (RefreshComplete received and dictionaries are loaded), what is the recommended behaviour?

* Should we ignore directory updates once dictionaries are loaded?
* Or should we re-request dictionaries in the same session if the directory update indicates changes (e.g., service/dictionaries provided changes)?

3) If we decide to “re-download dictionaries” on directory updates, how to handle version mismatch scenarios?

If we implement logic to refresh dictionaries when directory update arrives, and the new dictionary version is different than what we currently have:

* What is the recommended action?* Rebuild/replace dictionaries in memory and continue?
* Or treat version mismatch as a “hard error” and fallback to local files?
* Or keep existing dictionary until next restart?

4) “Updates are not allowed on dictionary” — is this correct?

The RDM usage documentation mentions dictionaries do not update and do not receive unsolicited refreshes (i.e., dictionary is delivered as refresh, possibly multipart, then complete). Can you confirm this statement for RFA C++ Dictionary domain?

5) EnumType vs Field Dictionary RT_Version mismatch

If the RT_Version / version metadata in the EnumType (RWFEnum) response doesn’t match the version information populated by the RDMFieldDictionary (RWFFld) response:

* What should the consumer do?* Reject one and retry?
* Accept both but log a warning?
* Prefer one version as source of truth?

6) Handling ClosedEnum or ClosedRecoverEnum for Directory/Dictionary streams

When we receive StreamState = ClosedEnum or ClosedRecoverEnum for Directory or Dictionary streams:

* Should we re-issue the request (and if yes, any recommended backoff/retry limits)?
* Or should we fallback to local files immediately?
* For ClosedRecoverEnum, is it expected that RFA recovers automatically, or should the application explicitly retry?

7) IndicationMask flags — which ones must be handled for Directory/Dictionary refreshes?

In response messages we can receive the following IndicationMask bits:

* DoNotCacheFlag = 0x1 (do not cache)
* DoNotFilterFlag = 0x2 (do not conflate)
* ClearCacheFlag = 0x4 (clear cache; data known invalid)
* RefreshCompleteFlag = 0x8 (final refresh / last part of multipart refresh)
* DoNotRippleFlag = 0x10 (do not ripple)

Currently we handle:

* DoNotCacheFlag, ClearCacheFlag, RefreshCompleteFlag

Questions:

* For Directory and Dictionary domain messages, do we need to handle DoNotFilterFlag and DoNotRippleFlag? If yes, what is the expected application behaviour?
* The RDM usage guide indicates Dictionary refresh uses DoNotCacheFlag, ClearCacheFlag, RefreshCompleteFlag, and mentions DoNotFilterFlag / DoNotRippleFlag as “not used” for Dictionary. Can you confirm this and advise if any exceptions exist?
* For multipart refreshes, is there any guarantee about when ClearCacheFlag appears vs RefreshCompleteFlag? (We’ve seen guidance that order is not guaranteed and should be handled independently.

Thanks in advance for your responses on each questions.

Jirapongse · Answer

@mktdata Thank you for reaching out to us. 1)StreamState/DataState coverage for Directory & Dictionary responses Those are admin domains so handling StreamState: OpenEnum, ClosedEnum, ClosedRecoverEnum and DataState: OkEnum, SuspectEnum should be enough. 2)What to do if we receive a Directory UPDATE after dictionaries are loaded successfully? Typically, there is no need to reload the dictionary when the source directory is updated. 3)If we decide to “re-download dictionaries” on directory updates, how to handle version mismatch scenarios? As far as I know, ADS loads dictionary files and provides dictionaries to consumer applications upon request. Therefore, I assume that a disconnection occurred and RFA reconnected to another ADS server that was using a different version of the data dictionary. In this scenario, all ADS servers should use the same dictionary version to ensure consistency. On the consumer side, the behavior depends on the application’s requirements. For simplicity, an application may continue using the existing dictionary until the next restart. Alternatively, the application may choose to replace it with a newer version when one becomes available. An application that has a previously cached dictionary can request only DICTIONARY_INFO. This approach avoids unnecessary bandwidth overhead by preventing the download of a dictionary the application already has. If the server indicates that a newer dictionary version is available, the application can then request the full dictionary and remove the cached version after successfully retrieving the new one. 4)Updates are not allowed on dictionary” — is this correct? Domain usage should follow the specifications defined in the RDM Usage Guide. According to the guide, the dictionary domain does not define the use of update messages, so it is correct. 5)EnumType vs Field Dictionary RT_Version mismatch You should check that ADS server and verify the dictionary versions loaded on that server. The consumer can accept both but log a warning. 6)Handling ClosedEnum or ClosedRecoverEnum for Directory/Dictionary streams For the directory domain, please check the section 4.4 Special Semantics in the RFA C++ RDM Usage Guide. For the dictionary domain, please check the section 5.8 Special Semantics in the RFA C++ RDM Usage Guide. RFA does NOT auto‑recover admin streams. Recovery is explicitly the application’s responsibility. 7)IndicationMask flags — which ones must be handled for Directory/Dictionary refreshes? According to the RDM Usage Guide, the DoNotFilterFlag and DoNotRippleFlag are not used by the dictionary domain. For the multiple parts, I checked and found that the first part contains the RSSL_RFMF_CLEAR_CACHE flag. The subsequent parts don't have the RSSL_RFMF_CLEAR_CACHE flag. The last part contains the RSSL_RFMF_REFRESH_COMPLETE flag.

EXPLORE OUR SITES