LastMsgSeqNumProcessed Logic

, ,
1

Imported from previous forum

2

[ original email was from ron newell - rnewell@cme.com ]
Should the value of LastMsgSeqNumProcessed always be next expected - 1?

During normal flow this works well. Comparing LastMsgSeqNumProcessed (next expected - 1) to last msg seq num sent will show a gap, if any, resulting from:

  1. the counterparty having a queue (backlog) of msgs to process;

  2. at higher tps, msgs in the pipe but not yet received by the counterparty.

Upon detecting a msg seq num gap, however, queues and latency are no longer the issue (eg: these msgs may be discarded or queued until the gap is filled). I would rather know the actual processing performed by the counterparty, especially because some msg types are handled uniquely. Thus:

  1. Logon with MsgSeqNum (100) too high. Process the request and then send a Resend Request. Thus,
    a) Send Logon confirmation with LastMsgSeqNumProcessed = 100.
    b) Send Resend Request(92 - infinity) with LastMsgSeqNumProcessed = 100.
    c) Receive response New Order-Single with MsgSeqNum = 92.
    d) Send next message with LastMsgSeqNumProcessed = 92.
    e) Receive response Order Status Request with MsgSeqNum = 93.
    f) Send next message with LastMsgSeqNumProcessed = 93.
    g) Etc for the remainder of the response.
    h) Then revert to normal flow.

  2. Resend Request (20 - infinity) with MsgSeqNum (100) too high. Process the request and then issue a Resend Request.
    a) Send response msg (MsgSeqNum = 20) with LastMsgSeqNumProcessed = 100.
    b) Send next response msg (MsgSeqNum = 21) with LastMsgSeqNumProcessed = 100.
    c) Etc for the remainder of the response.
    d) Send Resend Request(92 - infinity) with LastMsgSeqNumProcessed = 100.
    e) Receive response New Order-Single with MsgSeqNum = 92.
    f) Send next message with LastMsgSeqNumProcessed = 92.
    g) Etc for the remainder of the response.
    h) Then revert to normal flow.

(This might prove particularly useful during dual resend senarios as it would indicate if the counterparty has your Resend Request in hand. Otherwise, you only know at what point the counterparty detected a gap on its side.)

  1. ResetReset with MsgSeqNum (100) ignored. Process the request.
    a) Send next message with LastMsgSeqNumProcessed = 100.

My real question, I suppose, is whether the value of LastMsgSeqNumProcessed should equal:

A) the actual last message processed which is normally next expected - 1, or
B) always next expected - 1.

Thanks in advance for all thoughts and comments.

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Note for completeness that there’s also a third explanation for the observed gap.

> During normal flow this works well. Comparing LastMsgSeqNumProcessed (next expected - 1) to last msg seq num sent will show a gap, if any, resulting from:
>
> 1) the counterparty having a queue (backlog) of msgs to process;
>
> 2) at higher tps, msgs in the pipe but not yet received by the counterparty.

  1. You having a queue of inbound messages to process.

Even if the counterparty provides an immediate response to every message, you’re going to see a gap if you can’t process responses as fast as the other party is sending them.