How FIX Engine processes the new message when it is performing resend request

, ,
1

Imported from previous forum

2

For example,FIX Engine A is performing resend request with FIX Engine B,during the process,FIX Engine A receives a message that will be sent to FIX Engine.Now the status is performing resend request,the new received message could not be sent to FIX Engine B right now,for it will bring new resend request.
Now my question is that how to deal the new message?
Method 1:store it and wait for the end of performing resend request,and then send it to FIX Engine B as a “new” message;
Method 2:consider the new received message as the one which need to “resend” to FIX Engine B,and process the message in the resend request performing.
I don’t know which method is “standare”,if anyone knows it or has the other method,please tell me,thank you very much!

3

Hi Chen,

The response to the resend request depends on how the request has been constructed. There are two sequence numbers, namely, the start and end sequence, that can be included in the resend request. If start sequence is m and end sequence is n, where n > 0 and n > m, the resend is expected only from m to n. In this case, sending the new message as a “poss-dup” (though it doesn;t do any harm) at the end, behaviourally is incorrect. Since it is not part of the requested window, it can never be a “possible duplicate”. If your engine selectively refrains from stamping the new message as “poss-duplicate” then it is fine. In this case, there can be situations where n need not necessarily be the last sequence of the session prior to the new message.

If the request is from m to 0, where m > 0, you can indeed send the new message also as a “poss-duplicate” at the end of the gap fill. When a request is put this way, it can mean that the fix engine has lost track of messages subsequent to the sequence number m. The latter is a more common approach to gap-fills.

Rgds,
Thaya.

For example,FIX Engine A is performing resend request with FIX Engine
B,during the process,FIX Engine A receives a message that will be sent
to FIX Engine.Now the status is performing resend request,the new
received message could not be sent to FIX Engine B right now,for it will
bring new resend request. Now my question is that how to deal the new
message? Method 1:store it and wait for the end of performing resend
request,and then send it to FIX Engine B as a “new” message; Method
2:consider the new received message as the one which need to “resend” to
FIX Engine B,and process the message in the resend request performing. I
don’t know which method is “standare”,if anyone knows it or has the
other method,please tell me,thank you very much!

4

Hi All,

Any approach mentioned below or others should be fine depends on the implementation stratergy. Here is my one cent to add on this question:

Common Fix Engine behaviour is that it persists outgoing messages for performing the “Resend Request”. In this case the new message received by FIX Engine A and never sent to FIX Engine B; meaning won’t be part of outgoing message persister. Fix Engine A should perform Resend request for application messages - seq. nos(m to n ; m>0 and n>= 0) -with poss dup flag “Y” and “GapFillFlag=Y” for session level messages based on outgoing mesasges persister. The new messge received during this process should go after processing the resend request otherwise it will cause another Resend Request.

Hope this will help.

Thanks.

Regards,
Amit

Hi Chen,

The response to the resend request depends on how the request has been
constructed. There are two sequence numbers, namely, the start and end
sequence, that can be included in the resend request. If start sequence
is m and end sequence is n, where n > 0 and n > m, the resend is
expected only from m to n. In this case, sending the new message as a
“poss-dup” (though it doesn;t do any harm) at the end, behaviourally is
incorrect. Since it is not part of the requested window, it can never be
a “possible duplicate”. If your engine selectively refrains from
stamping the new message as “poss-duplicate” then it is fine. In this
case, there can be situations where n need not necessarily be the last
sequence of the session prior to the new message.

If the request is from m to 0, where m > 0, you can indeed send the new
message also as a “poss-duplicate” at the end of the gap fill. When a
request is put this way, it can mean that the fix engine has lost track
of messages subsequent to the sequence number m. The latter is a more
common approach to gap-fills.

Rgds, Thaya.

For example,FIX Engine A is performing resend request with FIX
Engine B,during the process,FIX Engine A receives a message that
will be sent to FIX Engine.Now the status is performing resend
request,the new received message could not be sent to FIX Engine B
right now,for it will bring new resend request. Now my question is
that how to deal the new message? Method 1:store it and wait for the
end of performing resend request,and then send it to FIX Engine B as
a “new” message; Method
2:consider the new received message as the one which need to “resend”
to FIX Engine B,and process the message in the resend request
performing. I don’t know which method is “standare”,if anyone knows
it or has the other method,please tell me,thank you very much!