Managing Possible Duplicates

, ,
1

Imported from previous forum

2

I’m using FIX 4.2 and have a question regarding management of application messages that have the PossDupFlag set to Y.

Can I assume that if the MsgSeqNum in this message is less than the sequence number I’m expecting, then I can safely ignore this message?

If not, what is the best way to quickly identify if I should process these messages, or simply ignore them?

Thanks

Nik

3

I’m using FIX 4.2 and have a question regarding management of
application messages that have the PossDupFlag set to Y.

Can I assume that if the MsgSeqNum in this message is less than the
sequence number I’m expecting, then I can safely ignore this message?

If not, what is the best way to quickly identify if I should process
these messages, or simply ignore them?

Resending messages is part of the session level protocol, which is normally handled (nearly) transparently by your FIX engine. The engine is responsible to deliver the messages to the application in sequence.

If you want to implement your own engine, you need to know these details: Messages with a lower sequence number than already received are ignored if they are marked with PossDup=Y, otherwise they indicate a serious error.

There is another important point regarding PossDup processing:

If your side is requested to resend messages, your FIX engine has normally a method (e.g. callback) to decide whether a message should be resent as-is or as a gap fill (no-op).

Consider the following situation:

You send a NewOrderSingle with OrdType=Market to the exchange to get the current price in the market. Due to some network errors, extensive resend processing takes place (you never know which message will be resent, possibly all messages from the beginning of the session!).

After some minutes, the situation has settled and your engine resends the market order since the other side has requested it. But now the market may have changed significantly. So you want to decide whether to resend this order or not.

If you decide to drop this order, the engine will send a gap-fill to keep the message sequence. Of course, the other side has to honour your decision to drop the order: The gap-fill should have precedence over any older (buffered) versions with the same sequence number.

Such older version could exist if only some message in the middle are lost, ie

  1. you send 1, 2, 3, 4, 5
  2. counterparty gets 1, 3, 5
  3. resend request 1-infinity
  4. you re-send 1, 2, 3, 4, 5

Consider the 3 being your order, the counterparty should throw away the old version and use the gap-fill 3.

To measure the time gap between the first time the message has been sent and the resend time, the following fields are in the header:

  1. SendingTime = the time this version of the message is being sent
  2. OrigSendingTime = the first time the message with this sequence number has been sent, conditionally required if PossDup=Y

In this way, the counterparty could also drop orders if (SendingTime - OrigSendingTime) is too large.

Regards, Jörg