This page sets out the key aspects of establishing and managing sessions between a Whisperer Enterprise Client and a Feed Handler.

Logon

A FIX session is only fully established when the following stages are complete:

• Establishing a connection (typically, but not always, involving the creation of a TCP socket connection).
• Authentication: Implemented via the exchange of FIX Logon messages.
• Synchronization: Identification of lost/untransmitted messages and retransmission as necessary by either or both sides,
• Verification: Exchange of TestRequest and Heartbeat messages to explicitly confirm correct session establishment.

Authentication & Authorization

When the Client requires a new session with a Venue, it must first establish a TCP socket connection with the  Whisperer Logon Service on a single, standard IP address and port - no matter the User, Session type, or Venue. Once connected, it must then send a Logon message specifying the desired session.

The Logon Service is responsible for the following functions:

• Authentication - validation of the provided Username and associated Password.
• Authorisation - verification that the User is permissioned for the specified SessionType and Venuename.

Should either of these checks fail,  the Logon Service will terminate the connection without a Logout message.

Otherwise the Logon Service will hand off the connection to the target Feed Handler. From this point on, the Client is communicating directly with the Feed Handler itself,  neither the LogonService, nor any other processes are involved.

Message Persistence

All Whisperer Enterprise messages are exchanged over TCP, with connectivity maintained directly between the Client and FH - so message delivery and ordering are both guaranteed, whilst the socket connection is operating correctly.

A message is deemed to have been sent, and received, successfully when:

• The send completes successfully, and
• The TCP session remains up for a period subsequent to the send.

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

It will be noted that that all  messages that represent stateful events are persisted and resent by the MF FH - but only these. It is the responsibility of the Client application to determine the appropriate response.

For sequence gaps identified on the outbound Client Session, it is entirely the responsibility of the Client application to determine which message types are to be persisted for possible resend. This is typically most important for Maker clients accepting or rejecting orders against Taker Venues, but other scenarios may need to be considered.

User Session Synchronisation

Whisperer Enterprise 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 - populating NextExpectedMsgSeqNum which contains the next msgSeqNum 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 msgSeqNum is lower than the FH's expected value, or 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 (using it's next sequence number).

  The Customer should contact MF Support to agree the correct resolution actions.

  
  

• Otherwise, the FH will issue a LogonResponse message - populating NextExpectedMsgSeqNum which contains the next msgSeqNum 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 (as used in the preceding Logon response), then the message gap is resolved by the FH with SequenceResetGapFill messages and/or the resending of persisted messages as necessary. The preceding LogonResponse will be gap-filled over.

  
  

  Should a Client specify a next-expected inbound sequence number too low (e.g. expecting '1' on re-logon just prior to weekly trading session close), then the FH will service most of the range to correct with a SequenceResetGapFill. For the more recent messages that are still persisted, these will be processed as normal. The FH will not resend a week's worth of persisted messages. Refer to Message Persistence above for more detail.

   Resent messages are characterised by: 

• • Msg.messageHeader.msgSeqNum populated with the original sequence number
  • Msg.messageHeader.sendingTime populated with the resend time
  • Msg.TradingFlags.PossDupFlag = TRUE
  • Msg.OrigSendingTime populated with Msg.messageHeader.sendingTime of original message

• After any inbound sequence number gaps have been resolved for the MFAPI Client, the Client then reciprocates in a similar manner, based on the the next msgSeqNum value that the Whisperer Feed Handler expects to receive from the Client - as specified in it's LogonResponse.
• The Whisperer Client signals it's completion of session synchronisation with a TestRequest.

• On receipt of this TestRequest, the Whisperer Feed Handler will respond with the necessary Heartbeat and then signal it's own completion of session synchronisation with a TestRequest in the opposite direction. 

  Any new (i.e. not SequenceResetGapFill or resent) messages sent by the MFAPI Client prior to the required Heartbeat response will result in ErrorReport messages.

  
  

Erroneous Scenarios

Second Logon to Existing Session

Any attempt by the Client to send a Logon message on an existing session that it established previously will result in the session being aborted.

Second Session for User/SessionType/Venue

Should the Client attempt to establish a second  (additional) session using the same credentials as of a currently-active Client session, then it will be rejected. The original session will be unaffected.

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.

MaxTx

For inbound Heartbeat and TestRequest messages sent by the Client , the FH will allow a fixed maximum allowed message transmission time (MaxTx), currently set to one second, before treating the message as 'missed'. This is used to allow for some degree of hysteresis WRT message delivery latencies.

The Client may specify it's own MaxTx value and logic when monitoring inbound messages sent by the FH.

In both cases only the local clock is used as reference.

Heartbeats

Once the Client has successfully established a session with the Whisperer Feed Handler (i.e. on dispatch of the first Heartbeat message in response to the end of synchronisation TestRequest), subsequent Heartbeat messages are sent by each party at the interval specified by the Client in it's Logon message.

Test Request

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

Logout

The recipient of a Logout message must echo it with a LogoutResponse (using it's next sequence number).

• It is the responsibility of the Logout initiator to terminate the socket connection on receipt of the LogoutResponse.
• If no LogoutResponse is received within HeartBtInt + MaxTx seconds of the issuance of the Logout, then the session and associated TCP socket connection must be dropped.

ErrorReport

The ErrorReport is a custom, user-defined, message used by the Whisperer Feed Handler to notify the Client when erroneous messages are received:

From Client

• At an invalid lifecycle phase (e.g. QuoteRequest sent before the connection to the Maker Venue is established, or after the Whisperer Feed Handler has disconnected from the Venue).
• Message is not supported by the Venue (e.g. sending a Quote to a Maker Venue).
• Message contains invalid data.

From Venue

• A FIX Reject or BusinessMessageReject message

Since there are scenarios where ErrorReport messages may not be delivered (e.g. during session abort sequences), these messages are persisted and will be delivered on reconnection.