Page History
This page sets out the key aspects of establishing and managing sessions between a Whisperer Direct Enterprise Client and a Feed Handler. In addition details are provided setting out how to initiate or terminate connectivity to the target Venue.
| Table of Contents |
|---|
Overview
Sessions
Session Types
Whisperer Direct Enterprise Maintains the following session types:
...
For a given Client and given Whisperer Feed Handler deployment within MarketFactory, each session type will be assigned unique Venue connection credentials (typically TargetCompID and SenderCompID).
24x5.5 Availability
All session types are maintained directly with an individual Whisperer Feed Handler. All Feed Handlers are available 24 x 5.5 - the full trading week commencing on Sunday prior to Asia-open and ending on Friday, NY-close, irrespective of the schedule of the Venue itself.
Message Header
In addition to the default SBE message header fields (blockLength, templateId, schemaId and version), the MFSBE4 header additionally defines the mandatory population of the following fields:
...
| Note | ||
|---|---|---|
| ||
This field should never be reset intra-week, for any session type. If the Client should disconnect from Whisperer during the trading week, they must continue the message sequence when re-establishing the session. |
Users
Whisperer Direct 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. | ||||||||||
Client Session Management
Message Persistence
All Whisperer Direct Enterprise messages are exchanged over TCP, with connectivity maintained directly between the Client and FH.
...
| Info | ||
|---|---|---|
| ||
The MF FH guarantees persistence of sent outbound messages for possible resend for a minimum period of three heartbeat intervals, allowing for detection of dead connections as per Whisperer Direct Enterprise - Session Management, below. |
...
| Info | ||
|---|---|---|
| ||
Any unsent messages will be persisted indefinitely until either:
|
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 |
Logon
Session Synchronisation
Whisperer Direct Enterprise utilises the 'new' model of session synchronisation introduced in FIX 4.4. This ensures that each side can expect any sequence number gaps to be filled automatically, eliminating the need for ResendRequest messages - and the problems that historically accompany these.
...
If the Client is expecting a sequence number lower than the FH's next-to-be-assigned msgSeqNum[34], then the message gap is resolved by the FH with SequenceResetGapFill messages and/or the resending of persisted messages as necessary.
Warning Should a Client specify a next-expected inbound sequence number too low (e.g. expecting '1' on re-logon just prior to weekly trading session close), then the FH will service most of the range to correct with a SequenceResetGapFill. For the more recent messages that are still persisted, these will be processed as normal.
The FH will not resend a week's worth of persisted messages. Refer to Whisperer Direct Enterprise - Session Management above more more detail.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Logon to Existing Session
Any attempt by the Client to send a Logon message on an existing session that it established previously will result in the session being aborted.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Session Monitoring
Active sessions are monitored at the application level by each party via Heartbeat and TestRequest messages. Indications of problems must result in the monitoring party aborting the session.
MaxTx
For inbound Heartbeat and TestRequest messages sent by the Client , the FH will allow a fixed maximum allowed message transmission time (MaxTx), currently set to one second, before treating the message as 'missed'. This is used to allow for some degree of hysteresis WRT message delivery latencies.
...
In both cases only the local clock is used as reference.
Heartbeats
Once the Client has successfully established a session with the Whisperer Feed Handler (i.e. on dispatch of the first Heartbeat message in response to the end of synchronisation TestRequest), subsequent Heartbeat messages are sent by each party at the interval specified by the Client in it's Logon message.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Test Request
TestRequest messages may be issued by either party and under normal circumstances result in a Heartbeat being sent in response, echoing the specified TestRequestID.
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Logout
| Warning |
|---|
All Logout messages must be echoed with a LogoutResponse. If no LogoutResponse is received within HeartBtInt + MaxTx seconds of the issuance of the Logout, then the session and associated TCP socket connection must be dropped. |
All messages received by the Whisperer Feed Handler (from either the Client or the Venue) between the exchange of Logout and LogoutResponse messages will result in ErrorReport messages being sent to the Client.
ErrorReport
The ErrorReport is a custom, user-defined, message used by the Whisperer Feed Handler to notify the Client when erroneous messages are received:
...
Since there are scenarios where ErrorReport messages may not be delivered (e.g. during session abort sequences), these messages are persisted and will be delivered on reconnection.
Venue Session Management
| Note |
|---|
Whisperer is solely responsible for the management and correct handling of Venue-side Session Synchronisation, including the necessary logic relating to End of Day Resets etc. |
Venue Logon
Session startup behaviour is standardised across Taker, Maker and CLOB Venue types as follows:
- The Client first establishes connection to Whisperer with Logon & LogonResponse, then establishes connection to the Venue with UserRequest (UserRequestType=LogOnUser) & UserNotification (UserStatus=LoggedOn).
- Any Client pricing/trading requests sent before this will be rejected by Whisperer via ErrorReport messages.
Venue Logoff
Venue logoff may be initiated as a result of any of the following:
...
Overview
Content Tools