Re: [Quickfix-developers] RE: [Quickfix-users] Logon Ack seqNo

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

Yes, this change is going into the next version.

--oren

On Oct 20, 2004, at 5:25 AM, Shamanth wrote:

> Hi Oren
> =A0
> Thanks for the reply, Regarding Answer 2 below,
>  =A0
> You are right, Acceptor is not a quickfix engine, but a custom built=20=

> one used by one of our providers. It seems, he is sending this huge=20
> number(2147483647)=A0in resend requests to signify infinity.=A0
> =A0
> I think the code you have give below, should solve this problem. Is it=20=

> possible to incorporate this change in the next release of quickfix.
> =A0
> thanks
> R Shamanth
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, October 19, 2004 8:29 PM
> To: Shamanth
> Cc: qui...@li...;=20
> qui...@li...
> Subject: Re: [Quickfix-users] Logon Ack seqNo
>
>
> 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=20
> the 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=20
> since the two engines can resolve this on their own. And since in this=20=

> case we are talking about logon messages, all that is required is a=20
> single gap fill message to put everything in order.
>
>
>
>  Answer2:
>
>
>
>  Depends on the version. For FIX.4.2 and higher, the value should be=20=

> 0. For versions 4.1 and earlier, a special value of 999999 is used.=20
> I'm a bit curious as to what is going on here. Is both the initiator=20=

> and acceptor QuickFIX. It seems strange because since QuickFIX 1.6,=20
> the EndSeqNo is always send either 0 or 999999, never another value.=20=

> Based on this I'm guessing the acceptor in this scenario is not=20
> QuickFIX, is 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=20
> such 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