handling incorrect sequence numbers

, ,
1

Imported from previous forum

2

I am specifically thinking about a situation where both sender and acceptor has sequence gaps.

The initiator sends login request
The acceptor validates login and sends login ack
The acceptor sends a resend request.
The initiator sees the login ack and sends resend request.

If this sequence is correct, we have handling administrative messages in-spite of the sequence number.

Is this a correct interpretation?

Thomas George

3

I’m not sure I understand your question/statement and “in-spite of the sequence number”. There are specific Admin messages which are processed if the MsgSeqNum is too high (see “Response by Message Type” within “Message Recovery” in the FIX session section of the spec).

The sequence you documented is correct. Subsequent steps (asynch) would be:

  • The initiator receives and responds to ResendRequest
  • The acceptor receives and responds to ResendRequest
  • The acceptor receives and processes resent messages/Seq Reset - Gap Fill and is now "in sync"
  • The initiator receives and processes resent messages/Seq Reset - Gap Fill and is now "in sync"

You should also refer to the “FIX Session-level Test Cases and Expected Behavior” document within the FIX website’s “Organization”, “Technical Committee” archive (also part of Volume 2 in FIX 4.3 spec). This documents the “FIX Logon Process State Transition Diagram” and has several test cases which are relevant to this discussion.

> I am specifically thinking about a situation where both sender and acceptor has sequence gaps.
>
> The initiator sends login request
> The acceptor validates login and sends login ack
> The acceptor sends a resend request.
> The initiator sees the login ack and sends resend request.
>
> If this sequence is correct, we have handling administrative messages in-spite of the sequence number.
>
> Is this a correct interpretation?
>
> Thomas George
>