iLink 3 Autocert Failure for Beginning of week GTC and GTD Orders.

[millerkdm]

Artio does not correctly handle retransmits correctly for beginning of week GTC and GTD orders.

The CME Spec is here:
https://cmegroupclientsite.atlassian.net/wiki/spaces/EPICSANDBOX/pages/457093395/iLink+3+Binary+Order+Entry+-+Session+Layer#Beginning-of-Week-Initialization-and-Binding

The relevant Auotcert test is here:
https://www.cmegroup.com/tools-information/webhelp/autocert-ilink-3/Content/LogonBeginning.html

To pass the test, I changed InternalILink3Connection.onEstablishmentAck as follows (I added the first if statement):

    if (previousUUID == 0 && previousSeqNo > 0)
    {
        final long impliedNextRecvSeqNo = previousSeqNo + 1;
        final long oldNextRecvSeqNo = nextSeqNo;
        final long retransmitLastUuid = previousUUID;

        DebugLogger.log(FIXP_SESSION, "impliedNextRecvSeqNo: " + impliedNextRecvSeqNo +
            ", oldNextRecvSeqNo: " + oldNextRecvSeqNo);

        return onInvalidSequenceNumber(
            retransmitLastUuid, impliedNextRecvSeqNo, oldNextRecvSeqNo, impliedNextRecvSeqNo);
    }
    else if (previousUUID == lastUuid)
    {
        if (previousSeqNo > lastConnectionLastReceivedSequenceNumber)
        {
            final long impliedNextRecvSeqNo = previousSeqNo + 1;
            final long oldNextRecvSeqNo = lastConnectionLastReceivedSequenceNumber + 1;
            final long retransmitLastUuid = uUID == previousUUID ? lastUUIDNullValue() : previousUUID;
            return onInvalidSequenceNumber(
                retransmitLastUuid, impliedNextRecvSeqNo, oldNextRecvSeqNo, impliedNextRecvSeqNo);
        }
    }

[lpiet]

Hi MillerkDM,

I'm not party of the artio team, but working on the certification of our own system based on the artio ilink3 implementation. Just to be sure the test your referencing is:
https://www.cmegroup.com/tools-information/webhelp/autocert-ilink-3/Content/begconngt.html ?
(not the link you posted which is simply connecting beginning of the week)

I passed the test for Beginning of Week Connection with GT Orders using an unmodified artio implementation.

The only reason it works is because the lastUuid defaults to 0 as it is a primitive long, which also happens to be the value that CME gives to the previous uuid if your connecting for the first time that week.

What error are you getting? Because looking at your patch the logic seems somewhat strange:

oldNextRecvSeqNo determines the last processed seqnum from the session your requesting from. During a beginning of the week that should always default to 1, as you want everything that was undelivered during the weekend and CME starts counting that as new messages with uuid=0. Artio gets that 1 by using lastConnectionLastReceivedSequenceNumber + 1 where lastConnectionLastReceivedSequenceNumber =0 because thats what it initializes too. Using nextseqnum there seems weird as that is a value associated with your current UUID and has nothing to do with the uuid=0 session?

Note that this only works if you start with a clean run of the system after the "weekend reset") step 2 in the autocert test. If the system is left running over the weekend (or simulated as such) so no clean initilization of the primitive lastuuid and lastConnectionLastReceivedSequenceNumber takes place, which will probably break it.

Kind regards,

LP

Note that there are issues with the current implementation for Mid week Connection (Initialization and Binding) with New UUID because they don't give us access to the handlers for the session level messages.