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

Overview

Sessions

Session Types

Whisperer SBE4 Maintains the following session types:

...

For a given Client and given Whisperer Feed Handler deployment within MarketFactory, each session type will be assigned unique Venue connection credentials (typically TargetCompID and SenderCompID).

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 for the lifetime of the Whisperer SBE4 session.
• sendingTime - nanosecond-precision timestamp indicating when the message left the sender.

Users

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

Pricing

Venue as CLOB/Maker

The MFSBE4 client may organise subscriptions across Users as it deems fit.

...

Venue as Taker

A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue QuoteRequest to specific individual Users.

Orders

Venue as CLOB/Maker

The MFSBE4 client may distribute Orders across Users as it deems fit.

Venue as Taker

A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue NewOrderMultileg to specific individual Users.

RFS

Venue as Maker

The MFSBE4 client may distribute RFQ and/or RFS across Users as it deems fit.

Venue as Taker

A single User must be defined, to avoid the need for configuration and logic to be maintained within MarketFactory to route each Venue RFS/RFQ to specific individual Users.

DropCopy

This is a single feed per Venue, delivering trade notifications from the Venue to to the Customer. A single User is defined, avoiding the need for configuration and logic to be maintained within MarketFactory to route trade notifications from the Venue to specific individual users.

Client Session Management

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.

...

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.

...

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 (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 MFAPI 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 MFSBE4 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 MFSBE4 Client when erroneous messages are received:

...

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 MFSBE4 Client first establishes connection to Whisperer with Logon & LogonResponse, then establishes connection to the Venue with UserRequest (UserRequestType=LogOnUser) & UserNotification (UserStatus=LoggedOn).
• Any MFSBE4 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:

...