Re: [Quickfix-developers] [repost] Queuing orders before StartTime

[John G. <joh...@wa...>]

> Posting has been very active.  There is apparently something wrong  
> with the SourceForge mailing list archive.  The quickfix mailing  
> lists are also archived at gmane and nabble:
> http://www.nabble.com/QuickFIX---Dev-f1041.html
> http://dir.gmane.org/gmane.comp.finance.quickfix.devel

Thanks a lot for these links, I'll check these out tomorrow as soon as I 
get to work.

> > This is logical for an ACCEPTOR, but is both pointless (and with side
> > effects) for an INITIATOR.
> 
> Not sure what the difference is.  The only difference between an  
> initiator and acceptor is who initiates the connection.  Other than  
> this there is nothing in the FIX spec that differentiates their  
> behavior.  They are considered pears.

You are correct, I tend (wrongly) to assume the initiator sends the orders
and the acceptor collects them. What I meant is : if I am giving a new
order single to quickfix for sending as soon as the session starts, then I
don't want QF to *silently* drop the order. I know what I want to send, QF
does not and it never will be it's job to know. In fact I don't even
understand the purpose of StartTime if anything given to QF before it is
start my program at the time I want to, I don't need a deceiving internal
parameter.

> > 2) as we depend on the counterparty to detect unsent messages, if the
> > sequence numbers are not incremented, the orders are never sent.
> 
> True, but if you are sending outside of the session time, you are  
> sending on a session that does not really exist. 

I perfectly know I do. When it's Monday morning and I got something like 
one or two thousand orders to flush, it does take some time in my internal 
systems, and I garantee you I won't wait until it's session time to flush 
them or else I'll miss the opening of the market. So if I have a 
counterparty that accepts connection before being ready to really receive 
orders and who asks me not to connect before a certain time, I am screwed. 
Which is exactly what is happening right now.

> It's hard to tell  where the line gets drawn.  If you are pumping a bunch of message  
> through at the end of the day and a couple get pushed through after  
> the session closes, should QuickFIX try to send those orders when the  
> next session opens up the next day.  

End of day is indeed another story, but can be solved easily enough by 
having an endtime half an hour after the market closes, which is 
necessary anyway to get back late executions reports. And it is my job as 
a sender of the orders to format them according to the fix protocole so 
that the counterparty knows when they expire. 

Sincerely,
JG