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.
| SessionType | Venue is CLOB | Client is Taker | Client is Maker |
|---|---|---|---|
| Pricing | A single User must be defined and used for all MarketData subscriptions. This ensures consistent latency and throughput characteristics. | A single User must be defined and used for all ESP subscriptions. This ensures consistent latency and throughput characteristics. | 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. |
| Orders | The Whisperer Client may distribute Orders across Users as it deems fit. | The Whisperer Client may distribute Orders 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 Order to specific individual Users. |
| RFS | - | The Whisperer Client may distribute RFQ and/or RFS 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 RFS/RFQ QuoteRequest 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. This avoids the need for configuration and logic to be maintained within MarketFactory to route trade notifications from the Venue to specific individual users. | ||
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.
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.
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.
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.
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.
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 Whisper until their next venue session is established.
Orders may be automatically cancelled in the event of session outages.
A session disconnect may occur in the following contexts:
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.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.| TimeInForce | Description | Cancel On Disconnect |
|---|---|---|
| DAY | Short-lived Orders (single trading day) | YES |
| GTC | Long-lived Orders (multiple trading days) | NO |
| IOC | Immediate Orders | NO |
| FOK | Immediate Orders | NO |
| GTD | Short-lived Orders (typically single trading day) | YES |
| GFT | Short-lived Orders (typically single trading day) | YES |
| GFA | Auction-period Orders (Fixing) | NO |
| AMO | Auction-period Orders (Market Open) | NO |
| AMC | Auction-period Orders (Market Close) | NO |