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. | ||
Illustrate Multiplexing - multiple users connecting to Venue. First user triggers logon, last user triggers logout. A single user connection failure triggers logout, which in turn triggers graceful logout of all other users. Associated order cancellation message may be generated by venue. Whilst most users will receive these during their logout cycle, the failed user will receive these on next session synchronisation. |
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.