Page History
The MarketFactory-provided software which MarketFactory customers link into their local application in order to connect to the MarketFactory Whisperer APIServer.
The MarketFactory API (MFAPI) Client consists of little more than a message encoding and decoding layer that presents the contents of messages to callback functions.
MarketFactory has specifically limited the work performed within the MFAPI in order to minimize Client-side latency and maximize stability.
Handler
The Customer-written software which performs different actions on reception of messages of various types from the APIServer. This inherits from the MFHandler class.
Message
A MFAPI message is an application-level protocol data unit which is received by an MFClient object, and is passed to the appropriate function in a user-supplied class derived from MFHandler, based on its type.
Market
The MarketFactory name for a given instrument, for example EUR/USD for spot FX, or 6EH6 for CME Eurodollar futures expiring in March 2016.
Whisperer
The generic name for the MarketFactory server software. A Whisperer installation consists of an APIServer (which faces the customer), and one or more FeedServer components (which face the exchanges), as well as auxiliary data-logging components which are used internally and do not interact directly with the outside world.
The API Server
The API Server
The following documents/artefacts are intended to act as a draft/proposed replacement for the material currently found in the Lab:
Whisperer
The Whisperer platform is composed of a series of individual processes that combine together to form a unified platform, composed of the below constituent parts:
The API Server
The MarketFactory API (MFAPI) Server is the heart of the Whisperer platform and acts as the interface to which the customer infrastructure connects. The API Server It creates the customer sessions to the Whisperer platform and permits the customer infrastructure (and the associated users) to gain access to the Trading Venue Feeds/ connections configured for the instance. As the only interface for the customer infrastructure (using the classic implementation), the API server API Server is also the site of the session handling elements processes associated with customer connections to Whisperer prior to feed/venue connection subscription.
DB Logger
The DBLogger DB Logger applies the user authentication requirements for Whisperer, through use of a Lightweight Directory Access Protocol (LDAP)database. Ensuring that only users established within the designated customer infrastructure, listed individuals, known devices etc.. are the only users granted access to the platform and associated connections. failure to authenticate with the DBLogger the DB Logger will result in the customer infrastructure or user(s) being rejected. These user entries can be made directly to the LDAP database or explicitly to a static configuration.
DC Server
The Drop Copy Server (or DC Server) generates a stream of MFAPI TradeCapture Messages. MarketFactory can then allowan MFAPIClient thenallowanMFAPIClient to subscribe to these messages, similar to a traditional FIX drop copy using the MarketFactory protocol instead. This is an additional feature that can be enabled for customers, the benefits of which are described in more details below (under additional services).
FeedServersFeed Handlers
Every Trading Venue that MarketFactory's Whisperer is able to integrate with has a FeedServer (a term used synonymously with Feed Handler) which makes the integration possible. The Feed Servers connect directly with the API server under via the Classic MFAPI classic model of operation.
Customer infrastructure can connect directly to the Feed Server (for market data only) using the MarketFactory's new SBE implementation. The benefit of direct connection with the Feed Server being that messages do not have to pass through the single bottleneck of SBE3 implementation, avoiding the risk of bottlenecks in the API server (which traditionally has been the only interface available to the customer infrastructure). The more direct This approach is not only aimed at reducing latency at times of high message frequency but also improves high availability by reducing dependency on access to the API server in order to obtain market data from Trading venuesVenues.
The Feed Servers also exist as a source of normalisation, by integrating venue messages, tags and fields to align with the MarketFactory message protocol resulting in a Feedserver that aims to be as closely compatible to the venue as possible, whilst maintaining a normalised library of messages to smooth out the differences between differing trading venues and their protocols.
Additional Services
The Whisperer platform is also supplemented with additional features provided by MarketFactory, that enhance the benefits available to customers outside of connectivity alone. These optional modules are explained below:
. Refer to Additional Services for further detail.
Venue
An organisation which provides trading facilities, such as a bank or ECN. A Venue may provide the same services via multiple Feeds (for example via different protocols).
Feed
The term for a connection to a Venue, which (normally) consists of two login sessions to the venue, one for market data, and one for order entry.
A MarketFactory Customer may have more than one Feed to a given Venue, depending on the relationship the Customer has with the Venue.
Feeds are referred to by numeric and string identifiers. These identifiers are globally consistent across all Whisperer installations.
Additional Material
Further detail is provided in the following page(s):
| Children Display |
|---|
Configuring Whisperer
Whisperer Users
Description
Historically usernames such as "ProdUser1" have sometimes been used in Whisperer configurations. These are limiting for several reasons, not least of which is the fact that they are not globally unique across different Whisperer instances.
Usernames should follow the format mnemonic-environment-purpose-instance, where mnemonic is the three/four-letter identifier for the customer, the environment is one of duat, or prod, the purpose is one of trading, dropcopy, admin, api, and the instance is a three-digit identifier. While this format is not the shortest, it aims to strike a balance between brevity and clarity.
User types
Whisperer system users have different roles, so a component of the username should indicate this. Here are some examples:
example username
purpose name
description
bwp-prod-trading-001tradingregular trading users, used for market data and order entry
bwp-prod-data-001dataused for market data only, does not have trading rights
bwp-prod-dropcopy-001dropcopydropcopy subscriptions, does not have trading rights
bwp-prod-admin-001adminadministrative users, for NOP setting
bwp-prod-mm-001mmmarket-making trading
bwp-prod-api-001apiregular usage via the API
Feeds Filters
MarketFactory allows Customers to request the creation of Whisperer API users as described under the 'Whisperer Users' heading. Further, these users can be restricted or enabled in their abilities to access different connections for the trading venues through the use of feeds filters. In terms of definitions, the term trading venue connection is synonymous to Feed. The Feed filter exists as a statically defined enumeration within the Whisperer configuration and can allow for the following configuration examples:
- Users can be grouped together within a filter and provided with access to a collection of shared connections.
- A filter can be created to permit a user access to only feeds/connections with Banks, ECN's or a combination of these liquidity providers or any other distinguishing feature a customer wishes to divide or group feeds/connections with.
- Feeds filters can also enable the monitoring of prescribed users, a feature that is explored further in the user heading within this section.
TBD Example.
Eg Flow asked:
Use multiple logins > same MF gateway IP + Port using the same venueID.
We need this model for our market data where we split out BBO and Depth and but our reference data file we build internally we need both feeds to use the same venueID.
Overview
Content Tools