Please assume below scenario,
From FIX Client perspective,
OUT(From Client to Server) : seq(34)=999, an application msg, this is received by Server side
IN(From Server to Client) : Seq(34) = 3000
OUT : seq(34)=1000 an application msg, this is NOT received by Server side when disconnection happens
---- disconnection happens ----
---- Server side Authentication service has failed, so it cannot Authenticate new logins ----
OUT : Logon(A) 34=1001
IN(i.e. response from FIX Server) : Logout(5) : 34=1 reason=Cannot accept logins at the moment
OUT : Logon(A) 34=1002
IN : Logout(5) : 34=1 reason=Cannot accept logins at the moment
OUT : Logon(A) 34=1003
IN : Logout(5) : 34=1 reason=Cannot accept logins at the moment
— Server side Authentication service is available now --------------
OUT : Logon(A) 34=1004
IN : Logon(A) 34=3001
Few questions regarding this situation
-
Is FIX Client increasing it’s output seq(34) with each login request correct ?
-
In above FINAL STATE, is it a MUST that FIX Server send a Resend Request with BeginSeq=1000 ?
If the FIX server is able to respond then you do not have a disconnection. The flow you describe above is perfectly fine, i.e. the server receives all Login requests and responds accordingly. There is no need for the FIX server to send a resend request as he has received and responded to the messages 1001-1004. However, the FIX server would have to request message 1000 first before responding to message 1001 from the client. Also, the FIX server would have to use 3001-3003 to respond to 1001-1003. The message from the FIX server accepting the Logon is then already 3004.
The lack of authentication ability is not relevant for the flow here I believe.
Hi @hanno.klein,
Thanks for responding, I presume as per your comment,
OUT : Logon(A) 34=1001
IN(i.e. response from FIX Server) : Logout(5) : 34=1 reason=Cannot accept logins at the moment
here >>>
Logout has to be sent with 34=3001
A resend request has to be sent with BeginSeq=1000
But, the problem is since user cannot be authenticated (e.g. it is possible that user is a rogue user),
-
Is it correct sending with 34=3001 (i.e. next seq no of correct user) ?
-
When should the Resend Request request be sent, before or after Logout msg ?
-
Assuming a Resend Request is sent and If user responds with a Order msg, is it correct accepting it ? Since user cannot be Authenticated and it could be a rogue user ?
Message 1001 should cause the server to realise he has missed a message (1000) and immediately send a ResendRequest before processing any subsequent messages (#2 above). The ResendRequest has to use its next seq number, i.e. 3001 (#1 above). If the user responds to the ResendRequest with a message he has not sent, then you can reject it on the basis that there is no successful login yet (#3 above). What if there is no disconnection and you get an order without having seen a login before? It is the same case in principal.
Please also have a look at the use cases (https://www.fixtrading.org/standards/fix-session-testcases-online/) and the spec itself (https://www.fixtrading.org/standards/fix-session-layer-online/).
[https://www.fixtrading.org/family-of-standards/fix-session-testcases-online/]
Could not find a scenario for this specific case of “FIX Service Open BUT cannot Authenticate”.
Scenario 1S Receive Logon message
Closest scenarios are c and d.
As per scenario c, Disconnection should be done without sending any msg.
As per scenario “d. Invalid Logon(35=A) message.”, Logout should be sent, but it does NOT mention to send a ResendRequest (unlike Scenario a.)
Not sure whether you meant this specifically for “FIX Service Open BUT cannot Authenticate” scenario or for general case.
- Receive Logon Request with Seq > Expected Seq
- Send a Resend Seq immediately
But it looks to me this is NOT what is mentioned in “Scenario 1S Receive Logon message : a. Valid Logon(35=A) request message received.” (it says to send Login Response first and send ResendRequest after that)
Please let me know if I misunderstood what you meant.
I believe the misunderstanding comes from the fact that you are combining a disconnection with an outstanding authentication of the user. These are separate issues and hence you cannot find the exact scenario you are looking for in the normative specification. That was the background of my suggestion to reduce the scenario to a simple temporary disconnection first.
sorry, I corrected the description of the question which I think is mis-leading (before the first disconnection session is in fully established mode)
From FIX Client perspective,
Client session is fully established (i.e. Requester sent the login request, a Login Accept response received and more application messages exchanged), when in this situation,
OUT(From Client to Server) : seq(34)=999, an application msg, this is received by Server side
IN(From Server to Client) : Seq(34) = 3000
OUT : seq(34)=1000 an application msg, this is NOT received by Server side when disconnection happens
---- disconnection happens ----
---- Server side Authentication service has failed, so it cannot Authenticate new logins ----
OUT : Logon(A) 34=1001
IN(i.e. response from FIX Server) : Logout(5) : 34=1 reason=Cannot accept logins at the moment
– disconnected by Server -------
OUT : Logon(A) 34=1002
IN : Logout(5) : 34=1 reason=Cannot accept logins at the moment
– disconnected by Server -------
OUT : Logon(A) 34=1003
IN : Logout(5) : 34=1 reason=Cannot accept logins at the moment
– disconnected by Server -------
— Server side Authentication service is available now --------------
OUT : Logon(A) 34=1004
IN : Logon(A) 34=3001
Few questions regarding this situation
- Is FIX Client increasing it’s output seq(34) with each login request correct ?
- In above FINAL STATE, is it a MUST that FIX Server send a Resend Request with BeginSeq=1000 ?
#1 Yes, the client has to increase his sequence number with every new request it is sending. The same goes for the FIX server where you still show 3001 as sequence number to respond to 1004. 3001 must be used to respond to 1001.
#2 Yes, the FIX server has to ensure that he has seen all messages sent to him and processed them in the correct order. The nature of the missed message does not matter for this, the resend request must be sent to find out what was missed.
Thanks.
Would you recommend from a security point of view (not exposing “Server used FIX version, Server CompID, Running FIX Seq” to a Unauthenticated user - which can be a rogue user), best thing would be to
- disconnect the TCP connection without sending any msg
or
- avoid accepting new TCP connections
when Authentication cannot be done ? (instead of sending a Logout msg)
Suggest to follow scenario 1S-c (https://www.fixtrading.org/standards/fix-session-testcases-online#scenario-1s-receive-logon-message) which recommends as follows:
1. Generate an error condition in test output.
2. Disconnect without sending a message (Note: sending a Reject or Logout(35=5) would consume a MsgSeqNum(34)).
The condition for such a response is defined in scenario 1S-c as:
Logon(35=A) message received with unauthenticated/non-configured identity (e.g. invalid SenderCompID(49), invalid TargetCompID(56), invalid source IP address, etc. vs. system configuration).
I see the inability to authenticate as being similar enough to your use case.