Sequence Reset (Gap Fill)

, ,
1

Imported from previous forum

2

[ original email was from Michael Yuan - ]
I read FIX 4.2 spec regarding Sequence Reset (Gap Fill). The following is from the spec(p.33):

…
It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11).
…

I wonder why it’s possible to have multiple ResendRequests issued. If so, like the example in this section, the receiver will receive messages with MsgSeqNo lower than expected, which is a serious error ( from spec 4.2 p.20):

If the incoming message has a sequence number less than expected and the
PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session
be terminated and manual intervention be initiated.

So I think it’s impossible to receive those messages: the sender MUST guarantee not to send multiple ResendRequests, i.e., when the sender is in the state of already sending ResendRequests, even it receives new messages with MsgSeqNo higher than expected, it should wait for the response for the first ResendRequests.

Correct me if I am wrong.

Thanks,
Michael

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Michael,

It’s true that receiving multiple ResendRequests covering overlapping sequence number ranges will inevitably cause messages to be sent with low sequence numbers back to the issuer of the ResendRequests. The key issue is that all messages transmitted as a result of a ResendRequest MUST have PossDupFlag=Y. The recipient of a message with a low sequence number with PossDupFlag=Y merely discards the message and life is good.

I have seen some FIX engines that issue a ResendRequest every time they receive a high sequence message. These aren’t friendly with respect to network bandwidth. The recipient of a ResendRequest is obligated to honor it and resend all requested messages, even if the previous message happened to request exactly the same thing. If a FIX engine receives a high sequence message and issues a ResendRequest with the “thru infinity” method, it should really then start a timer and discard any further high sequence messages hoping that the ResendRequest will soon be honored and the expected sequence number will shortly be received. If the timer pops without having received the next expected sequence number, perhaps a further ResendRequest message should be sent. Simply issuing a ResendRequest upon receipt of every high sequence message in a stream of high sequence messages would cause a lot of retransmissions of identical messages.

I hope this (rambling) helps.

JohnP

I read FIX 4.2 spec regarding Sequence Reset (Gap Fill). The following
is from the spec(p.33):

… It is possible to have multiple ResendRequests issued in a row (i.e.
5 to 10 followed by 5 to 11). …

I wonder why it’s possible to have multiple ResendRequests issued. If
so, like the example in this section, the receiver will receive messages
with MsgSeqNo lower than expected, which is a serious error ( from spec
4.2 p.20):

If the incoming message has a sequence number less than expected and the
PossDupFlag is not set, it indicates a serious error. It is strongly
recommended that the session be terminated and manual intervention be
initiated.

So I think it’s impossible to receive those messages: the sender MUST
guarantee not to send multiple ResendRequests, i.e., when the sender is
in the state of already sending ResendRequests, even it receives new
messages with MsgSeqNo higher than expected, it should wait for the
response for the first ResendRequests.

Correct me if I am wrong.

Thanks, Michael