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. 

Session Handling

Logon

Each individual client User maintains an individual session with the Gateway, and each one must establish a connection to the Venue via a UserRequest as described in Venue Connection Management.

The first user to do this will trigger Whisperer to establish the venue-side session and resolve any session synchronisation issues that arise.

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. 

Gateway 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 Gateway Sequence Number Gaps

The first Client User to reconnect will trigger FIX message resends from the Gateway 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.

Logout

Similarly, when Client Users request a disconnection from the Venue via UserRequest (UserRequestType=LogOffUser), it is only the request of the last User that will actually trigger Whisperer to logout from the venue-side session. Any messages received from other client users will be persisted by Whisperer until their next  venue session is established.

Pricing Sessions

Background

Whilst Whisperer Enterprise trading sessions have always been shareable across multiple users, pricing sessions have to date been constrained such that only a single client user was allowed to connect. This was because the support of multiple users sharing a single subscription incurs latency and other costs:

• Additional Whisperer logic to maintain book state and support late-joins.
• The same data must be sent to the client many times by Whisperer. Given the nature of TCP, this means that price publication latencies will be different for each user (the traditional TCP round-robin saw-tooth profile), and also introduces network congestion/utilisation issues.

The existing architecture avoids these problems by delegating responsibility for client-side distribution of the market data to the client, using the client's specific technology choices (message bus, hardware/network architecture, etc.).

This approach works well for those clients that have a homogeneous connectivity architecture, internally.

For those clients that don't, Whisperer now offers Price Subscription Multiplexing ("Price MUX") for MarketData and TakerESP subscriptions, where subscriptions are shared by the use of a common MDReqID, or QuoteReqID for a given instrument. The first users' MarketDataRequest or QuoteRequest for a given instrument will set these parameters, and any subsequent users' subscription for the same instrument must match.

In the event of any validation errors for subsequent users, Whisperer will respond with a BusinessMessageReject.

Other than this, each user maintains their own independent session with a given venue gateway, no knowledge of other users' session status is required.

MarketData

Venue Session Establishment

Once a user has connected to the gateway and established a session with the venue via the standard UserRequest(LogOnUser) message, SecurityStatus messages will typically be published defining the status of available instruments.

These messages are identical to those received in a non-MUX context, with the addition of a new BodyPassthruKey/Value pair, "MFSecurityID". It should be noted that these IDs are not shared across venues and will change as venues make adjustments to their supported instruments.

MUX users must use this ID as the MDReqID in any subsequent MarketDataRequest messages.

Subscription Management

Subscription

MarketData sessions rely on MUX users using a common MDReqID to subscribe to shared subscriptions. Two ID-to-instrument mapping models are supported:

• Client-managed: Clients define and use whatever ID/instrument mapping they prefer. The first subscription defines the instrument details that subsequent requests must match.
• Whisperer-default: MUX users must use the provided MFSecurityID for their target instrument. In addition, all other instrument details in the MarketDataRequest must match those published in the SecurityStatus message.

Unsubscription

A venue-side subscription will be terminated when the last subscribed user either unsubscribes or suffers a disconnection.

Book Management

From the perspective of the user, subscription behaviour is always consistent: subscribe and receive an initial snapshot, followed by updates. Observed latencies will differ, depending on the subscription-sharing model chosen:

1. Single user, no MUX. No additional processing, lowest latency.
2. Multiple users, MUX of identical subscriptions.
3. Multiple users, MUX of different-depth subscriptions.

Multiple users, MUX of identical subscriptions

The first user will observe minimal delay vs option 1, but others will observe additional latency due to the sequenced delivery of the update to each subscribed user (the classic TCP round-robin saw-tooth distribution).

After the subscription is established, subsequent late-joining users will receive an initial snapshot to synchronise book state (MarketDataIncrementalRefresh.MDFlags.IsSnapshot = TRUE).

Thereafter, each incremental message will be sent to all subscribers, in turn. Whilst the message header will reflect the specific user session (SendingTime, MsgSeqNum, etc), every user receives the identical message body content.

Multiple users, MUX of different-depth subscriptions

Each subscribed book depth is a different view on the full venue book.

If necessary, users may subscribe to a shared Instrument with different MarketDepths, although it should be noted that this means that Whisperer must additionally maintain separate views on the book for each unique depth. Since late-joiners may subscribe to deeper book depths than the initial subscription, it also means that Whisperer must always make full-book subscriptions to the venue.

If the first user's subscription is full-book, then it will observe minimal delay vs option 1, but other user/MarketDepth subscriptions will observe additional latency vs option 2, due to the two-tier iteration of view management and per-view user distribution.

Each incremental received from the venue will be processed against every unique subscribed MarketDepth view, with a different message body being generated for each, containing additional explicit synthetic new and delete MDEntries as needed. A given venue MDEntry may result in any of the following:

It follows that a given venue MarketData message may not result in any message being sent to the subscribed user(s) at all.

Each view will be distributed in turn, with the message for the view also being sent to each subscribed user in turn.

TakerESP

TakerESP instrument permissions are managed bilaterally between Venue and Client and may vary significantly through time.

Subscription Management

In this context Whisperer is unable to provide an equivalent to the MFSecurityID provided for MUX MarketData, so in order to share subscriptions, a client-managed ID-to-instrument model must be adopted, with all users aligned on the following subscription qualities:

• QuoteReqID
• Instrument - Symbol (currency pair), SecurityType (Spot/Fwd/NDF), LegSettlType/Date (Tenor)
• Side (probably 2-Way)
• Sweepable vs FullAmount liquidity style
• Rung count and size (usually implicit, sometimes explicit via QuoteRequest.NoUnderlyings)

Trading

Whisperer ensures that ExecutionReport messages for a given ClOrdID are always routed to the User that submitted the originating NewOrderMultileg.

Cancel On Disconnect

Orders may be automatically cancelled in the event of session outages.

Context

A session disconnect may occur in the following contexts:

• Between Whisperer and Venue - When the Venue session is lost, Whisperer will notify all Client Users via UserNotification (UserStatus=LoggedOff) as per VenueLogoff details. The Venue will apply any Cancel-on-Disconnect rules applicable for their venue, and cancellations will be delivered along with any other In-flight ExecutionReports, as part of the synchronisation of the re-established session.
• Between Client and Whisperer - When a session with an individual Client User is lost, Whisperer will automatically send OrderCancelRequest message for all in-scope active orders, as per the table below.  NOTE: If the last Client User is disconnected unexpectedly, currently Whisperer will drop the socket connection to the Venue so as to trigger Venue Cancel-on-Disconnect.

Scope