[This message was posted by Amit Patel of IIROC <[email protected]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/d22ff595 - PLEASE DO NOT REPLY BY MAIL.]
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! [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
