1. user sends initiates a transaction after either sending/ receiving a logout.
User sends (eg) QuoteRequest after sending Logout - On rx of the logout FH will issue logout response and then close the session. In that context I would not expect it to process the subsequent message. On re-logon, the client outbound seq num will be one higher than the FH expects, and the resend logic will kick in, If the client wants, it can resend - the FH will receive the QuoteRequest(say) with PossResend=TRUE, OrigSendingTime, etc. We will send to the venue. Alternatively the client can just gap-fill. The decision is theirs.
User sends (eg) QuoteRequest after receiving Logout -
Rx'd logout was in response to client initiated logout: socket connection will be dropped, so not likely.
Rx'd logout was initiated by venue-side event: This doesn't make much sense. It must be the FH that send the logout message to the client. This can only have occurred if the venue is no longer connected, and we sent a preceding UserNotification[UserStatus=LoggedOff] to flag that status. In any case, as with std FIX session handling, the FH will wait a finite time (10s) for a graceful logout response. If not received, it will unilaterally drop the socket connection. In the intervening period, any other messages send by the Client should generate an ErrorReport.
2. same after receiving a loggedout user notification
In this scenario the FH is up and client connected/heartbeating, But no venue connectivity. Any business message will be rejected with ErrorReport until such time as the client requests the venue connection be re-established.
3. user fails to respond to a testrequest an sends no messages
This will trigger the standard graceful logout process. After the test request has been issued, we need to wait for a while. I would be content for this to be the same timeout value as used when waiting for logout responses.
4. same but in the opposite direction.
The client should behave in a symmetric manner. This would ideally be subject to conformance testing on our side.
5. Client logs in, and sends an order before receiving a login response.
Q1 - Is the logon service handling authentication, session validation etc or the FH itself?
For now, I'm assuming that the message is delivered to the FH. You make no mention of the UserRequest that must follow the logon - so I assume that has not been issued and the venue is NOT online. So response has to be LogonResponse first, then ErrorReport after.
6. Client logs in and receives a login response. Client sends an order before sending a UserRequest::LoggingIn.
As 5.
7. Client logs in and receives a login response. Client sends a UserRequest/LoggingIn. Client sends an order before receiving a UserNotification::LoggedOn.
It is possible that the UserNotification[UserStatus=LoggedOn] message was in flight - in which case client QuoteRequest(eg) would be processed correctly. Otherwise venue is not online when the message is received so ErrorReport, as with 5 & 6.
8. Client logs in and receives a login response. Client sends a UserRequest/LoggingIn. Client receives a UserNotification::LoggedOut. Client sends an order.
Again - if no venue connection is established, then we need to respond with an ErrorReport.
9. Client is logged in and the venue is logged in. Client receives a Logout. Client sends an order.
This seems to be the same as 1?
User fails to respond to a testrequest and sends no messages Same but in the opposite direction. |
Client FH logout. User sends initiates a transaction after either sending/ receiving a logout. |
Illustrate multiple logon attempts to venue - 5 attempts, one minute interval, then logout to client. Eg Consider Reuters MAPI. |
Illustrate what happens when Venue or Client connection is dropped. |
Illustrate EOD session/seq num resets. |
Multiplexing - if we have multuiple users connecting to single venue, and first user triggers logon, last user triggers logout, how de we support first user logout cleanly - eg their order cancellations that they need to be notified of... |
user sends initiates a transaction after after receiving a loggedout user notification |
MSW TODO
Single shot quote, ValidUntilTime. Possible Dealer Intervention may deliver other quote(s) prior to expiry of first. Expiry terminiates the workflow.
