Imported from previous forum
[ original email was from Thomas Galvin - thomas.galvin@bankofamerica.com ]
The FIX 4.1 spec states that, “When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request a possible duplicate message is generated…with the PossDupFlag…set to ‘Y’ in the header”. It also states that, “Ambiguous application level messages may be resent with thte PossResend flag set.” I read this to mean that either the receiving FIX engine (on its own) or receiving application might generate a resend message, resulting in the retransmission of possible duplicates. However, only a sending application will generate a possible resend. Yes? No?
The sending application is responsible for generating the Possible Resend. Your FIX engine should not be populating the PossResent flag by itself.
The PossDup message is generated by your FIX engine as result of a resend request from your counterparty’s FIX engine.
Later versions of the specification have clarified this language, so you may want to look at the verbiage in 4.2 Errata, 4.3 Errata or 4.4 Errata.
> The FIX 4.1 spec states that, “When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request a possible duplicate message is generated…with the PossDupFlag…set to ‘Y’ in the header”. It also states that, “Ambiguous application level messages may be resent with thte PossResend flag set.” I read this to mean that either the receiving FIX engine (on its own) or receiving application might generate a resend message, resulting in the retransmission of possible duplicates. However, only a sending application will generate a possible resend. Yes? No?
>
Hello,
First make clear that Possible Resend and Possible Duplicate messages are administrative messages, meaning, its the part of fix engine’s logic. The application using the fix engine just reads the message from the engine and checks for PossResend/PossDuplicate for handling the business logic correctly!
The fixenigine will have its own log for messages, from where it serves a resend request or generates a possible duplicate message. The apllication using the fix engine has no control over it! Or, even it never cares about it!
There is no question of sending application! Because, when an order is placed, the correspondent is the sender. When the order is executed, the exchange is the sender! So, PossResend is possible from both the sides! What i mean is, in a fix session, message is sent by both the parites! So, Resend is also possible from both the sides!
Hope i answered your question!
Thanks & Regards,
Sathya
> The FIX 4.1 spec states that, “When a FIX engine is unsure if a message was successfully received at its intended destination or when responding to a resend request a possible duplicate message is generated…with the PossDupFlag…set to ‘Y’ in the header”. It also states that, “Ambiguous application level messages may be resent with thte PossResend flag set.” I read this to mean that either the receiving FIX engine (on its own) or receiving application might generate a resend message, resulting in the retransmission of possible duplicates. However, only a sending application will generate a possible resend. Yes? No?
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
PossDupe should be considered a session-level flag. It is used by the engines in maintaining message sequence. For example, regardless of how many times message 500 is sent across the wire PossDupe, the receiving engine makes sure that message 500 gets forwarded to the application only once.
PossResend is something rarely used, and often misused. It is an application-level flag. For example, if my OMS sends an order with ClOrdID=X, and I haven’t received an ack in 30 seconds, my OMS might then send the order again with ClOrdID=X, but this time with PossResend=Y. While the engine might have sent the original order as message 800, the PossResend might go out as message 801. The sell-side FIX engine passes both messages to the application. If the first message was lost (due to an error between the engine and the application), then the second will be processed. If both were received, the application sees two orders with ClOrdID=X, the second of which is flagged PossResend, so the second is ignored.
A sell-side example might happen if the buy-side has a database problem and has lost messages. They might ask the sell-side to resend the last 10 minutes worth of Execution Reports. In this case, message 100-199 might get sent as 200-299 with PossResend=Y. The buy-side then looks at ExecID to see which messages have been processed and which haven’t.
In other words, PossDupe is used to address engine to engine message loss, which is generally the most common type of problem. PossResend addresses engine to application message loss, which (should be!) far less likely.
[ original email was from Joseph Horowitz - joey@aegisoft.com ]
> In other words, PossDupe is used to address engine to engine message loss, which is generally the most common type of problem. PossResend addresses engine to application message loss, which (should be!) far less likely.
As a side note, we have found PossResend frequently used for recovery in protocols and communication infrastructures that support more than one live connection/session to the same destination (such as commonly found in CMS & CTCI). In such cases, should a connection fail, the protocol engine can resend the messages to the same destination over any of the remaining live connections (marked as PossResend with a new set of sequence numbers). Depending on how the protocol engine is architected, it is not strictly required for the application to be involved.