Are there any ordering constraints on encoding/decoding different parts of an RSSL message?

bneway

I have an RSSL Consumer client using the Reuter's Domain Model. I also have an RSSL Producer server that is part of a testing harness to test my client. The consumer is successfully able to login, request and process source directory information, and request and process dictionary information, and I have tested this against a separate RSSL Provider sample binary. When decoding the login response (RSSL_DMT_LOGIN, RSSL_MC_REQUEST), a few questions occurred to me that I was unable to resolve from the specs. The login request message's containerType is RSSL_DT_NO_DATA and its attribContainerType is RSSL_DT_ELEMENT_LIST (UPA RDM Usage Guide Section 3.2.1). To encode the full login message, my code loosely follows the below code path:

RsslEncodeIterator encode_iterator = RSSL_INIT_ENCODE_ITERATOR;
/* clear and setup iterator */
RsslRequestMsg login_request = RSSL_INIT_REQUEST_MSG;
login_request.msgBase.msgClass = RSSL_MC_REQUEST;
login_request.msgBase.domainType = RSSL_DMT_LOGIN;
login_request.msgBase.streamId = stream_id;
login_request.msgBase.containerType = RSSL_DT_NO_DATA;
login_request.flags = RSSL_RQMF_STREAMING;
login_request.msgBase.msgKey.flags = RSSL_MKF_HAS_NAME_TYPE | RSSL_MKF_HAS_NAME | RSSL_MKF_HAS_ATTRIB;
login_request.msgBase.msgKey.nameType = RDM_LOGIN_USER_NAME;
login_request.msgBase.msgKey.name.data = username;
login_request.msgBase.msgKey.name.length = username_len;
login_request.msgBase.msgKey.attribContainerType = RSSL_DT_ELEMENT_LIST;
/* begin encode */
rsslEncodeMsgInit(&encode_iterator, &login_request, 0);
RsslElementList element_list = RSSL_INIT_ELEMENT_LIST;
rsslClearElementList(&element_list);
element_list.flags = RSSL_ELF_HAS_STANDARD_DATA;
/* encode element list init...how do i know this element list corresponds to container for the msg key attributes? */
rsslEncodeElementListInit(&encode_iterator, &element_list, NULL, 0);

RsslElementEntry element_entry = RSSL_INIT_ELEMENT_ENTRY;
element_entry.name = RSSL_ENAME_APPID;
element_entry.dataType = RSSL_DT_ASCII_STRING;
rsslEncodeElementEntry(&encode_iterator, &element_entry, &entry_data);
/* more encoding */
rsslEncodeElementListComplete(&encode_iterator, RSSL_TRUE);
/* complete encode key */
rssl_rc = rsslEncodeMsgKeyAttribComplete(&encode_iterator, RSSL_TRUE);
rsslEncodeMsgComplete(&encode_iterator, RSSL_TRUE);

There seems to be two possible sources for container types (the payload, based on login_request.msgBase.containerType, and the attributes, based on login_request.msgBase.msgKey.attribContainerType). This makes me wonder, how do I know the element list is encoded as part of the attributes and not the payload, since there is no API function to explicitly encode the attributes (e.g rsslEncodeMsgKeyAttribInit). Am I right to assume it is based on both the presence of a container type and also ordering? That is, RSSL recognizes the payload containerType is RSSL_DT_NO_DATA, and the attribContainerType is RSSL_DT_ELEMENT_LIST, and so the first encoding of an element list targets the msgKey attributes.

This raises some other questions as well. Say there is a domain with a message class that has a both a payload of element_list and also an attribute element_list. When I encode the message, is it that the attributes always get encoded first assuming there is a containerType that is not RSSL_DT_NO_DATA? Conversely, for decoding, if I want my consumer to be fully resilient to spec changes and unexpected message formatting, it is important for me to know I am decoding the expected portion of the message. If there is suddenly the presence of message key attributes when there previously wasn't (e.g. source directory refresh of UPA RDM Usage Section 4.2.2 unexpectedly has attribContainerType element_list, in addition to the usual payload of RSSL_DT_MAP), if I proceed to decode the map, will it error since I first need to decode the attributes? For this final question, I believe the answer is that I can safely ignore the attributes, since in order to decode them I would first have to call rsslDecodeMsgKeyAttrib(). However, I am still slightly confused on the encoding side how I know specifically what I am encoding, as there is no rsslEncodeMsgKeyAttribInit(). Is rsslEncodeMsgKeyAttribComplete all that is needed to indicate the termination of message key attribute encoding, such that subsequent encoding would go into the payload?

Apologies for the long question, I hope what I precisely am confused about is clear.

Thank you very much.

Jirapongse

@bneway

Thank you for reaching out to us.

If the application doesn't use a pre-encoded buffer, the encoding steps with an iterator will look like this.

The application may check the return values of the encoding functions to determine the next steps.

• RSSL_RET_ENCODE_MSG_KEY_ATTRIB indicates that initial message encoding was successful and now the application should encode msgKey attributes
• RSSL_RET_ENCODE_EXTENDED_HEADER indicates that initial message encoding (and msgKey attribute encoding) was successful, and the application should now encode extendedHeader content.
• RSSL_RET_ENCODE_CONTAINER indicates that initial encoding succeeded and that the application should now encode the specified containerType

Then, the decoding steps with an iterator look like this:

rsslDecodeMsgKeyAttrib prepares the RsslDecodeIterator to decode RsslMsg.MsgKey.EncodedAttrib information. If you do not want to decode MsgKey attribute information, you can decode the payload by using the containerType’s decode functions after rsslDecodeMsg returns.

Any ExtendedHeader information is expected to be decoded by using a separate RsslDecodeIterator.