Re: [Quickfix-developers] SendToTarget...

[Brian E. <azz...@ya...>]

John -

As I understand SendToTarget, it's going to
increment the outbound sequence number being used by QuickFix,
regardless of whether the message actually got sent. So when you
reconnect, the login will be using a higher sequence number, which will
cause a "sequence-resend" scenario.

Example: You are at seq #12 when you drop your network connection.
Two new orders get sent to SendToTarget while you are still down,
incrementing the seq # to 14. QuickFIX reestablishes the connection by
relogging in, using seq #15. Your counterparty was expecting #13, so it
asks for everything from 13 to 14. 

At this point, unless
you've turned off PersistMessages in the config file, QuickFIX will
resend the two orders. BUT, you have control over whether they are sent
via inspecting the PossDup flag - the PossDup flag is set on any
message sent due to a resend request, even if it never actually got out
the door the first time.

At that point, I will quote a previous email: 

You can add code like the following to your "toApp" callback:

void ExampleApp::toApp(FIX::Message& message, const FIX::SessionID& sessionID) throw(FIX::DoNotSend)
{
    // Don't send messages that are being resent
    try
    {
        FIX::PossDupFlag possDupFlag;
        message.getHeader().getField( possDupFlag );
        if (possDupFlag) 
            throw FIX::DoNotSend();
    }
    catch ( FIX::FieldNotFound& ) {}    

    // Do any other processing...
}
  
QuickFIX will
set the PossDup flag on any message that is being resent. You can use
that flag to prevent all (or a subset) of messages from being resent by
simply throwing the DoNotSend exception.

My rule of thumb is
never resend messages that increase market risk (orders, amendments),
but it's OK to resend messages that decrease risk (cancels) or report
status (execution reports). 

- Brian Erst
Thynk Software, Inc.


________________________________
From: John Haldi <jr...@ya...>
To: qui...@li...
Sent: Tuesday, June 9, 2009 10:20:02 AM
Subject: [Quickfix-developers] SendToTarget...

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

I
am interested in designing behavior in my application such that I
intelligently handle a scenario whereby SendToTarget might return
False.  

The scenario I am interested in handling is one where
the FIX connection has been lost and I attempt to send a new order to
the exchange.  My problem (as I understand it) is that if I call
SendToTarget while the connection is down, QuickFix will store the
message for later transmission when the session gets reestablished.  If
you can imagine a scenario where a user tries to send an order which
fails (perhaps because the network connection to the workstation is
down), I have a potential issue with the order subsequently being
transmitted at a later time when the connection is reestablished.  If
the market has moved since, the order may now be so far away (or
through) the market that sending it would be a big issue.

Does
anybody have any insight as to what circumstances might cause
SendToTarget to fail?  Similarly does anybody have any suggestions on
how I might construct my application such that if a SendToTarget fails,
the attempted NewOrderSingle is discarded and NOT sent on a subsequent
reconnection?  (fyi I'm using the generic QF build out of the box in a
.NET environment.)

I have constructed my code such that I do
check that the session is logged on immediately prior to attempting to
send the order, but this leaves the possibility that the session drops
immediately after I check isLoggedOn but before I attempt to
SendToTarget.

Any advice would be greatly appreciated.

Many thanks,

    John