...

Overview

Sessions

Session Types

Whisperer 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 deployment within MarketFactory, each session type will be assigned unique Venue connection credentials (typically TargetCompID and SenderCompID).

24x5.5 Availability

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 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:

• 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 the start of a trading week, it should be set to '1', and incremented with every subsequent message sent for the remainder of the trading week.

Users

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

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.
• Feed Handler - The Whisperer component responsible for maintaining connectivity with a Venue.
• Venue Connection - A connection established between the Feed Handler and the Venue and Whisperer. 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 Feed Handler and a Client User, dedicated to delivering messages between the User and the Venue for a specific Session Type.

Sessions

Session Types

Whisperer 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 deployment, each session type will be assigned unique Venue connection credentials (typically 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 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:

• 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 the start of a trading week, it should be set to '1', and incremented with every subsequent message sent for the remainder of the trading week.

Client Session Management

Logon

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

...

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.

Client Session Management

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 table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:

Logon

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[789] which contains the next msgSeqNum value that the Client expects to receive from the Whisperer Feed Handler. 

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 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 number higher than  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).

  Tip
  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 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.

  
  

  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 Enterprise - Session Management above for more detail.

   Resent messages are characterised by: 

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

• The FH will then issue a LogonResponse message - populating NextExpectedMsgSeqNum[789] which contains the next msgSeqNum value that it expects to receive from the Client.

• •  message

• The Whisperer Feed Handler signals it'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 , the Client then reciprocates in a similar manner, based on the the the the next msgSeqNum value msgSeqNum value that the Whisperer the Whisperer Feed Handler expects to receive from the Client - as specified in it's LogonResponse. The The Whisperer Client signals it's completion of session synchronisation with a TestRequest.

...

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 previously will result in the session being aborted.

Second Session for User/SessionType/Venue

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

...

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

...

Connection Management

...

• The Client first establishes connection to Whisperer the Feed Handler with Logon & LogonResponse, then establishes
• The Client then instructs the Feed Handler to establish a connection to the Venue with via a 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
• Whisperer shutdown

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

...

...

• message.
• The Feed Handler will attempt to establish connectivity to the Venue
• Once connectivity is established, FIX Session-level messages are exchanged as necessary to  address any synchronisation issues.
• The Feed Handler then notifies the client of a successful connection via a  UserNotification (UserStatus=LoggedOn) message.
• Any Client pricing/trading requests sent before this will be rejected by Whisperer via ErrorReport messages.

FIX Session Reset

For those Venues which reset FIX sessions on a weekly basis, no special action is required, as this matches the Feed Handler schedule described above.

For persisted (non-Pricing) session types where Venues reset FIX sessions on a daily basis, the Feed Handler will apply the necessary reset logic for the first successful FIX Session Logon only, at Start of Day. 

For non-persisted Pricing sessions, the Feed Handler will typically reset the session on every FIX Session Logon.

FIX Session Establishment

Once instructed to do so by the Client User, the Feed Handler will attempt to logon to the Venue. Should a connection not be established immediately, it will periodically retry as follows:

• On a failed logon attempt the Feed Handler will wait RetryInterval seconds (> 0), and repeat.
• Once MaxAttempts (> 0) failed logons occur in a row, the Feed Handler will
• wait BackoffInterval seconds (>= 0) and restart the cycle.

This behaviour applies across all Feed Handlers, irrespective of line protocol, Maker/Taker perspective, or trading model.

MarketFactory will apply appropriate values to each of these three properties, based on individual Venue requirements. No Customer involvement is required.

Venue Connection - FIX Session Synchronisation

In order to ensure that Venue-side session synchronisation issues are avoided, Whisperer implements the following policy:

Feed Handler Detection of Venue Sequence Number Gaps

If a sequence number gap is detected on receipt of the Venue's logon response, then a ResendRequest will be issued.

Whilst a sequence gap exists, no other Venue messages will be processed until the sequence gap is resolved - via SequenceResetGapFill(s) and message resends, as the Venue deems necessary.

Once the sequence gap is resolved, Whisperer will formally Logout from the Venue and then re-Logon. Standard Logon processing will thus only progress when complete, clean session synchronisation is guaranteed.

As a final verification, the Feed Handler will issue a TestRequest against the Venue; receipt of the Heartbeat response triggers Whisperer to notify the Client of successful session establishment via the UserNotification(UserStatus=LoggedOn).

The Client User must therefore be capable of receiving and processing resent Venue messages relating to it's previous session (marked as PossResend) in the interval between the UserRequest and the UserNotification.

Venue Detection of Feed Handler Sequence Number Gaps

If the sequence number associated with Venue Logon message issued by the Feed Handler indicates a gap, the Venue will typically respond with a Logon response, followed by a ResendRequest.

Whisperer will respond to this via SequenceResetGapFill(s) and/or message resends, as mandated by the Venue. Immediately after resolution of the sequence gap, Whisperer will formally Logout from the Venue and then re-Logon.

Client Session Synchronisation

Any Client User messages that were delivered to the Feed Handler during Client Session synchronisation will be assigned message sequence numbers that follow sequentially from the end of the previous session. delivered to the Venue  immediately on successful completion of the standard FIX Session Synchronisation.

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
• Whisperer shutdown

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

Session Sharing (User Multiplexing)

Multiplexing Guidelines

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

Logon

FIX Session Synchronisation with Multiplexed Users

In the event of a Venue FIX  Session failure, session synchronisation will be triggered when the first Client User reconnects. Specific implications relating to this are discussed below. 

Feed Handler Detection of Venue Sequence Number Gaps

In this case any resent messages will only be forwarded to the Client when the correct Client User finally reconnects. This implies that state should be persisted across Venue Connections.

Venue Detection of Feed Handler Sequence Number Gaps

The first Client User to reconnect will trigger FIX message resends from the Feed Handler to the Venue for all affected Client User Sessions. Any messages sent by the Venue in response will only be forwarded to the Client when the correct Client User finally reconnects. 

Client Session Synchronisation

Any Client User messages delivered during Client Session synchronisation will only be forwarded when that User finally reconnects to the Venue. This may be some considerable period after the FIX session has been established, from the Venues perspective. This scenario is thus subject to the same caveats as outlined above.