FIX4.1: Logon response sequence number reversal

, ,
1

Imported from previous forum

2

Hi,

We’ve recently had an incident whereby a session logon failed because the peer’s Logon response to our initiation rewound the sequence numbers (we resumed a disconnected session; they’d reset back to 1).

I’ve checked the forums for guidance on what should happen here but it’s not clear: the only definitive thing I found is that the session should be disconnected immediately; the question is, what’s the best behaviour when doing so.

I found two suggestions which seem resonable:

  1. Send a Logout with error text in the text field. We’d need to close the session cleanly for this to work properly as our peer would see this as a “normal” logout and behave normally. However, if we did this during a session reconnection we’d then lose the previous context of the session with potentially serious effects.

  2. Send a Reject and immediately disconnect. In this case the disconnection will leave both sides with an open session. Our peer will know what’s happened from the Reject and the previous context will still be available if needed for recovery.

Is the latter to be preferred? If not, why not?

Cheers

Keith

3

Please refer to the “FIX Session Level Teset Cases and Expected Behavior”. You can find this in Volume 2 of the FIX 4.4 spec.

Hi,

We’ve recently had an incident whereby a session logon failed because
the peer’s Logon response to our initiation rewound the sequence numbers
(we resumed a disconnected session; they’d reset back to 1).

I’ve checked the forums for guidance on what should happen here but it’s
not clear: the only definitive thing I found is that the session should
be disconnected immediately; the question is, what’s the best behaviour
when doing so.

I found two suggestions which seem resonable:

  1. Send a Logout with error text in the text field. We’d need to close
    the session cleanly for this to work properly as our peer would see
    this as a “normal” logout and behave normally. However, if we did
    this during a session reconnection we’d then lose the previous
    context of the session with potentially serious effects.

  2. Send a Reject and immediately disconnect. In this case the
    disconnection will leave both sides with an open session. Our peer
    will know what’s happened from the Reject and the previous context
    will still be available if needed for recovery.

Is the latter to be preferred? If not, why not?

Cheers

Keith

4

Thanks, Scott, but it doesn’t help.

The transistion diagram is similar to the one from 2001 I’ve been using but the preamble in 4.4 suggests that initiating a Logout is the thing to do. As below I see this as a risk: if the sequence numbers are rewound when resuming a session, doing a Logout will have the likely effect of making the session subsequently unrecoverable.

To me it seems this is another case for the “When to send a Logout vs. when to just disconnect” section where there should be no Logout. At least then the session should be available for recovery.

Cheers

Keith

Please refer to the “FIX Session Level Teset Cases and Expected
Behavior”. You can find this in Volume 2 of the FIX 4.4 spec.

Hi,

We’ve recently had an incident whereby a session logon failed because
the peer’s Logon response to our initiation rewound the sequence
numbers (we resumed a disconnected session; they’d reset back to 1).

I’ve checked the forums for guidance on what should happen here but
it’s not clear: the only definitive thing I found is that the session
should be disconnected immediately; the question is, what’s the best
behaviour when doing so.

I found two suggestions which seem resonable:

  1. Send a Logout with error text in the text field. We’d need to close
    the session cleanly for this to work properly as our peer would see
    this as a “normal” logout and behave normally. However, if we did
    this during a session reconnection we’d then lose the previous
    context of the session with potentially serious effects.

  2. Send a Reject and immediately disconnect. In this case the
    disconnection will leave both sides with an open session. Our peer
    will know what’s happened from the Reject and the previous context
    will still be available if needed for recovery.

Is the latter to be preferred? If not, why not?

Cheers

Keith

5

[ original email was from Ajay Kamdar - ajay.kamdar@thomson.com ]
Keith,

Resetting of sequence number to 1 is unrelated to counter parties disconnecting gracefully by exchanging Logout messages. Typically the sequence number gets reset to 1 either
(a) at a mutually agreed upon time between the counter parties,
(b) by sending a Logon message with 141=Y, or
© manually reset by operators to resolve a seqence number mismatch

Otherwise the two counter parties can resume a session without worrying about sequence numbers having been reset to 1 even if a Logout had been sent previously. This is quite typical in 24x6 trading scenarios in which FIX sequence numbers may get reset only over the weekend, but the counter parties Logon/Logout multiple times during the week at the start and end of trading sessions.

HTH.

  • Ajay
6

Hi, Ajay,

I agree with what you say except in this situation there’s a rule that subsequent resumption of a closed session is not allowed: successful Logout implies reset. [But isn’t that the case according to the spec? “Sequence numbers are initialised at the start of each session … at 1” and “Normal termination … will be completed via the exchange of Logout messages.”]

However, here both sides should’ve resumed an existing session but one had mistakenly reset. The initiating side (A), resuming, sends the Logon >1 but sees the other side (B) has reset because the response was =1. My point is that if A then sends a Logout this will be taken as a clean closure by B and a Logout at A’s initiation should also cleanly close A’s session.

In effect, B’s error has caused A an additional support burden to recover the previous session … which could’ve been avoided if A had sent a Reject to the Logon response and abruptly terminated the session.

Cheers

Keith

Keith,
[SNIP]
This is quite typical in 24x6 trading scenarios in
which FIX sequence numbers may get reset only over the weekend, but the
counter parties Logon/Logout multiple times during the week at the start
and end of trading sessions.

7

[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
In general the 4.4 spec improves the clarity of the session protocol description over previous versions but there has been a conscious effort not to change session protocol functionality from version 4.0 onwards. The description of Logout in the 4.4 spec does need a word replaced: “Normal termination of the message exchange session will be completed via the exchange of Logout messages.” Here “session” should be replaced by “connection” based on definitions stated earlier in the Session Protocol section:

· FIX Connection is comprised of three parts: logon, message exchange, and logout.
· FIX Session is comprised of one or more FIX Connections, meaning that a FIX Session spans multiple logins.

In other words, Logout does not imply sequence reset. Also the only proper responses to correctly formatted Logon are Logon (to accept) and Logout (to reject). Reject would be used if a required field is missing or incorrectly formatted, but should never be used for a version, sequence, compid, or userid issue.

Dean

Hi, Ajay,

I agree with what you say except in this situation there’s a rule that
subsequent resumption of a closed session is not allowed: successful
Logout implies reset. [But isn’t that the case according to the spec?
“Sequence numbers are initialised at the start of each session … at 1”
and “Normal termination … will be completed via the exchange of Logout
messages.”]

However, here both sides should’ve resumed an existing session but one
had mistakenly reset. The initiating side (A), resuming, sends the Logon

1 but sees the other side (B) has reset because the response was =1. My
point is that if A then sends a Logout this will be taken as a clean
closure by B and a Logout at A’s initiation should also cleanly close
A’s session.

In effect, B’s error has caused A an additional support burden to
recover the previous session … which could’ve been avoided if A had
sent a Reject to the Logon response and abruptly terminated the session.

Cheers

Keith

Keith,
[SNIP]
This is quite typical in 24x6 trading scenarios in which FIX sequence
numbers may get reset only over the weekend, but the counter parties
Logon/Logout multiple times during the week at the start and end of
trading sessions.

8

Hmm.

So, Dean, if I read you right, the only correct response is to send a Logout which, in 4.4 won’t necessarily result in closure of the session (as opposed to the connection). That I understand.

Given that the situation is as described below and we’re operating under 4.1 AND both parties agree that Logout=session termination (because that’s what the spec says), what do I do? If I send a Logout it will close the session – cleanly – with the attendant problems.

Sorry to hammer on about this, and thanks for your interest.

Cheers again

Keith

In general the 4.4 spec improves the clarity of the session protocol description over previous versions but there has been a conscious effort not to change session protocol functionality from version 4.0 onwards. The description of Logout in the 4.4 spec does need a word replaced: “Normal termination of the message exchange session will be completed via the exchange of Logout messages.” Here “session” should be replaced by “connection” based on definitions stated earlier in the Session Protocol section:

· FIX Connection is comprised of three parts: logon, message exchange,
and logout. · FIX Session is comprised of one or more FIX Connections,
meaning that a FIX Session spans multiple logins.

In other words, Logout does not imply sequence reset. Also the only
proper responses to correctly formatted Logon are Logon (to accept) and
Logout (to reject). Reject would be used if a required field is missing
or incorrectly formatted, but should never be used for a version,
sequence, compid, or userid issue.

Dean

Hi, Ajay,

I agree with what you say except in this situation there’s a rule that
subsequent resumption of a closed session is not allowed: successful
Logout implies reset. [But isn’t that the case according to the spec?
“Sequence numbers are initialised at the start of each session … at
1” and “Normal termination … will be completed via the exchange of
Logout messages.”]

However, here both sides should’ve resumed an existing session but
one had mistakenly reset. The initiating side (A), resuming, sends
the Logon

1 but sees the other side (B) has reset because the response
was =1. My
point is that if A then sends a Logout this will be taken as a clean
closure by B and a Logout at A’s initiation should also cleanly close
A’s session.

In effect, B’s error has caused A an additional support burden to
recover the previous session … which could’ve been avoided if A had
sent a Reject to the Logon response and abruptly terminated the
session.

Cheers

Keith

Keith,
[SNIP]
This is quite typical in 24x6 trading scenarios in which FIX
sequence numbers may get reset only over the weekend, but the
counter parties Logon/Logout multiple times during the week at the
start and end of trading sessions.