Imported from previous forum
Hi folks,
I’m implementing 24-hour connectivity with Logon.ResetSeqNumFlag to reset the sequence numbers back to 1. However, I’m wondering about the following scenario.
The initiator of the online sequence reset first sends a TestRequest and awaits the response to ensure the counterparty has received all messages (as described on page 7 of volume 2 of the 4.4 spec) and then sends its Logon with MsgSeqNum = 1 and ResetSeqNumFlag set. The counterparty is now obliged to respond with a Logon message with MsgSeqNum = 1.
In this scenario however, the acceptor sends a business message right after it sent the response to the initiator’s TestRequest and unfortunately this message is lost. The acceptor now receives the initiator’s Logon message to which it has to respond. However, doing so would make the business message unrecoverably lost.
Have I misinterpreted the spec regarding 24-hour connectivity, or does this potential problem really exist?
kind regards,
Erik van Zijst
Dear Erik,
You’re to my understanding correct in your interpretation of the specifications. However, an engine should not issue a Logon message when a/the session is already active (“logged on”). I’d rather use a Sequence Reset (MsgType 4) or why not consider refraining from resetting the seqnum completely? With 24 hour connectivity, I see no reason for restting the seqnum. Just leave it “ticking”. Alternately a logoff, followed by logon with msgseqnum = 1 will do the trick.
Kind regards,
Soren Mikkelsen
Switzerland
Hi folks,
I’m implementing 24-hour connectivity with Logon.ResetSeqNumFlag to
reset the sequence numbers back to 1. However, I’m wondering about the
following scenario.The initiator of the online sequence reset first sends a TestRequest and
awaits the response to ensure the counterparty has received all messages
(as described on page 7 of volume 2 of the 4.4 spec) and then sends its
Logon with MsgSeqNum = 1 and ResetSeqNumFlag set. The counterparty is
now obliged to respond with a Logon message with MsgSeqNum = 1.In this scenario however, the acceptor sends a business message right
after it sent the response to the initiator’s TestRequest and
unfortunately this message is lost. The acceptor now receives the
initiator’s Logon message to which it has to respond. However, doing so
would make the business message unrecoverably lost.Have I misinterpreted the spec regarding 24-hour connectivity, or does
this potential problem really exist?kind regards, Erik van Zijst
Hi Soren,
Certain exchanges require the use of this “online reset”. We’re now busy connecting to a Euronext FIX CAP and the sequence numbers should be reset while being online.
Erik
Dear Erik,
You’re to my understanding correct in your interpretation of the
specifications. However, an engine should not issue a Logon message when
a/the session is already active (“logged on”). I’d rather use a Sequence
Reset (MsgType 4) or why not consider refraining from resetting the
seqnum completely? With 24 hour connectivity, I see no reason for
restting the seqnum. Just leave it “ticking”. Alternately a logoff,
followed by logon with msgseqnum = 1 will do the trick.Kind regards, Soren Mikkelsen Switzerland
Hi folks,
I’m implementing 24-hour connectivity with Logon.ResetSeqNumFlag to
reset the sequence numbers back to 1. However, I’m wondering about the
following scenario.The initiator of the online sequence reset first sends a TestRequest
and awaits the response to ensure the counterparty has received all
messages (as described on page 7 of volume 2 of the 4.4 spec) and then
sends its Logon with MsgSeqNum = 1 and ResetSeqNumFlag set. The
counterparty is now obliged to respond with a Logon message with
MsgSeqNum = 1.In this scenario however, the acceptor sends a business message right
after it sent the response to the initiator’s TestRequest and
unfortunately this message is lost. The acceptor now receives the
initiator’s Logon message to which it has to respond. However, doing
so would make the business message unrecoverably lost.Have I misinterpreted the spec regarding 24-hour connectivity, or does
this potential problem really exist?kind regards, Erik van Zijst
Also, much FIX software treats the MsgSeqNum field as a 32-bit, signed integer type, which has room for “only” 2 billion sequence numbers. Certainly a number that can be reached on a very busy FIX connection, so “letting them tick” may get you in trouble 
Hi Soren,
Certain exchanges require the use of this “online reset”. We’re now busy
connecting to a Euronext FIX CAP and the sequence numbers should be
reset while being online.Erik
Dear Erik,
You’re to my understanding correct in your interpretation of the
specifications. However, an engine should not issue a Logon
message when
a/the session is already active (“logged on”). I’d rather use a
Sequence Reset (MsgType 4) or why not consider refraining from
resetting the seqnum completely? With 24 hour connectivity, I see no
reason for restting the seqnum. Just leave it “ticking”. Alternately
a logoff, followed by logon with msgseqnum = 1 will do the trick.Kind regards, Soren Mikkelsen Switzerland
Hi folks,
I’m implementing 24-hour connectivity with Logon.ResetSeqNumFlag to
reset the sequence numbers back to 1. However, I’m wondering about
the following scenario.The initiator of the online sequence reset first sends a TestRequest
and awaits the response to ensure the counterparty has received all
messages (as described on page 7 of volume 2 of the 4.4 spec) and
then sends its Logon with MsgSeqNum = 1 and ResetSeqNumFlag set. The
counterparty is now obliged to respond with a Logon message with
MsgSeqNum = 1.In this scenario however, the acceptor sends a business message
right after it sent the response to the initiator’s TestRequest and
unfortunately this message is lost. The acceptor now receives the
initiator’s Logon message to which it has to respond. However, doing
so would make the business message unrecoverably lost.Have I misinterpreted the spec regarding 24-hour connectivity, or
does this potential problem really exist?kind regards, Erik van Zijst
The initiator of the online sequence reset first sends a
TestRequest and awaits the response to ensure the counterparty has
received all messages (as described on page 7 of volume 2 of the
4.4 spec) and then sends its Logon with MsgSeqNum = 1 and
ResetSeqNumFlag set. The counterparty is now obliged to respond
with a Logon message with MsgSeqNum = 1.In this scenario however, the acceptor sends a business message
right after it sent the response to the initiator’s TestRequest
and unfortunately this message is lost. The acceptor now receives
the initiator’s Logon message to which it has to respond. However,
doing so would make the business message unrecoverably lost.Have I misinterpreted the spec regarding 24-hour connectivity, or
does this potential problem really exist?
If the acceptor and initiator agrees to specify (and in this case acceptor use it to validate), LastMsgSeqNumProcessed(369) in the message header, the lost messages may be salvaged if acceptor rejects in-session logon, upon finding trade message processing discrepancy. Otherwise, IMHO, as it stands, the logon specifications you pointed out will not be adequate for this situation.
Regards, Anil
True, proper use of LastMsgSeqNumProcessed by both counterparties would discover the lost business message. Unfortunately this tag was introduced in 4.3 only, and we are currently busy integrating Euronext FIX 4.2 with online sequence reset, which lacks this tag.
I’ll discuss the issue with Euronext. Thanks for your feedback.
Erik
The initiator of the online sequence reset first sends a
TestRequest and awaits the response to ensure the counterparty
has received all messages (as described on page 7 of volume 2 of
the
4.4 spec) and then sends its Logon with MsgSeqNum = 1 and
ResetSeqNumFlag set. The counterparty is now obliged to
respond with a Logon message with MsgSeqNum = 1.In this scenario however, the acceptor sends a business message
right after it sent the response to the initiator’s TestRequest
and unfortunately this message is lost. The acceptor now
receives the initiator’s Logon message to which it has to
respond. However, doing so would make the business message
unrecoverably lost.Have I misinterpreted the spec regarding 24-hour connectivity,
or does this potential problem really exist?If the acceptor and initiator agrees to specify (and in this case
acceptor use it to validate), LastMsgSeqNumProcessed(369) in the message
header, the lost messages may be salvaged if acceptor rejects in-session
logon, upon finding trade message processing discrepancy. Otherwise,
IMHO, as it stands, the logon specifications you pointed out will not be
adequate for this situation.Regards, Anil