I am trying to understand handling of retransmitted messages that come in out-of-sequence in respond to resend requests in FIX 4.2. Like in the FIX spec. , under Session Protocol, Message Recovery section, it mentions below action (double-quoted) for sender’s response when receiving a SeqReset-GapFill message with Sequence # mismatch (via a table) : " Send a ResendRequest back. Gap Fill messages behave similar to a SeqReset message. However, it is important to insure that no messages have been inadvertently skipped over. This means that GapFill messages must be received in sequence. An out of sequence GapFill is an abnormal condition" . I just wonder if this can result in an infinite loop situation:
Let’s have a very simple example below between A (resend sender) and B (resend receiver) :
A B
=== ===
resend from 7
app msg 8, 9
sequence reset gap fill 7, new 8
resend from 7
app msg 8, 9
sequence reset gap fill 7, new 8
…
…
…
Here sender A keeps on detecting the sequence reset gap fill message #7 is received out-of-sequence after receiving messages #8 and #9 and as per the spec., will just keep on issuing resent requests. As such will we end up in an infinite loop ?
Thanks
Let’s see if I understand your scenario correctly, the formatting seems to be a bit off.
Do you mean the following?
Someone sends a ResendRequest starting from 7.
That someone receives messages 8 and 9 first, then the GapFill for message 7?
Is that correct?
If yes, then I’d expect that that engine will cache messages 8 and 9 until it receives message 7. Afterwards it will process messages 8 and 9 and the normal message exchange continues since the sequence numbers will be in sync again.
That should be in line with https://www.fixtrading.org/standards/fix-session-layer-online/#fix-session-state-matrix where it is stated that messages with too high a sequence number should be queued (see number 11 and 12).
Please someone correct me if I am wrong.
Thanks,
Chris.
1 Like
Yes, this is the scenario I like to ask.
Thanks for pointing out this part of the spec. to base our discussion on. In there, under the section with title “Request retransmission of messages”, it says “Request only the specific messages missed while maintaining an ordered list of all newer messages”.
I think in my scenario, Message 8 and 9 would not be considered newer messages as they were sent before (i.e. sent as a response to resend request; in addition, they carry tags like original sending time and poss dup =Y). “newer messages” will not carry poss dup = Y and with original sending time set ?
Also think buffering will occur say like when one receives a resent request at time t0 where his last sent is say Message #450, then during processing the resend request, newer application messages like #451 to #455 need to be sent out after time t0, then #451 to #455 can be sent out at any time without original sending time and poss dup=Y when sending back retransmitted messages. The resend request sender would then need to buffer these newer messages and when it catches up to process the last received being 450 then he would go to process this buffered list.
As mentioned, the part of the spec. where I get this idea of responding with a ResendRequest is there is a table called “Response by Message Type” with 2 columns “Message Type” and “Action to Be Taken on Sequence # mismatch” as mentioned in FIX 4.2 spec. under “Session Protocol”, “Message Recovery section”. (around page 17 of the spec after I accepted all the pending edits)
Regards.
Also think buffering will occur say like when one receives a resent request at time t0 where his last sent is say Message #450, then during processing the resend request, newer application messages like #451 to #455 need to be sent out after time t0, then #451 to #455 can be sent out at any time without original sending time and poss dup=Y when sending back retransmitted messages. The resend request sender would then need to buffer these newer messages and when it catches up to process the last received being 450 then he would go to process this buffered list.
Correct, that is what I suggested in my former post.
As mentioned, the part of the spec. where I get this idea of responding with a ResendRequest is there is a table called “Response by Message Type” with 2 columns…
I would always suggest to look up session-level specific stuff in the most current specification since there might have been updates and clarifications. That table is also here:
https://www.fixtrading.org/standards/fix-session-layer-online/#processing-gaps-when-receiving-fix-session-layer-messages
However, after reading your post I am not quite sure if there still is an open question. 
Is it about the difference between already resent messages (as you said with PossDup and OrigSendingTime) and messages that were not transmitted before (i.e. without PossDup/OrigSendingTime)?
I think it does not make a difference in your scenario whether the message with sequence numbers 8 and 9 have been transmitted before or not.
The ResendRequest usually requests messages from a starting sequence number up to 0 (which means infinity, at least in FIX4.2 and newer). When the requesting FIX engine realises that there are no more missing messages then the resend request processing is finished. It does not make any difference if the incoming messages have PossDup set or not as long as they are received in sequence. But they must not have a lower sequence number than already received when PossDup is not set.
Thanks for your detailed replied. Sorry, I went off track and brought up buffering, “new” messages etc. Anyway, as per the row for SequenceReset(35=4) (GapFillFlag(123)=Y) message in the table, the proper response from the resend request sender for my scenario would be to “Send a ResendRequest(35=2)” .
Would you think so ?