Re: [Quickfix-developers] PossDupFlag

[<OM...@th...>]

>> I have run into some confusion regarding the PossDupFlag:

>> The release notes for quickfix 1.1.0 say the application programmer is
>> responsible for handling messages with the PossDupFlag set.

>> I don't really understand the motivation for this. Isn't quickfix
>> responsible for handling the session level stuff, including guaranteed
>> delivery of messages in the correct order?

>> If I simply ignore the PossDupFlag in my fromApp method, does this mean
>> I can get the same message twice?

>> If I check for the PossDupFlag in fromApp, what is the "right thing" to
>> do with a message with PossDupFlag=Y?

I've gone and looked back at the spec and the FIX mailing list.  There is
disagreement on this, but I think the consensus is that you are right. I
also found this in the spec which backs your argument.

"Two  fields help with resending messages. The PossDupFlag is set to Y when
resending  a  message  as  the  result  of  a session level event (i.e. the
retransmission  of  a message reusing a sequence number). The PossResend is
set  to  Y  when  reissuing  a  message  with  a  new sequence number (e.g.
resending  an  order).  The  receiving  application  should  process  these
messages as follows:


PossDupFlag  -  if  a message with this sequence number has been previously
received, ignore message, if not, process normally."


So  the  answer  is  yes,  the QuickFIX session should be preventing resent
messages that have already been processed from being passed to you.


Realisticly  I  think  you  can safely skip checking for the PossDupFlag in
messages  because  QuickFIX will only submit resend request for messages it
hasn't  processed.   So  unless  there  is  a  serious error with the other
engine,  you  shouldn't  ever  see a resent message that you have processed
coming across the wire.



>> In the tradeclient example, there exists the following code in the toApp

>> method:

>>   try
>>   {
>>     FIX::PossDupFlag possDupFlag;
>>     message.getHeader().getField(possDupFlag);
>>     if(possDupFlag) throw FIX::DoNotSend();
>>   } catch(FIX::FieldNotFound&) {}

>> This code prevents all application level messages with PossDupFlag=Y
>> from being sent, right? Again, what is the motivation for this? Doesn't
>> this defeat the purpose of FIX (guaranteed delivery of messages)?

This actually has a useful purpose.  This is really targeted for
NewOrderSingle messages and should really be checking for that message
explicitly. Does this defeat the purpose of FIX guaranteed delivery?  Yes,
and that's the point.  If I send an order out that does not get processed
and a system then wants to process it say, I don't know, an hour later,
chances are the market doesn't look like it did when I wanted that order to
go out. At this point I don't want my order to go out into some random
market.  Now the exchange processing this message may very well have some
rules for out of date orders, but they may not, or they may process orders
up to 2 minuntes old and that's not good enough for me.

Realisticly this piece of code would also check for how many seconds old
this message is and determine if it wants to resend it. When a DoNotSend
exception is thrown, QuickFIX will replace the application message with a
harmless sequence gap fill, so the other side will happily get what they
want and not what you don't want them to have. It was originally written
just to simply demonstrate the functionality of DoNotSend, but a more
realistic example that explicitly checks for the message type and time of
the message would be clearer.

For other types of messages, like ExecutionReport, this code would makes no
sense because you always want to send those no matter how old.

--oren