SequenceReset clarification

[gregorynatenzon_x]

Imported from previous forum

[gregorynatenzon_x]

Hello all,

I got a question regarding the Sequence Reset message in protocol 4.2.
The following is the scenario:

Initiator: 35=A, 34=64
Acceptor: 35=A, 34=4, 43=N
Acceptor: 35=2, 34=5, 43=N, 7=4, 16=63
Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor: 35=0, 34=6, 43=N
Initiator: 35=0, 34=64
Acceptor: 35=5, 34=7, 43=N, 58= Error: Incoming sequence number (64) is less than expected (65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor according to FIX4.2 in this case is.

Thank you

[fplpo_x]

[ original email was from John Prewett - jprewett@lavatrading.com ]
Bonjour Gregory,

The initiator is at fault with the Heartbeat message.
It sent a Heartbeat with MsgSeqNum=64 when it had previously used that sequence number in its Logon message.
The acceptor was entirely correct to get angry and logout.
It received a low sequence number (64) from the initiator when it should have been 65.
The initiator sent out a Sequence-reset/GapFill PossDup=Y message which correctly responded to the ResendRequest, after that it should have resumed its usage of sequence numbers from where it left off, which should have been 65, not 64.

JohnP

[gregorynatenzon_x]

Hi John,

Thank you very much for so timely and detailed response.
So Initiator in this case has to put NewSeqNumber (tag 36) to its next outbound sequence number (65) rather than to EndSeqNum+1 (63+1) from Acceptor’s ResendRequest message, right?

Bonjour Gregory,

The initiator is at fault with the Heartbeat message. It sent a
Heartbeat with MsgSeqNum=64 when it had previously used that sequence
number in its Logon message. The acceptor was entirely correct to get
angry and logout. It received a low sequence number (64) from the
initiator when it should have been 65. The initiator sent out a Sequence-
reset/GapFill PossDup=Y message which correctly responded to the
ResendRequest, after that it should have resumed its usage of sequence
numbers from where it left off, which should have been 65, not 64.

JohnP

[fplpo_x]

[ original email was from SENTHIL SUBRAMANIAM - sensubra@lehman.com ]
reset/GapFill response is incorrect, tag 36 should convey the next seq num which should be 65.

Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y

Senthil

Bonjour Gregory,

The initiator is at fault with the Heartbeat message. It sent a
Heartbeat with MsgSeqNum=64 when it had previously used that sequence
number in its Logon message. The acceptor was entirely correct to get
angry and logout. It received a low sequence number (64) from the
initiator when it should have been 65. The initiator sent out a Sequence-
reset/GapFill PossDup=Y message which correctly responded to the
ResendRequest, after that it should have resumed its usage of sequence
numbers from where it left off, which should have been 65, not 64.

JohnP

[fplpo_x]

[ original email was from John Prewett - jprewett@lavatrading.com ]
Sorry Senthil, I do not believe your statement below is correct.

I believe the SequenceReset/GapFill message in the original example was correct with NewSeqNo=64, although I do agree this is a slightly confusing issue.

Imagine that the sequence of messages to be retransmitted in the original example contained a NewOrderSingle in the middle (MsgSeqNum=8) of a bunch of administrative messages.

Then the initiator’s response to the ResendRequest would have to have been three messages:
35=4, 34=4, 43=Y, 36=8, 123=Y
35=D, 34=8, 43=Y
35=4, 34=9, 43=Y, 36=64, 123=Y

You will notice the first gap fill contains NewSeqNo must contain a number that is 1 higher than the gap it actually fills, otherwise the resent messages themselves would be out of sequence.

It is my opinion that NewSeqNo contains a number that is 1 higher than the gap it fills in ALL SequenceReset/GapFill messages. It doesn’t magically substitute the next actually expected message when doing a one-message response to a ResendRequest where someone is using the “fill-the-gap” method, that would be inconsistent.

Thanks

JohnP

reset/GapFill response is incorrect, tag 36 should convey the next seq
num which should be 65.

Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y

Senthil

Bonjour Gregory,

The initiator is at fault with the Heartbeat message. It sent a
Heartbeat with MsgSeqNum=64 when it had previously used that sequence
number in its Logon message. The acceptor was entirely correct to get
angry and logout. It received a low sequence number (64) from the
initiator when it should have been 65. The initiator sent out a Sequence-
reset/GapFill PossDup=Y message which correctly responded to the
ResendRequest, after that it should have resumed its usage of sequence
numbers from where it left off, which should have been 65, not 64.

JohnP

[joellouis32_x]

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So if I understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what would happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in protocol 4.2.
The following is the scenario:

Initiator: 35=A, 34=64
Acceptor: 35=A, 34=4, 43=N
Acceptor: 35=2, 34=5,43=N, 7=4, 16=63
Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N
Initiator: 35=0, 34=64
Acceptor: 35=5, 34=7, 43=N, 58= Error: Incoming sequence number (64) is less than expected (65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor according
to FIX4.2 in this case is.

Thank you

[srithayaparan_x]

Joel,

In your scenario, the fact that the acceptor has sent a resend request, means that the acceptor is behind the sender (sender has higher sequence). The format for resend requests do vary in FIX 4.2. The formats are :-

1. From m to N (Gap request)
2. From m to 0 (From m upto last sent msg)

Both these messages mean that the receiver is behind the sender or has a gap. Here (unusually) the acceptor sends out a “Gap request” (which also is technically valid as the login sequence was 64, and the acceptor needs msgs from 4 to 63). Easiest is to use the 2nd form.

The interpretation is, the acceptor has received messages successfully only upto 4 and then has received from 64 (including 64). In the resend request, tag 63 denotes the end sequence and need not necessarily mean that end-sequence + 1 th message has been received successfully.

If sender is behind (lets say the login came with sequence number 2), the the acceptor shoul immediately logout and drop the connection.

Hope this cleared your query.

Rgds,
Thaya.

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So if I
understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what would
   happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in protocol 4.2.
The following is the scenario:

Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2,
34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5, 34=7,
43=N, 58= Error: Incoming sequence number (64) is less than expected
(65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor
according to FIX4.2 in this case is.

Thank you

[joellouis32_x]

Thanks Taya,

in other word if the sequence is higher or less than expected the accepto will logout?

Joel

Joel,

In your scenario, the fact that the acceptor has sent a resend request,
means that the acceptor is behind the sender (sender has higher
sequence). The format for resend requests do vary in FIX 4.2. The
formats are :-

1. From m to N (Gap request) 2. From m to 0 (From m upto last sent msg)

Both these messages mean that the receiver is behind the sender or has a
gap. Here (unusually) the acceptor sends out a “Gap request” (which also
is technically valid as the login sequence was 64, and the acceptor
needs msgs from 4 to 63). Easiest is to use the 2nd form.

The interpretation is, the acceptor has received messages successfully
only upto 4 and then has received from 64 (including 64). In the resend
request, tag 63 denotes the end sequence and need not necessarily mean
that end-sequence + 1 th message has been received successfully.

If sender is behind (lets say the login came with sequence number 2),
the the acceptor shoul immediately logout and drop the connection.

Hope this cleared your query.

Rgds, Thaya.

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So if I
understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what would
   happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in protocol
4.2. The following is the scenario:

Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2,
34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5, 34=7,
43=N, 58= Error: Incoming sequence number (64) is less than expected
(65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor
according to FIX4.2 in this case is.

Thank you

[srithayaparan_x]

Joel,

I feel you are confused. Let me simplyfy this.

The rule is :-

1. If sequence number is less than expected, send logout and drop the connection immediately

2. If sequence number is greater than expected, send a resend request to the peer and synchronize.

In the example in hand, it is the second situation that prevails. Acceptor has sent a resend request with start seq = 4 and end sequence = 63. This means, the acceptor has got only upto sequence number 4 and thus expecting 5, whereas 64 was received. The behaviour of the acceptor, in this case is fine.

The acceptor has sent the resend with an end-of sequence by deriving it from the logon sequence of the initiator (Logon sequence - 1). This has the same effect as requesting from 4 to 0.

Regards,
Thaya.

Thanks Taya,

in other word if the sequence is higher or less than expected the
accepto will logout?

Joel

Joel,

In your scenario, the fact that the acceptor has sent a resend
request, means that the acceptor is behind the sender (sender has
higher sequence). The format for resend requests do vary in FIX 4.2.
The formats are :-

1. From m to N (Gap request) 2. From m to 0 (From m upto last
   sent msg)

Both these messages mean that the receiver is behind the sender or has
a gap. Here (unusually) the acceptor sends out a “Gap request” (which
also is technically valid as the login sequence was 64, and the
acceptor needs msgs from 4 to 63). Easiest is to use the 2nd form.

The interpretation is, the acceptor has received messages successfully
only upto 4 and then has received from 64 (including 64). In the
resend request, tag 63 denotes the end sequence and need not
necessarily mean that end-sequence + 1 th message has been received
successfully.

If sender is behind (lets say the login came with sequence number 2),
the the acceptor shoul immediately logout and drop the connection.

Hope this cleared your query.

Rgds, Thaya.

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So if
I understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what would
   happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in protocol
4.2. The following is the scenario:

Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2,
34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5,
34=7, 43=N, 58= Error: Incoming sequence number (64) is less than
expected
(65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor
according to FIX4.2 in this case is.

Thank you

[joellouis32_x]

Hey Taya,

It is clear for me now, thank you ever so much for you all for your assistance.

Joel

Joel,

I feel you are confused. Let me simplyfy this.

The rule is :-

1. If sequence number is less than expected, send logout and drop the
   connection immediately

2. If sequence number is greater than expected, send a resend request to
   the peer and synchronize.

In the example in hand, it is the second situation that prevails.
Acceptor has sent a resend request with start seq = 4 and end sequence =
63. This means, the acceptor has got only upto sequence number 4 and
thus expecting 5, whereas 64 was received. The behaviour of the
acceptor, in this case is fine.

The acceptor has sent the resend with an end-of sequence by deriving it
from the logon sequence of the initiator (Logon sequence - 1). This has
the same effect as requesting from 4 to 0.

Regards, Thaya.

Thanks Taya,

in other word if the sequence is higher or less than expected the
accepto will logout?

Joel

Joel,

In your scenario, the fact that the acceptor has sent a resend
request, means that the acceptor is behind the sender (sender has
higher sequence). The format for resend requests do vary in FIX 4.2.
The formats are :-

1. From m to N (Gap request) 2. From m to 0 (From m upto last
   sent msg)

Both these messages mean that the receiver is behind the sender
or has a gap. Here (unusually) the acceptor sends out a “Gap
request” (which also is technically valid as the login sequence
was 64, and the acceptor needs msgs from 4 to 63). Easiest is to
use the 2nd form.

The interpretation is, the acceptor has received messages
successfully only upto 4 and then has received from 64 (including
64). In the resend request, tag 63 denotes the end sequence and need
not necessarily mean that end-sequence + 1 th message has been
received successfully.

If sender is behind (lets say the login came with sequence number
2), the the acceptor shoul immediately logout and drop the
connection.

Hope this cleared your query.

Rgds, Thaya.

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So
if I understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what
   would happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in
protocol
4.2. The following is the scenario:

Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2,
34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5,
34=7, 43=N, 58= Error: Incoming sequence number (64) is less than
expected
(65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor
according to FIX4.2 in this case is.

Thank you

[seanpeng_x]

Well, for your second query, it’s clear that the acceptor would respond with a ResendRequest if the incoming message is higher than expected

Hi Guys,

I am a bit confused too here, I have 2 questions

1. We have Acceptor: 35=2, 34=5,43=N, 7=4, 16=63

Why would acceptor send Resend Request with endof sequence 63. So if I
understood 63 is the last seq acceptor has received or not?

2. This for a seq less than expected Acceptor loggout and what would
   happened then if it was higher than expected?

Thank you in advance,

Joel

Hello all,

I got a question regarding the Sequence Reset message in protocol 4.2.
The following is the scenario:

Initiator: 35=A, 34=64 Acceptor: 35=A, 34=4, 43=N Acceptor: 35=2,
34=5,43=N, 7=4, 16=63 Initiator: 35=4, 34=4, 43=Y, 36=64, 123=Y
Acceptor:35=0, 34=6, 43=N Initiator: 35=0, 34=64 Acceptor: 35=5, 34=7,
43=N, 58= Error: Incoming sequence number (64) is less than expected
(65) without PossDupFlag being set. Logging out.

Please let me know what correct behavior of Initator/Acceptor
according to FIX4.2 in this case is.

Thank you