LastMsgSeqNumProcessed During Resend

, ,
1

Imported from previous forum

2

[ original email was from ron newell - ronnewell@email.com ]
When responding to a Resend Request, what value should LastMsgSeqNumProcessed contain:

  1. the same value as presented in the original message, or

  2. a new value?

3

The concept behind LastMsgSeqNumProcessed was to provide a way to “know” if your counterparty is way behind in message processing. This optional field’s value should reflect the current state of the FIX engine’s last seq num processed (or (next expected - 1)).

This provides a mechanism for a FIX engine upon receiving a message from their counterparty to compare the LastMsgSeqNumProcessed value they just received to their own last msg seq num sent (or (last sent - 1)) value to determine the "backlog" or gap.

The LastMsgSeqNumProcessed value should reflect the current state vs. prior state when responding to a ResendRequest in the same manner as SendingTime represents the current time vs. the prior state’s time.

> When responding to a Resend Request, what value should LastMsgSeqNumProcessed contain:
>
> 1) the same value as presented in the original message, or
>
> 2) a new value?
>
>
>

4

[ original email was from ron newell - rnewell@cme.com ]
Thanks for the reply.

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.

> The concept behind LastMsgSeqNumProcessed was to provide a way to “know” if your counterparty is way behind in message processing. This optional field’s value should reflect the current state of the FIX engine’s last seq num processed (or (next expected - 1)).
>
> This provides a mechanism for a FIX engine upon receiving a message from their counterparty to compare the LastMsgSeqNumProcessed value they just received to their own last msg seq num sent (or (last sent - 1)) value to determine the “backlog” or gap.
>
> The LastMsgSeqNumProcessed value should reflect the current state vs. prior state when responding to a ResendRequest in the same manner as SendingTime represents the current time vs. the prior state’s time.
>
> > When responding to a Resend Request, what value should LastMsgSeqNumProcessed contain:
> >
> > 1) the same value as presented in the original message, or
> >
> > 2) a new value?
> >
> >
> >
>