{{Quickfixn}} Issue 22

Wed May 23 10:05:16 PDT 2012

Great ;) SO happy I am not getting market data with FIX or Fast then ;)

Mine actually DOES redeliver everything ;) Every tick on all 200.000 or so symbols it tracks ;)

From: quickfixn-bounces at lists.quickfixn.com [mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Grant Birchmeier
Sent: 23 May 2012 19:04
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Issue 22

Between EndTime and StartTime, the acceptor will refuse all connections.  The initiator should not even try.

The session's first connection after StartTime should start both seq numbers at 1.  No exceptions.

In a persistent session, there should be some catch-up behavior on reconnection, but only as it pertains to sequence numbers of messages that you didn't get.  If you're monitoring market data, for example, and your client goes down for 3 minutes, the acceptor probably won't spend that 3 minutes queuing up messages to send you on reconnection.  I mean, they could, but they probably won't.  Most likely, they stopped sending anything the second you went down, and you're recovery will consist of only the few messages that were in transit when you went down.  (There may be acceptors that work differently, but this scenario is more inline with my experiences.)

As always, don't assume anything about your counterparty's FIX interface.  Check their specs.  FIX is an extraordinarily flexible protocol.

-Grant

On Wed, May 23, 2012 at 11:39 AM, Thomas Tomiczek <t.tomiczek at nettecture.com<mailto:t.tomiczek at nettecture.com>> wrote:
As someone new to FIX _ how SHOULD it be have?

If the session is persistent, then should it not continue playing back the stored messages?

Imagine at 23:14 internet goes down - then 23:15 I do not get the rest of the data?

That sounds to me like a normal continuation behaviour - at least how I would have done it. Keep numbers until next start time ;)

Just talking  here- but one thing that really interests me. Because I just happen to sit behind internet connections going down to the MOST inconvenient time. I am SURE if that would session parameters for me, and I would have a machine in my office relying on that, next day I would get exactly this down time. ;)

From: quickfixn-bounces at lists.quickfixn.com<mailto:quickfixn-bounces at lists.quickfixn.com> [mailto:quickfixn-bounces at lists.quickfixn.com<mailto:quickfixn-bounces at lists.quickfixn.com>] On Behalf Of Grant Birchmeier
Sent: 23 May 2012 18:22
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Issue 22

Hm... you're ending *before* EndTime, then manually starting *after* EndTime...?

That might be the bit of info we were lacking.  Myself, I was only checking on the auto-start/end that is triggered when the times are reached.

I'd hope that it's using the same startup-time checking code regardless of whether it's started manually or automatically, but it's possible it's not.

I've added this info to the issue.  Will have to make time to give it a shot later.

(You are using the new release, right?)

-Grant

On Wed, May 23, 2012 at 11:13 AM, Matt Wood <mjwood7 at gmail.com<mailto:mjwood7 at gmail.com>> wrote:
Related to issue 22:
https://github.com/connamara/quickfixn/issues/22

I believe I'm also encountering this. Basically if I'm manually disconnecting a session before EndTime, then manually starting it up again after StartTime on the following day, my session doesn't get reset. QuickfixN throws the "MsgSeqNum too low, expecting... " message. Relevant config values are included below:

config.cfg:

[DEFAULT]
ConnectionType=initiator
StartDay=monday
EndDay=friday
StartTime=11:00:00
EndTime=23:15:00
ResetOnLogon=N
ResetOnLogout=N
ResetOnDisconnect=N

I took a look into the code prior to running into "Session.Verify(Message logon, false, true)" and I haven't found state_.Reset() being called for this type of scenario (logoff before EndTime, logon after StartTime the next day). Could anyone verify this?

Thanks,

Matt

_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com<mailto:Quickfixn at lists.quickfixn.com>
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com<mailto:Quickfixn at lists.quickfixn.com>
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120523/37421a09/attachment-0002.htm>