The NextExpectedMsgSeqNum(789) was added Logon(35=A) message to FIX.4.4 to optimize resynchronization of messages when re-establishing a FIX Connection within a FIX Session. By communicating the next expected sequence number the peer FIX engine can recover any missing messages (gaps) without requiring the receipt of a ResendRequest(35=2).
If you don’t mind can you let us know here if you are using this feature in your FIX implementation? We are refactoring the FIX session layer specification and are trying to determine if this should be considered a standard feature of the protocol or a profile (variant) within the standard.
I confirm it is commonly used. On our side it helps to know if the session is ready for trading after receiving the logon message (which can trigger subsequent actions) or it has to synchronize first.
All our FIX sessions can manage this field when it is received at logon. For initiator sessions, this tag is only populated depending on configuration (because the counterpart may not support it).
Thank you for the feedback. We are winding down on a refactored FIX session layer specification along the lines of what Hanno has been doing with the FIX application layer. We added a sequence diagram that explains NextExpectedMsgSeqNum(789) feature. It is identified as an extended feature of the core session layer protocol. A worthwhile extension in my opinion. Given the reliability of networks, usually upon intiating a new FIX Connection within an existing FIX session, there is usually only one or so messages (a missed logout acknowledgement that consumed a sequence number) that needs to be reconciled.
When the session is disconnected, messages to send are queued with or without a sequence number. In case they are queued with a sequence number, the counterpart may have tens/hundreds of messages to synchronize when it connects again.