What happen with uninvited GapFill (i.e. no ResendRequest and no gap)?

, ,
1

Imported from previous forum

2

I am wondering what would you expect a FIX engine to react when an “uninvited” SequenceReset/GapFill comes in – with no actual sequence gap and no ResendRequest?

To be more specific:

A: Logon(1)
B: Logon(1)
A: Heartbeat(2)
B: Heartbeat(2)
A: Heartbeat(3)
B: Heartbeat(3)
A: ResetRequest/GapFill(1->2)

What would B do at this time?

I tend to assume that the ResetRequest/GapFill(1->2) from A is harmless though not expected, and B should be able to handle it (i.e. ignore it).

However, some FIX engine would disconnect the session complaining tthat “attempting to decrease sequence number from 4 to 2”.

What’s your opinion? Thanks.

3

I don’t think you should be allowed to decrease the sequence number. The problem is that any subsequent resend-request would not know which message to resend as the sequence numbers had been re-used and multiple messages then have the same sequence number.

Clive

I am wondering what would you expect a FIX engine to react when an
“uninvited” SequenceReset/GapFill comes in – with no actual sequence
gap and no ResendRequest?

To be more specific:

A: Logon(1)
B: Logon(1)
C: Heartbeat(2)
D: Heartbeat(2)
E: Heartbeat(3)
F: Heartbeat(3)
G: ResetRequest/GapFill(1->2)

What would B do at this time?

I tend to assume that the ResetRequest/GapFill(1->2) from A is harmless
though not expected, and B should be able to handle it (i.e. ignore it).

However, some FIX engine would disconnect the session complaining tthat
“attempting to decrease sequence number from 4 to 2”.

What’s your opinion? Thanks.

4

Thanks for replying Clive. No doubt that it’s never acceptable to decrease sequence number. However, since Engine B knows there is no incoming sequence gap, wouldn’t it have the capability to determine that the GapFill(1->2) was an accident, and hence simply ignoring it without taking any action – instead of terminating the session?

I don’t think you should be allowed to decrease the sequence number. The
problem is that any subsequent resend-request would not know which
message to resend as the sequence numbers had been re-used and multiple
messages then have the same sequence number.

Clive

5

Hi

We have implemented that scenario with a session level reject. So we keep the session logged on, but send a session level reject back to the counter-party.

Having said that… i’m not sure what the counter-party would then do as their side would be expecting to use the new sequence number they had specified in the sequence reset message. And the very likely outcome is the next message they send will have a sequence number lower than we expect, so we will then log them off.

Clive

Thanks for replying Clive. No doubt that it’s never acceptable to
decrease sequence number. However, since Engine B knows there is no
incoming sequence gap, wouldn’t it have the capability to determine that
the GapFill(1->2) was an accident, and hence simply ignoring it without
taking any action – instead of terminating the session?

I don’t think you should be allowed to decrease the sequence number.
The problem is that any subsequent resend-request would not know which
message to resend as the sequence numbers had been re-used and
multiple messages then have the same sequence number.

Clive