TODO

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?

Overview

Session Types

Whisperer SBE4 Maintains the following session types:

• Pricing - used for delivery of Market Data from a CLOB Venue, or ESP mass-quotes from a Maker.
• Orders - used for submission and execution of CLOB Venue orders, or trading against ESP Maker liquidity (published on a separate Pricing session).
• RFS - used for the full RFS/RFQ quotation negotiation life cycle between Maker and Taker.
• DropCopy - used for the delivery of post-Trade Straight-Through Processing (STP) trade notifications. Typically this will be 

Session Schedule

All session types are maintained directly with an individual Whisperer Feed Handler and operate a weekly schedule commencing on Sunday prior to Asia-open and ending on Friday, NY-close. This is irrespective of the schedule of the Venue itself,

Message Header

In addition to the default SBE message header fields (blockLength, templateId, schemaId and version), the MFSBE4 header additionally defines the mandatory population of the following fields:

• messageLength - this is provided to allow verification that the full message has indeed been received (e.g. should it span multiple packets).
• msgSeqNum - this is the standard integer message sequence number. At the start of a session it should be set to '1', and incremented with every subsequent message sent.
• sendingTime - nanosecond-precision timestamp indicating when the message left the sender.

Logon

Session Synchronisation

The Whisperer SBE4 APi utilises the 'new' model of session synchronisation introduced in FIX 4.4. This ensures that each side can expect any sequence number gaps to be filled automatically, eliminating the need for ResendRequest messages - and the problems that historically accompany these.

The MFAPI client initiates a new session with a Logon message - this contains the next MsgSeqNum[34] value that the client expects to receive from the Whisperer Feed Handler. 

The Whisperer Feed Handler validates the sequence number value as expected by the MFAPI client as follows:

If the Client is expecting a sequence number higher than the FH's next-to-be-assigned msgSeqNum, then this is an unrecoverable error and the FH will abort the session with a Logout message.

Otherwise the FH will issue a LogonResponse message containing the next MsgSeqNum[34] value that it expects to receive from the client.

If the Client is expecting a sequence number lower than the FH's next-to-be-assigned msgSeqNum[34], then the message gap is resolved by the FH with SequenceResetGapFill messages and the resending of persisted messages as necessary.

The Whisperer Feed Handler signals it's completion of session synchronisation with a TestRequest.

After any inbound sequence number gaps have been resolved for the MFAPI Client, it then reciprocates in a similar manner, based on the the next MsgSeqNum[34] value that the Whisperer Feed Handler expects to receive from the client - as specified in it's LogonResponse.

The mutual exchange of TestRequest and Heartbeat (response) messages are required as verification that no sequence number gaps remain. The MFAPI client should only proceed after it has received the Heartbeat sent in response to it's own TestRequest.

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: Logon 4.0 Sequence_3

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Message Persistence

The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:

Logon to Existing Session

Any attempt by the MFAPI client to log on to an existing session will result in the session being aborted.

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: 4.0 Schema_2ndLogon

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Session Monitoring

Active sessions are monitored at the application level by each party via Heartbeat and TestRequest messages. Indications of problems must result in the monitoring party aborting the session.

The maximum allowed message transmission time (MaxTx) between between the MFAPI Client and the Whisperer Feed Handler is fixed, currently set to one second.

Heartbeats

Once the MFAPI Client has successfully established a session with the Whisperer Feed Handler, Heartbeat messages are sent by both parties at the interval specified by the MFAPI client in it's Logon message.

A heartbeat is deemed to have been missed if it is not received within HeartBtInt + MaxTx seconds and results in the issuance of a TestRequest.

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: 4.0 Schema_Heartbeat_3

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Test Request

TestRequest messages may be issued by either party and should result in a Heartbeat being sent in response, echoing the specified TestRequestID.

Under normal circumstances, TestRequest messages may therefore be used to obtain an approximate indication of message round-trip times between the MFAPI Client and the Whisperer Feed Handler.

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: 4.0 Schema_TestRequest

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Session Termination

If no Heartbeat response is received within HeartBtInt + MaxTx seconds of the issuance of the TestRequest, then the party should abort the session with a Logout message.

Logout

All Logout messages must be echoed. If no LogoutResponse is received within HeartBtInt + MaxTx seconds of the issuance of the Logout, then the session and associated TCP socket connection should be dropped.

Venue Login

Session startup behaviour is standardised across Taker, Maker and CLOB Venue types as follows:

• MFAPI Client first establishes connection to Whisperer with Logon & LogonResponse, then connects to Venue with UserRequest (UserRequestType=LogOnUser) & UserNotification (UserStatus=LoggedOn)
• All MFAPI Client pricing/trading requests sent before this will be rejected by Whisperer via ErrorReports.

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: 4.0 Schema_Heartbeat.03

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Venue Connection Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management

Client Session Management