Logon Message NextExpectedMsgSeqNum Processing

The NextExpectedMsgSeqNum(789) field has been added in FIX 4.4 to the Logon<A> message to support a proposed new way to resynchronize a FIX session. This new method is optional and its use should be bilaterally agreed upon between counterparties.

NextExpectedMsgSeqNum(789) is used as follows:

In its Logon<A> request the session initiator supplies in NextExpectedMsgSeqNum(789) the value next expected from the session acceptor in MsgSeqNum(34). The outgoing header MsgSeqNum(34) of the Logon<A> request is assigned the next-to-be-assigned sequence number as usual.

The session acceptor validates the Logon request including that NextExpectedMsgSeqNum(789) does not represent a gap. It then constructs its Logon<A> response with NextExpectedMsgSeqNum(789) containing the value next expected from the session initiator in MsgSeqNum(34) having incremented the number above the Logon<A> request if that was the sequence expected. The outgoing header MsgSeqNum(34) is constructed as usual.

The session initiator waits to begin sending application messages until it receives the Logon response. When it is received the initiator validates the response including that NextExpectedMsgSeqNum(789) does not represent a gap.

Both sides react to NextExpectedMsgSeqNum(789) from its counterparty thus:

• If equal to the next-to-be-assigned sequence, proceed sending new messages beginning with that number.
• If lower than the next-to-be-assigned sequence, "recover" (see "Message Recovery") all messages from the the last message delivered prior to this Logon<A> through the specified NextExpectedMsgSeqNum(789) sending them in order; then Sequence Reset-Gap Fill<4> over the sequence number used in Logon<A> and proceed sending newly queued messages with a sequence number one higher than the original Logon<A>.
• If higher than the next-to-be-assigned sequence, send Logout<5> to abort the session.

Neither side should generate a ResendRequest<2> based on MsgSeqNum(34) of the incoming Logon message but should expect any gaps to be filled automatically. If a gap is produced by the Logon message MsgSeqNum<34>, the receive logic should expect the gap to be filled automatically prior to receiving any messages with sequences above the gap.