RE: [Quickfix-users] Logon Ack seqNo

[Shamanth <sha...@in...>]

Hi Oren
=20
Thanks for the reply, Regarding Answer 2 below,=20
=20
You are right, Acceptor is not a quickfix engine, but a custom built one =
used by one of our providers. It seems, he is sending this huge =
number(2147483647) in resend requests to signify infinity.=20
=20
I think the code you have give below, should solve this problem. Is it =
possible to incorporate this change in the next release of quickfix.
=20
thanks
R Shamanth

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Tuesday, October 19, 2004 8:29 PM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-users] Logon Ack seqNo



Answer1:=20


No. This is in fact normal behavior. Whenever a message is sent the =
sequence number has to be incremented. Just because we did not receive =
an ack, does not necessarily mean the counter-party did not receive the =
logon. If the sequence number was not incremented, and they had actually =
received it without acknowledging, you would then encounter disconnect =
scenarios due to too low sequence numbers at some point. A much worse =
position to be in as it cannot be resolved automatically.=20


Having a sequence number that is too high isn't much of a problem since =
the two engines can resolve this on their own. And since in this case we =
are talking about logon messages, all that is required is a single gap =
fill message to put everything in order.=20


Answer2:=20


Depends on the version. For FIX.4.2 and higher, the value should be 0. =
For versions 4.1 and earlier, a special value of 999999 is used. I'm a =
bit curious as to what is going on here. Is both the initiator and =
acceptor QuickFIX. It seems strange because since QuickFIX 1.6, the =
EndSeqNo is always send either 0 or 999999, never another value. Based =
on this I'm guessing the acceptor in this scenario is not QuickFIX, is =
this correct?=20


As to the effect of the value 2147483647, I suspect your application has =
stopped responding because you now got the message store trying to look =
up a hell of a lot of messages in a tight loop. I suspect we can have =
QuickFIX handle this situation more gracefully if we consider such a =
situation equivalent to an infinite request as such:=20


if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||=20

beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||=20

endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle bizarrely =
large numbers=20

{ endSeqNo =3D getExpectedSenderNum() - 1; }=20



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


Hi=20


I am using quickfix 1.8,=20


While testing due to some network problems we got disconnected from the =
"Acceptor". In the mean time, our "initiator" tried reconnecting to the =
"acceptor" every 30secs.=20


It tried it 8 times before it could get an ack for its logon message.=20



Problem1: Our initiator, sent 8 logon messages and only the 9th logon =
message was ack by the acceptor. But in the meantime, our initiator =
incremented its MsgSeqNo, so when both the initiator and acceptor got =
connected, there was a mismatch of SeqNo, and the =93acceptor=94 send a =
resendRequest to the =93initiator=94=20


Question: Is there a way we can prevent the quickfix initiator from =
incrementing its SeqNo, if it did not receive Ack for its Logon msg.=20


NOTE: Only the SeqNo of the messages sent was incremented, while the =
SeqNo of the messages received was correct.=20




Problem2: After connecting again the Acceptor sent, a resend request =
FROM: 0 TO: 2147483647, our initiator had not sent so many messages, so =
it considers it as an error condition and stops responding to the =
acceptor. Is =932147483647=94 the maximum value in resend request as per =
fix protocol or should =930=94(infinity) be considered as the max =
valueis considered as the maximum number?=20


thanks=20


R Shamanth=20