Skip to content

Determine CME SBE message token by actingVersion #484

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
chinsaiki opened this issue Jul 31, 2017 · 2 comments
Closed

Determine CME SBE message token by actingVersion #484

chinsaiki opened this issue Jul 31, 2017 · 2 comments

Comments

@chinsaiki
Copy link

In CME SBE xml, attribute "sinceVersion" of the messageHeader may have a smaller value than attribute "sinceVersion" of the field. For example, "sinceVersion" of the messageHeader is "2", but is "8" of the field "MDEntrySize":

    <ns2:message name="MDIncrementalRefreshSessionStatistics35" id="35" description="MDIncrementalRefreshSessionStatistics" blockLength="11" semanticType="X" sinceVersion="2">
        <field name="TransactTime" id="60" type="uInt64" description="Start of event processing time in number of nanoseconds since Unix epoch" offset="0" semanticType="UTCTimestamp"/>
        <field name="MatchEventIndicator" id="5799" type="MatchEventIndicator" description="Bitmap field of eight Boolean type indicators reflecting the end of updates for a given Globex event" offset="8" semanticType="MultipleCharValue"/>
        <group name="NoMDEntries" id="268" description="Number of entries in Market Data message" blockLength="24" dimensionType="groupSize">
            <field name="MDEntryPx" id="270" type="PRICE" description="Market Data entry price" offset="0" semanticType="Price"/>
            <field name="SecurityID" id="48" type="Int32" description="Security ID " offset="8" semanticType="int"/>
            <field name="RptSeq" id="83" type="uInt32" description="MD Entry sequence number per instrument update" offset="12" semanticType="int"/>
            <field name="OpenCloseSettlFlag" id="286" type="OpenCloseSettlFlag" description="Flag describing IOP and Open Price entries" offset="16" semanticType="int"/>
            <field name="MDUpdateAction" id="279" type="MDUpdateAction" description="Market Data update action " offset="17" semanticType="int"/>
            <field name="MDEntryType" id="269" type="MDEntryTypeStatistics" description="Market Data entry type   " offset="18" semanticType="char"/>
            <field name="MDEntrySize" id="271" type="Int32NULL" description="Indicative Opening Quantity " offset="19" sinceVersion="8" semanticType="Qty"/>
        </group>
    </ns2:message>

But in OtfExample (cpp), messageTokens is decoded by templateId and actingVersion :
std::shared_ptr<std::vector<Token>> messageTokens = irDecoder.message(templateId, actingVersion);
and the actingVersion must equal to the value of the attribute "sinceVersion" of messageHeader:

if (token.signal() == Signal::BEGIN_MESSAGE && token.fieldId() == id && token.tokenVersion() == version)
{
   result = tokens;
}

That causes the massges with new fields and higher actingVersion cannot be specified correctly. So I wander whether the condition above should be:

token.tokenVersion() <= version
@tmontgomery
Copy link
Contributor

tmontgomery commented Aug 1, 2017

I think this works for the example you cite. But it seems quite reverse of what would be assumed. i.e. the otfVersion (tokenVersion) should be always higher than the actingVersion so that it knows the messages.

I think this is one area of the SBE spec that is, unfortunately, quite a mess. Versioning requires some cooperation with the schema to do the right thing. In this case, message id 35 needs to specify sinceVersion 8 since it has an element that has sinceVersion 8.

Maybe I am missing something here. But shouldn't the outer message be the same sinceVersion as the highest element?

tmontgomery added a commit that referenced this issue Aug 1, 2017
@tmontgomery
Copy link
Contributor

I've added a method, IrDecoder::message(int) that can be used to first look up by templateId, then version can be compared however is most appropriate. This aligns now with the Java version.

In the example above, it might be best to iterate over the tokens and check version and keep the max.

The IrDecoder::message(int,int) overload can be used for backwards compatibility and for an exact match.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants