Page History
...
The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:
| Message | Sent By | Received By | Persisted |
|---|---|---|---|
| Logon | Client (Both) | Feed Handler | No |
| LogonResponse | Feed Handler | Client (Both) | No |
| Logout | Client (Both) | Feed Handler | No |
| LogoutResponse | Feed Handler | Client (Both) | No |
| SequenceResetGapFill | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| Heartbeat | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| TestRequest | Client (Both) | Feed Handler | No |
| Feed Handler | Client (Both) | No | |
| SecurityStatus | Feed Handler | Client (TAKER) | No |
| UserRequest | Client (Both) | Feed Handler | No |
| UserNotification | Feed Handler | Client (Both) | No |
| ErrorReport | Feed Handler | Client (Both) | Yes |
| MarketDataRequest | Client (Both) | Feed Handler | No |
| MarketDataRequestReject | Feed Handler | Client (Both) | No |
| MarketDataIncrementalRefresh | Feed Handler | Client (Both) | No |
| QuoteRequest | Client (TAKER) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes | |
| Quote | Client (MAKER) | Feed Handler | No |
| Feed Handler | Client (TAKER) | No | |
| MassQuote | Client (MAKER) | Feed Handler | No |
| Feed Handler | Client (TAKER) | No | |
| QuoteResponse | Client (MAKER) | Feed Handler | Optional |
| Feed Handler | Client (TAKER) | Yes | |
| Client (TAKER) | Feed Handler | Optional | |
| Feed Handler | Client (MAKER) | Yes | |
| NewOrderMultileg | Client (Both) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes | |
| OrderCancelReplaceRequest | Client (Both) | Feed Handler | Optional |
| OrderCancelRequest | Client (Both) | Feed Handler | Optional |
| OrderCancelReject | Feed Handler | Client (Both) | Yes |
| OrderTimeout | Feed Handler | Client (Both) | Yes |
| ExecutionReport | Client (MAKER) | Feed Handler | Yes |
| Feed Handler | Client (TAKER) | Yes | |
| ExecutionAck | Client (TAKER) | Feed Handler | Optional |
| Feed Handler | Client (MAKER) | Yes |
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.
...
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.
| Venue Type | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| SessionType | CLOB | Maker | Taker | ||||||||
| Pricing | 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. | ||||||||
| 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 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. | ||||||||||
Logon
| Note | ||
|---|---|---|
| ||
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. |
...
Overview
Content Tools