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

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

Correction:

That condition should read, 'endSeqNo >=3D getExpectedSenderNum()'

On Oct 19, 2004, at 9:59 AM, Oren Miller wrote:

> 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=20
> receive an ack, does not necessarily mean the counter-party did not=20
> receive the logon.  If the sequence number was not incremented, and=20
> they had actually received it without acknowledging, you would then=20
> encounter disconnect scenarios due to too low sequence numbers at some=20=

> point.  A much worse position to be in as it cannot be resolved=20
> 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=20
> this case we are talking about logon messages, all that is required is=20=

> a 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