Will Logout(due to invalid Logon) update the last received MSN?

1

Consider the scenario A and scenario B below. Actually, I am a little puzzled if I need to update the last received MSN in scenario B. Thanks.

Scenario A

  1. The FIX session has already established(valid Logons have been exchanged successfully before).

  2. I send a Logout message to counter-party. Counter-party replies Logout message(where the MSN is N) to me. For this, I presume I need to accept this Logout and update the last received MSN = N.

Scenario B

  1. Counter-party sends Logon to me but this Logon is invalid so that I reply Logout(e.g. 1409(SessionStatus) = 5(Invalid username or password)) to the Counter-party. Here, I think the session has not been established.

  2. Counter-party receives the Logout. Counter-party sends Logout (as a reply to my Logout, e.g. 1409(SessionStatus) = 4(Session logout complete)) to me. Since the session has not been established, do I need to update the last received MSN in my side for this Logout?

2

Sounds like you want to build your own FIX engine. There are open source and commercial engines available already. Do you think it is necessary?

Edit: scenario B point 2: when you send a logout as reply to logon, why should the counter party reply with logout? Your logout is the reply to their logon and the message exchange ends there.

But in the case that you really received a logout when the session is not established you should not increment sequence numbers since there is no active session. But your scenario is no example where this will normally happen.

3

Thanks @christophjohn. I take your point. Based on my experience, some FIX engines blindly reply a Logout upon received Logout and put down 1409(SessionStatus) = 4(Session logout complete).

4

@robertlau
So do you? :wink:

1 Like
5

@christophjohn, I just have a little bit experience on the FIX parsing.

6

@robertlau in case you haven’t seen these links yet, take a look. The FIX Session layer behavior’s specification hasn’t changed in a very very long time (15+ yrs).


7

Thanks @ltaikit.