{{Quickfixn}} Issue 22

Wed May 23 10:06:59 PDT 2012

I guess you're done here then.  See you around.

On Wed, May 23, 2012 at 12:05 PM, Thomas Tomiczek <t.tomiczek at nettecture.com
> wrote:

>  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> 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
>
>
>
> _______________________________________________
> 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/ae7f1f92/attachment-0002.htm>