...
The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:.
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.
For sequence gaps identified on the outbound Client Session, it is entirely the responsibility of the Client application to determine which message types are to be persisted for possible resend. This is typically most important for Maker clients accepting or rejecting orders against Taker Venues, but other scenarios may need to be considered.
| Table Filter |
|---|
| inverse | false,false |
|---|
| default | , |
|---|
| cell-width | 150,150 |
|---|
| userfilter | Sent By,Persisted |
|---|
| datepattern | yy-mm-dd |
|---|
| id | 1571392653103_486306577 |
|---|
| labels | Sent By‚Persisted |
|---|
| order | 0,1 |
|---|
|
| 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 (TAKER) | 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 | | QuoteCancel | 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 (TAKER) | Feed Handler | Optional | | Feed Handler | Client (MAKER) | Yes | | OrderCancelReplaceRequest | Client (TAKER) | Feed Handler | Optional | | OrderCancelRequest | Client (TAKER) | Feed Handler | Optional | | OrderCancelReject | Feed Handler | Client (TAKER) | 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.
...
User Session Synchronisation
...