{{Quickfixn}} Issue 22

[Grant Birchmeier]

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
> 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] *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> 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
> 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
> 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/c6eb07c4/attachment-0002.htm>