This page sets out the key aspects of establishing and managing sessions between a Whisperer Direct Enterprise Client and a Feed Handler. In addition details are provided setting out how to initiate or terminate connectivity to the target Venue.

Overview

Terminology

• Customer - The organisation utilizing MarketFactory's systems.
• Client - The software component(s) maintained by the Customer that are used to communicate with Venues via Whisperer
• User - A logical entity defined by the Customer and configured by MarketFactory, used to associate a Client Session with a Venue Connection.
• Venue - External trading system - may be a Maker (e.g. a Bank), a Taker (e.g. an ECN), or a CLOB.
• Logon Service - Whisperer's security and session administration component.
• Gateway - The Whisperer component responsible for maintaining connectivity with a Venue.
• Venue Connection - A connection established between the Gateway and the Venue. Typically this will be a single FIX session (i.e. a specific Target/SenderCompID pair), but in some cases this may incorporate additional physical connections - for example, a Pricing session for a CLOB may comprise A/B UDP market data feeds in addition to a standard TCP FIX session used for message recovery.
• Client Session - A connection maintained between the Gateway and a Client User, dedicated to delivering messages between the User and the Venue for a specific Session Type.

Sessions

Session Types

Whisperer Direct Maintains Enterprise maintains the following session types:

• Pricing
  • Delivery of Market Data from a CLOB Venue.
  • ESP mass-quotes from a Maker MFSBE4 Client to a Taker Venue.
  • ESP mass-quotes from a Maker Venue to a Taker Client.
• Orders
  • Submission and execution of MFSBE4 Client orders against a CLOB Venue.
  • Orders against ESP liquidity (published on a separate Pricing session) from a Taker Venue to a Maker Client.
  • Orders against ESP liquidity (published on a separate Pricing session) from a Taker Client to a Maker Venue.
• RFS
  • Full RFS/RFQ quotation negotiation life cycle between Maker Client and Taker Venue.
  • Full RFS/RFQ quotation negotiation life cycle between Taker Client and Maker Venue.
• DropCopy
  • Delivery of post-Trade Straight-Through Processing (STP) trade notifications. Typically this will be restricted to notifications from dedicated Venue API connections only.

For a given Client and given Whisperer Feed Handler Gateway deployment within MarketFactory, each session type will be assigned unique Venue connection credentials (typically TargetCompID and SenderCompID).target IP:Port details and associated Target/SenderCompIDs, but potentially additional details such as Username and Password, PKI certs, etc).

Session Architecture

24x5.5 Availability

All session types are maintained directly with an individual Whisperer Feed Handler. All Feed Handlers Gateway. All Gateways are available 24 x 5.5 - the full trading week commencing on Sunday prior to Asia-open and ending on Friday, NY-close, 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:

...

Users

Whisperer Direct requires the configuration of at least one 'User' to be used for a given Session. In general a single User should be associated with a single Venue/Session, although there is some flexibility as set out below. 

...

The Client may organise subscriptions across Users as it deems fit.

The Client may organise subscriptions across Users as it deems fit.

...

A single User must be defined.

This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue ESP QuoteRequest to specific individual Users.

...

A single User must be defined.

This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue ESP Order to specific individual Users.

...

The Whisperer Client may distribute RFQ and/or RFS across Users as it deems fit.

...

A single User must be defined.

This avoids the need for configuration and logic to be maintained within MarketFactory to route each Venue RFS/RFQ QuoteRequest to specific individual Users.

...

This is a single feed per Venue, delivering trade notifications from the Venue to to the Customer.

A single User is defined.

This avoids the need for configuration and logic to be maintained within MarketFactory to route trade notifications from the Venue to specific individual users.

Additional Material

Further detail is provided in the following page(s):

Client Session Management

Message Persistence

All Whisperer Direct messages are exchanged over TCP, with connectivity maintained directly between the Client and FH.

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:

...

Logon

Session Synchronisation

Whisperer Direct 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.

...

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/or 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.

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.

Should a second Client attempt to establish an 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

All messages received by the Whisperer Feed Handler (from either the Client or the Venue) between the exchange of Logout and LogoutResponse messages will result in ErrorReport messages being sent to the Client.

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.

Venue Session Management

Venue Logon

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

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

Venue Logoff

Venue logoff may be initiated as a result of any of the following:

• A request from the Client via UserRequest (UserRequestType=LogOffUser).
• The Venue initiates a Logout (e.g. End of Day).
• Whisperer detects a dropped connection

In all scenarios, the Client is notified of the event via UserNotification (UserStatus=LoggedOff).

...

...