Page History
This page sets out the key aspects of establishing and managing sessions between a Whisperer Direct Client and a 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.
| Table of Contents |
|---|
Overview
Sessions
Session Types
Whisperer Direct SBE4 Maintains the following session types:
- Pricing
- Delivery of Market Data from a CLOB Venue
- ESP mass-quotes from a Maker MFSBE4 Client client to a Taker Venue.
- ESP mass-quotes from a Maker Venue to a Taker ClientTaker MFSBE4 client.
- Orders
- Submission and execution of MFSBE4 Client client orders against a CLOB Venue.
- Orders against ESP liquidity (published on a separate Pricing session) from a Taker Venue to a Maker ClientMFSBE4 client.
- Orders against ESP liquidity (published on a separate Pricing session) from a Taker Client MFSBE4 client to a Maker Venue.
- RFS
- Full RFS/RFQ quotation negotiation life cycle between Maker Client MFSBE4 client and Taker Venue.
- Full RFS/RFQ quotation negotiation life cycle between Taker Client and Taker MFSBE4 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 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 . All Feed Handlers are available 24 x 5.5 - the full trading week 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,
| Note | ||
|---|---|---|
| ||
This field should never be reset intra-week, for any session type. |
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).sendingTime - nanosecond-precision timestamp indicating when the message left the sender.
- msgSeqNum - this is the standard integer message sequence number. When first establishing a connection at At the start of a trading week, session it should be set to '1', and incremented with every subsequent message sent for the remainder lifetime of the trading week.
...
| title | msgSeqNum |
|---|
- Whisperer SBE4 session.
- sendingTime - nanosecond-precision timestamp indicating when the message left the sender
This field should never be reset intra-week, for any session type.
...
- .
Users
Whisperer Direct 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.
| Note |
|---|
| Venues may reject multiple identical requests, so care should be taken to ensure that there is a clear demarcation of responsibility across Users. |
| Note |
|---|
Only the last user to logout from a venue will cause Whisperer to logout from the Venue. It follows then that when multiple users are configured, when logging off prior users, |
...
it is the responsibility of the |
...
MFSBE4 client to ensure that the user session is cleaned up correctly prior to logout. |
The Client may organise subscriptions across Users as it deems fit.
| Note |
|---|
| Venues may reject multiple identical requests, so care should be taken to ensure that there is a clear demarcation of responsibility across Users. |
| Note |
|---|
Only the last user to logout from a venue will cause Whisperer to logout from the Venue. It follows then that when multiple users are configured, when logging off prior users, it is the responsibility of the Whisperer Client to ensure that the user session is cleaned up correctly prior to logout. |
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
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.
| Info | ||
|---|---|---|
| ||
The MF FH guarantees persistence of sent outbound messages for possible resend for a minimum period of three heartbeat intervals, allowing for detection of dead connections as per Whisperer Direct - Session Management, below. |
| Info | ||
|---|---|---|
| ||
Any unsent messages will be persisted indefinitely until either:
|
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.
| Note |
|---|
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. |
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.
| Warning |
|---|
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 with new messages after it has received the Heartbeat sent in response to it's own TestRequest. |
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Message Persistence
The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:
| Message | Sent By | Received By | Persisted |
|---|---|---|---|
| Logon | Client (Both) | Feed Handler | No |
| LogonResponse | Feed Handler | Client (Both) | No |
| Logout | Client (Both) | Feed Handler | No |
| LogoutResponse | Feed Handler | Client (Both) | No |
| SequenceResetGapFill | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| Heartbeat | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| TestRequest | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| SecurityStatus | Feed Handler | Client (TAKER) | No |
| UserRequest | Client (Both) | Feed Handler | No |
| UserNotification | Feed Handler | Client (Both) | No |
| ErrorReport | Feed Handler | Client (Both) | Yes |
| MarketDataRequest | Client (Both) | Feed Handler | No |
| MarketDataRequestReject | Feed Handler | Client (Both) | No |
| MarketDataIncrementalRefresh | Feed Handler | Client (Both) | No |
| QuoteRequest | Client (TAKER) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes | |
| QuoteRequestReject | Client (MAKER) | Feed Handler | Optional |
| Feed Handler | Client (TAKER) | Yes | |
| Quote | Client (MAKER) | Feed Handler | No |
| Feed Handler | Client (TAKER) | No | |
| MassQuote | Client (MAKER) | Feed Handler | No |
| Feed Handler | Client (TAKER) | No | |
| QuoteResponse | Client (MAKER) | Feed Handler | Optional |
| Feed Handler | Client (TAKER) | Yes | |
| Client (TAKER) | Feed Handler | Optional | |
| Feed Handler | Client (MAKER) | Yes | |
| NewOrderMultileg | Client (Both) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes | |
| OrderCancelReplaceRequest | Client (Both) | Feed Handler | Optional |
| OrderCancelRequest | Client (Both) | Feed Handler | Optional |
| OrderCancelReject | Feed Handler | Client (Both) | Yes |
| OrderTimeout | Feed Handler | Client (Both) | Yes |
| ExecutionReport | Client (MAKER) | Feed Handler | Yes |
| Feed Handler | Client (TAKER) | Yes | |
| ExecutionAck | Client (TAKER) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes |
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.
| Tip |
|---|
| The Customer should contact MF Support to agree the correct resolution actions. |
...
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.
| Warning |
|---|
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 Whisperer Direct - Session Management above more more detail. |
to Existing Session
Any attempt by the MFAPI client to log on to an existing session
The Whisperer Feed Handler signals it's completion of session synchronisation with a TestRequest.
| Note |
|---|
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. |
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.
| Warning |
|---|
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 with new messages after it has received the Heartbeat sent in response to it's own TestRequest. |
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
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.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
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 The maximum allowed message transmission time (MaxTx) between between the MFAPI Client and the Whisperer Feed Handler is fixed, 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 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 Client MFAPI client in it's Logon message.
| Note |
|---|
| Unlike standard FIX sessions, MFSBE4 Heartbeat messages must be published as a metronome - no allowance should be made based on whether or not other messages are sent within each interval. |
...
| Warning | ||
|---|---|---|
| A heartbeat is deemed to have been missed if it is not received within HeartBtInt + MaxTx seconds and must result in the monitoring party issuing a TestRequest. | ||
| Info | ||
| ||
MF plans to utilise the Heartbeat message to periodically publish additional metrics to and from the server/Client : This functionality will be made available via a backwardly-compatible schema change. |
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
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.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Logout
| Warning |
|---|
All Logout messages must be echoed with a 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. |
All messages received by the Whisperer Feed Handler (from either the Client MFSBE4 client or the Venue) between the exchange of Logout and LogoutResponse messages will result in ErrorReport messages being sent to the Clientclient.
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
| Note |
|---|
Whisperer is solely responsible for the management and correct handling of Venue-side Session Synchronisation, including the necessary logic relating to End of Day Resets etc. |
Venue Logon
Session startup behaviour is standardised across Taker, Maker and CLOB Venue types as follows:
- The Client MFSBE4 Client first establishes connection to Whisperer with Logon & LogonResponse, then establishes connection to the Venue with UserRequest (UserRequestType=LogOnUser) & UserNotification (UserStatus=LoggedOn).
- Any Client 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:
- A request from the Client MFSBE4 client via UserRequest (UserRequestType=LogOffUser).
- The Venue initiates a Logout (e.g. End of Day).
- Whisperer detects a dropped connection
In all scenarios, the MFSBE4 Client is notified of the event via UserNotification (UserStatus=LoggedOff).
...
| Note | ||
|---|---|---|
| ||
Illustrate multiple logon attempts to venue - 5 attempts, one minute interval, then logout to Clientclient. Eg Consider Reuters MAPI. |
...
Overview
Content Tools