Requesting dictionary from RDF-D server using UPA/ETA

My application can retrieve the dictionary from the Elektron Edge server without a problem but when it connects to an RDF-D server and issues the same request,

the Dictionary response on the RDM_DC_MT_REFRESH message has the type field in the dictionary refresh message set to 0. (DictionaryMsgEvent->pRDMDictionaryMsg->refresh->type)

The valid values in the ETA API are shown here:

typedef enum {
RDM_DICTIONARY_FIELD_DEFINITIONS = 1
RDM_DICTIONARY_ENUM_TABLES = 2
RDM_DICTIONARY_RECORD_TEMPLATES = 3
RDM_DICTIONARY_DISPLAY_TEMPLATES = 4
RDM_DICTIONARY_DATA_DEFINITIONS = 5
RDM_DICTIONARY_STYLE_SHEET = 6
RDM_DICTIONARY_REFERENCE = 7
RDM_DICTIONARY_FIELD_SET_DEFINITION = 8
RDM_DICTIONARY_ELEMENT_SET_DEFINITION = 9
} RDMDictionaryTypes;

The enum does not contain a 0 value.

Fortunately I've been able to work around the problem by specifying the path to the static dictionary files RDMFieldDictionary and enumtype.def in calls to rsslLoadFieldDictionary and rsslLoadEnumTypeDictionary.

Is it possible to get the dictionaries from an RDF-D server or must they be loaded locally from files on the disk

Answers

  • When the consumer sends the dictionary request, it specifies the dictionary name (RWFFld or RWFEnum) in the request message. Then, the provider will send the refresh message with the corresponding dictionary name. The dictionary name is defined in the message key attribute.

    <requestMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_NO_DATA" flags="0x4 (RSSL_RQMF_STREAMING)" dataSize="0">
    <key flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)" serviceId="267" name="RWFFld" filter="7"/>
    <dataBody>
    </dataBody>
    </requestMsg>

    <requestMsg domainType="RSSL_DMT_DICTIONARY" streamId="4" containerType="RSSL_DT_NO_DATA" flags="0x4 (RSSL_RQMF_STREAMING)" dataSize="0">
    <key flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)" serviceId="267" name="RWFEnum" filter="7"/>
    <dataBody>
    </dataBody>
    </requestMsg>

    <refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="" dataSize="615880">
    <key flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)" serviceId="267" name="RWFFld" filter="7"/>

    ...

    <refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="4" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="" dataSize="102159">
    <key flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)" serviceId="267" name="RWFEnum" filter="7"/>
    <dataBody>

    RsslRDMDictionaryRefresh::type is populated from the summary data in the payload of dictionary refresh message.

    image

    It is a required field. To verify the problem, please enable XML tracing in the application. Therefore, we can verify the value of Type sent in the summary data.

    You can use the below code to enable XML tracing or run rsslVAConsumer in the package with -x option.

    RsslTraceOptions traceOptions;
    RsslErrorInfo rsslErrorInfo;

    rsslClearTraceOptions(&traceOptions);
    traceOptions.traceMsgFileName = traceOutputFile;
    traceOptions.traceFlags |= RSSL_TRACE_TO_FILE_ENABLE | RSSL_TRACE_TO_MULTIPLE_FILES | RSSL_TRACE_WRITE | RSSL_TRACE_READ;
    traceOptions.traceMsgMaxFileSize = 100000000;

    rsslReactorChannelIoctl(pReactorChannel, (RsslIoctlCodes)RSSL_TRACE, (void *)&traceOptions, &rsslErrorInfo);

    Please attach the tracing file in your response.

  • Attaching the xml trace per request:
    trace.zip

  • my comments attached as text, clearly showing that

    pRsslRDMDictionaryMsgEvent->pRDMDictionaryMsg->refresh.type is 0
    NOT
    one of the values in the table in the message above.

    Note that the application logic works perfectly when connecting to an Elektron Edge server. If only has a problem when communicating with an RDF-D server.

    comments and related data structure dumps from gdb:
    my-comments.txt

  • Thank you so much for your analysis.

    For your concern about flag's values, the RsslRDMDictionaryRefreshFlags in the value added library and RsslRefreshFlags in the UPA library use the different enum for flags.

    The following is RsslRefreshFlags enum defined in rsslRefreshMsg.h.

    typedef enum {
    RSSL_RFMF_NONE = 0x0000,
    RSSL_RFMF_HAS_EXTENDED_HEADER = 0x0001,
    RSSL_RFMF_HAS_PERM_DATA = 0x0002,
    RSSL_RFMF_HAS_MSG_KEY = 0x0008,
    RSSL_RFMF_HAS_SEQ_NUM = 0x0010,
    RSSL_RFMF_SOLICITED = 0x0020,
    RSSL_RFMF_REFRESH_COMPLETE = 0x0040,
    RSSL_RFMF_HAS_QOS = 0x0080,
    RSSL_RFMF_CLEAR_CACHE = 0x0100,
    RSSL_RFMF_DO_NOT_CACHE = 0x0200,
    RSSL_RFMF_PRIVATE_STREAM = 0x0400,
    RSSL_RFMF_HAS_POST_USER_INFO = 0x0800,
    RSSL_RFMF_HAS_PART_NUM = 0x1000,
    RSSL_RFMF_HAS_REQ_MSG_KEY = 0x2000,
    RSSL_RFMF_QUALIFIED_STREAM = 0x4000
    } RsslRefreshFlags;

    The flag's value (0x168) in the XML is RsslRefreshFlags which means:

    • RSSL_RFMF_CLEAR_CACHE (0x0100) is equivalent to RDM_DC_RFF_CLEAR_CACHE (0x10)
    • RSSL_RFMF_REFRESH_COMPLETE (0x0040) is equivalent to RDM_DC_RFF_IS_COMPLETE (0x02)
    • RSSL_RFMF_SOLICITED (0x0020) is equivalent to RDM_RFF_SOLICITED (0x04)
    • RSSL_RFMF_HAS_MSG_KEY (0x0008) is equivalent to RDM_DC_RFF_HAS_INFO (0x01)

    Therefore, the flag's values in RsslRDMDictionaryRefresh::flags and the XML file represent the same meaning.

    Next, for the dictionary's type issue, the XML file indicates that the type's value in the summary data sent by RDFD is zero.

    <refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text=""  dataSize="238134">
    <key flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)" serviceId="74" name="RWFFld" filter="7"/>
    <dataBody>
    <series flags="0x7 (RSSL_SRF_HAS_SET_DEFS|RSSL_SRF_HAS_SUMMARY_DATA|RSSL_SRF_HAS_TOTAL_COUNT_HINT)" countHint="6009" containerType="RSSL_DT_ELEMENT_LIST">
    ...
    <summaryData>
    <elementList flags="0x8 (RSSL_ELF_HAS_STANDARD_DATA)">
    <elementEntry name="Type" dataType="RSSL_DT_UINT" data="0"/>
    <elementEntry name="DictionaryId" dataType="RSSL_DT_INT" data="1"/>
    <elementEntry name="Version" dataType="RSSL_DT_ASCII_STRING" data="4.00.2"/>
    </elementList>
    </summaryData>

    This could be the problem in RDFD so I have created a case to RDFD team on your behalf to verify the problem. The case number is 05106623.