Page History

...

All Whisperer Enterprise messages are exchanged over TCP, with connectivity maintained directly between the Client and FH and Feed Handler - so message delivery and ordering are both guaranteed, whilst the socket connection is operating correctly.

...

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 MF Feed Handler - 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.

Resent messages are always characterised by: 

• Msg.messageHeader.msgSeqNum populated with the original sequence number
• Msg.messageHeader.sendingTime populated with the resend time
• Msg.TradingFlags.PossDupFlag = TRUE
• Msg.OrigSendingTime populated with Msg.messageHeader.sendingTime of original message

...

User Session Synchronisation

...

• If the Client msgSeqNum is lower than the FHFeed Handler's expected value, or the Client is expecting a sequence number higher than the FHFeed Handler's next-to-be-assigned msgSeqNum, then this is an unrecoverable error and the FH Feed Handler will abort the session with a Logout message (using it's next sequence number).

  Tip
  The Customer should contact MF Support to agree the correct resolution actions.

  
  

• Otherwise, the FH the Feed Handler will issue a LogonResponse message - populating NextExpectedMsgSeqNum which contains the next msgSeqNum value that it expects to receive from the Client.

...

• If the Client is expecting a sequence number lower than the FHFeed Handler's next-to-be-assigned msgSeqNum (as used in the preceding Logon response), then the message gap is resolved by the FH the Feed Handler with SequenceResetGapFill messages and/or the resending of persisted messages as necessary. The preceding LogonResponse will be gap-filled over. A concluding TestRequest will be issued by the Feed Handler to confirm the end of the replay.

  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 the Feed Handler 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 The Feed Handler will not resend a week's worth of persisted messages. Refer to Message Persistence 63805411 above for more detail.

   Resent messages are characterised by: 

• • Msg.messageHeader.msgSeqNum populated with the original sequence number
  • Msg.messageHeader.sendingTime populated with the resend time
  • Msg.TradingFlags.PossDupFlag = TRUE
  • Msg.OrigSendingTime populated with Msg.messageHeader.sendingTime of original message

• When the MFAPI Client receives the Feed Handler's LogonResponse message, the Client must behave After any inbound sequence number gaps have been resolved for the MFAPI Client, the Client then reciprocates in a similar manner, based on the the next msgSeqNum value that the Whisperer Feed Handler expects to receive from the Client - as specified in it's LogonResponse.The Whisperer Client signals it's the returned NextExpectedMsgSeqNum value. Any message gap must be resolved by the Client with SequenceResetGapFill messages and/or the resending of persisted messages as necessary. The preceding Logon must be gap-filled over. The Feed Handler will issue a concluding TestRequest to confirm the end of the replay.

• Irrespective of whether repays are required in either direction or not, the Feed Handler will always issue a further TestRequest to verify overall completion of the session synchronisation. Thus the Client may be expected to respond to one, two or three TestRequest messages in total to successfully Logon.

...

...

...

Erroneous Scenarios

Second Logon to Existing Session

...

For inbound Heartbeat and TestRequest messages sent by the Client , the FH the Feed Handler 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.

The Client may specify it's own MaxTx value and logic when monitoring inbound messages sent by the FHFeed Handler.

In both cases only the local clock is used as reference.

...

• The HeartBtInt value is specified by the Client in their Logon message and subsequently used by both sides of the Client Session, i.e. the FH the Feed Handler will always use the interval specified by the Client.
• The heartbeat interval timer should be reset after every message is transmitted (not just heartbeats).
• On expiry of the heartbeat interval timer, a Heartbeat message must be sent.

...