Imported from previous forum
Based on the following understanding:
-
PossDupFlag is a session-level mechanism to help the fix engine to determine whether a message has been previously received
-
The fix engine will ensure that the application only ever sees one instance of any message (having checked for duplication as above)
Is it considered necessary or normal for the fix engine to pass the PossDupFlag up to the application? If so, is the application expected to pay any attention to this flag?
Is it considered an error for the application to pass a message to the fix engine with PossDupFlag set or should the fix engine only consider that flag when receiving a message from another fix engine?
The issue has come about with trying to re-route a message that has come in via one fix engine connection, out through another. The incoming message has the PossDupFlag set (due to a ResendRequest) and we are wondering whether we should strip the field out before we pass the message to the outbound fix engine.
[ original email was from Ramesh Kadambi - ramesh.kadambi@verizon.net ]
> Based on the following understanding:
>
> * PossDupFlag is a session-level mechanism to help the fix engine to determine whether a message has been previously received
>
> * The fix engine will ensure that the application only ever sees one instance of any message (having checked for duplication as above)
> Based on the following understanding:
>
> * PossDupFlag is a session-level mechanism to help the fix engine to
determine whether a message has been previously received
>
> * The fix engine will ensure that the application only ever sees one
instance of any message (having checked for duplication as above)
>
I hope you mean to verify that the given Clordid is in the system, if so has
it been processed. If not then pass the message with the possdup flag to
the Application.
> Is it considered necessary or normal for the fix engine to pass the
PossDupFlag up to the application? If so, is the application expected to pay
any attention to this flag?
>
Typically the application should worry about the PossDupFlag. This way
there can be an alert at the client in case of problems and issues. The job
of the engine is not to filter out information.
> Is it considered an error for the application to pass a message to the fix
engine with PossDupFlag set or should the fix engine only consider that flag
when receiving a message from another fix engine?
>
> The issue has come about with trying to re-route a message that has come
in via one fix engine connection, out through another. The incoming message
has the PossDupFlag set (due to a ResendRequest) and we are wondering
whether we should strip the field out before we pass the message to the
outbound fix engine.
If the PossdupFlag has been set due to a resend request, there are two
possible solutions depending on your implementation.
- Check and verify if the CLordid has been processed relayed correctly if
so you could log the exception and ignore the message. - Do not verify and relay the message as is with the possdupflag set and
let the execution point worry about it.
Note that Never strip the possdupflag in case you are relaying the message
through, it is safer to send it through.
On the messages going back to the client, The Engine should not act as a
filter. It just abstracts the session layer from the Application. So all
messages should be relayed as is and let the application worry about it.
The application will typically deal with it depending on business
needs/specs.
In general if you are implementing a conduit just relaying messages back and
forth, a good solution may be to be just that and not worry too much about
meddling with the message content.
I hope this helps.
Ramesh
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Note that I disagree with the previous response on a few points.
> Is it considered necessary or normal for the fix engine to pass the PossDupFlag up to the application? If so, is the application expected to pay any attention to this flag?
PossDupFlag is entirely a session level concept. While I don’t see harm in the engine passing it to the application, I also don’t see what significant benefit it really serves, other than possibly as an indicator that the message may be stale, having come from a Resend Request.
The FIX spec says absolutely nothing about engine<->application interaction. One can design that interface however one chooses. However, in this response, I’m assuming that the engine handles all sequence number reliability issues, and insulates the application from their complexities. Doing so is the main justification for separating the engine from the application. In this case, the engine should make sure that the application is presented with each business message, in sequence, exactly once. If so, then PossDupFlag likely will be entirely irrelevant to the application.
Now PossResend is a different matter entirely. That is an application-level concept, and must be passed to the application. A firm may send the same order twice, each with the same ClOrdID and with different sequence numbers, but the second sending would have PossResend=Y. The engine forwards it to the application, which sees PossResend, checks the ClOrdID, finds it, and thus doesn’t consider the message an error.
On the contrary, seeing a PossDupe message with the same ClOrdID (and no PossResend) is a serious error. It means either:
-
Your FIX engine has a problem. If the client sends 100 Order ABC1234, and 100 PossDupe Order ABC1234, then the engine should (making the assumptions above) only send one message 100 on to the application, hence your application only knows one ClOrdID=ABC1234.
-
The other party is doing something wrong. If they send 100 Order ABC1234 and 101 PossDupe Order ABC1234, then they have done something very wrong by sending the same ClOrdID on two different messages without setting PossResend on the message 101. In this case, your engine sees two distinct messages and must forward both to your app, and your app will not like seeing the second order without PossResend.
> Is it considered an error for the application to pass a message to the fix engine with PossDupFlag set or should the fix engine only consider that flag when receiving a message from another fix engine?
I don’t believe the application should pass PossDupFlag to an engine. The app hands the engine the messages, the engine sends them to the client without PossDupFlag, and only if the client sends a Resend Request should the engine respond by resending those messages PossDupe. In this case the application doesn’t handle the complexity of determining whether PossDupFlag should be set.
Now a possible exception here is the case where a buy-side may want to control whether an engine resends orders or gap fills over them, to prevent a stale order from being executed. Doing so violates the clean split between session and application and complicates the engine to application interface, however it can sometimes be a business requirement, and the protocol certainly accomodates it.
Note also that the app can set PossResend on the engine, and the engine must honor that and send PossResend to the client.
> The issue has come about with trying to re-route a message that has come in via one fix engine connection, out through another. The incoming message has the PossDupFlag set (due to a ResendRequest) and we are wondering whether we should strip the field out before we pass the message to the outbound fix engine.
In this case, the two session layers and sequence numbers are entirely independent. The engine should only pass a sequenced, ordered, unique stream of messages on to the other engine. For example, engine A receives the following messages and takes the following actions:
100 Order ABC1234: Forward
101 Order ABC1235: Forward
105 Order ABC1239: Send Resend Request 102 to -1
106 Order ABC1240: Send Resend Request 102 to -1
102 PD Order ABC1236: Forward
103 PD Order ABC1237: Forward
104 PD Order ABC1238: Forward
105 PD Order ABC1239: Forward
106 PD Order ABC1240: Forward
102 PD Order ABC1236: Drop (it is a duplicate)
103 PD Order ABC1237: Drop
104 PD Order ABC1238: Drop
105 PD Order ABC1239: Drop
106 PD Order ABC1240: Drop
107 Order ABC1241: Forward
108 PR Order ABC1234: Forward
So engine B sends on, using different sequence numbers:
300 Order ABC1234
301 Order ABC1235
302 Order ABC1236
303 Order ABC1237
304 Order ABC1238
305 Order ABC1239
306 Order ABC1240
307 Order ABC1241
308 PR Order ABC1234
Note that this is an ordered stream. PossDupe isn’t needed on these outbound messages. Also note the use of PossResend; it is an application-level concept that crosses session boundaries, and in this case whoever is receiving the stream from engine B will see two orders ABC1234 but will drop the latter without error as it is flagged PossResend.
Thanks Ryan. That was my understanding. It’s good to have it confirmed.