Re: [Quickfix-users] Logon Ack seqNo

[Oren M. <or...@qu...>]

Answer1:

No.  This is in fact normal behavior.  Whenever a message is sent the=20
sequence number has to be incremented.  Just because we did not receive=20=

an ack, does not necessarily mean the counter-party did not receive the=20=

logon.  If the sequence number was not incremented, and they had=20
actually received it without acknowledging, you would then encounter=20
disconnect scenarios due to too low sequence numbers at some point.  A=20=

much worse position to be in as it cannot be resolved automatically.

Having a sequence number that is too high isn't much of a problem since=20=

the two engines can resolve this on their own.  And since in this case=20=

we are talking about logon messages, all that is required is a single=20
gap fill message to put everything in order.

Answer2:

Depends on the version.  For FIX.4.2 and higher, the value should be 0.=20=

  For versions 4.1 and earlier, a special value of 999999 is used.  I'm=20=

a bit curious as to what is going on here.  Is both the initiator and=20
acceptor QuickFIX.  It seems strange because since QuickFIX 1.6, the=20
EndSeqNo is always send either 0 or 999999, never another value.  Based=20=

on this I'm guessing the acceptor in this scenario is not QuickFIX, is=20=

this correct?

As to the effect of the value 2147483647, I suspect your application=20
has stopped responding because you now got the message store trying to=20=

look up a hell of a lot of messages in a tight loop.  I suspect we can=20=

have QuickFIX handle this situation more gracefully if we consider such=20=

a situation equivalent to an infinite request as such:

   if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
        beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D =
999999 ||
        endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle=20=

bizarrely large numbers
   { endSeqNo =3D getExpectedSenderNum() - 1; }

On Oct 19, 2004, at 7:08 AM, Shamanth wrote:

> Hi
>
> I am using quickfix 1.8,
>
> While testing due to some network problems we got disconnected from=20
> the "Acceptor". In the mean time, our "initiator" tried reconnecting=20=

> to the "acceptor" every 30secs.
>
>  It tried it 8 times before it could get an ack for its logon message.
>
>  Problem1: Our initiator, sent 8 logon messages and only the 9th logon=20=

> message was ack by the acceptor. But in the meantime, our initiator=20
> incremented its MsgSeqNo, so when both the initiator and acceptor got=20=

> connected, there was a mismatch of SeqNo, and the =93acceptor=94 send =
a=20
> resendRequest to the =93initiator=94
>
> Question: Is there a way we can prevent the quickfix initiator from=20
> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the=20=

> SeqNo of the messages received was correct.
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request=20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages,=20=

> so it considers it as an error condition and stops responding to the=20=

> acceptor. Is =932147483647=94 the maximum value in resend request as =
per=20
> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
> considered as the maximum number?
>
> thanks
>  R Shamanth