...

This seems to be the same as 1?

Overview

Session Types

Whisperer SBE4 Maintains the following session types:

• Pricing - used for delivery of Market Data from a CLOB Venue, or ESP mass-quotes from a Maker.
• Orders - used for submission and execution of CLOB Venue orders, or trading against ESP Maker liquidity (published on a separate Pricing session).
• RFS - used for the full RFS/RFQ quotation negotiation life cycle between Maker and Taker.
• DropCopy - used for the delivery of post-Trade Straight-Through Processing (STP) trade notifications. Typically this will be 

Session Schedule

All session types are maintained directly with an individual Whisperer Feed Handler and operate a weekly schedule commencing on Sunday prior to Asia-open and ending on Friday, NY-close. This is 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:

• messageLength - this is provided to allow verification that the full message has indeed been received (e.g. should it span multiple packets).
• msgSeqNum - this is the standard integer message sequence number. At the start of a session it should be set to '1', and incremented with every subsequent message sent.
• sendingTime - nanosecond-precision timestamp indicating when the message left the sender.

Logon

Session Synchronisation

The Whisperer SBE4 APi 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.

The MFAPI client initiates a new session with a Logon

...

message - this contains the next MsgSeqNum[34] value that the client expects to receive from the Whisperer Feed Handler. 

The Whisperer Feed Handler validates the sequence number value as expected by the MFAPI client as follows:

If the Client is expecting a sequence number higher than the FH's next-to-be-assigned msgSeqNum, then this is an unrecoverable error and the FH will abort the session with a Logout message.

Otherwise the FH will issue a LogonResponse message containing the next MsgSeqNum[34] value that it expects to receive from the client.

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 the resending of persisted messages as necessary.

The Whisperer Feed Handler signals it's completion of session synchronisation with a TestRequest.

After any inbound sequence number gaps have been resolved for the MFAPI Client, it then reciprocates in a similar manner, based on the the next MsgSeqNum[34] value that the Whisperer Feed Handler expects to receive from the client - as specified in it's LogonResponse.

The mutual exchange of TestRequest and Heartbeat messages are required as verification that no sequence number gaps remain. The MFAPI client should only proceed after it has received the Heartbeat sent in response to it's own TestRequest.

Message Persistence

The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled:

...