Page History

This page sets out details of how the Feed Handler Gateway initiates or terminates connectivity with the target Venue. The Client initiates this behaviour via UserRequest messages.

...

• The Client first establishes connection to the Feed Handler Gateway with Logon & LogonResponse,
• The Client then instructs the Feed Handler Gateway to establish a connection to the Venue via a UserRequest (UserRequestType=LogOnUser) message.
• The Feed Handler Gateway will attempt to establish connectivity to the Venue
• Once connectivity is established, FIX Session-level messages are exchanged as necessary to  address any synchronisation issues.
• The Feed Handler Gateway then notifies the client of a successful connection via a  UserNotification (UserStatus=LoggedOn) message.
• Any Client pricing/trading requests sent before this will be rejected by Whisperer via ErrorReport messages.

...

For those Venues which reset FIX sessions on a weekly basis, no special action is required, as this matches the Feed Handler Gateway schedule described above.

For persisted (non-Pricing) session types where Venues reset FIX sessions on a daily basis, the Feed Handler Gateway will apply the necessary reset logic for the first successful FIX Session Logon only, at Start of Day. 

For non-persisted Pricing sessions, the Feed Handler Gateway will typically reset the session on every FIX Session Logon.

...

Once instructed to do so by the Client User, the Feed Handler Gateway will attempt to logon to the Venue. Should a connection not be established immediately, it will periodically retry as follows:

• On each failed logon attempt the Feed Handler Gateway will:
  • First issue an ErrorReport(Subject= VenueLogonError, Text="Venue Logon failed, waiting <RetryInterval>s before retry."), then
  • wait RetryInterval seconds (> 0), and repeat.
• Once MaxAttempts (> 0) failed logons occur in a row, the Feed Handler Gateway will:
  • First issue an ErrorReport(Subject= VenueLogonError, Text="Venue Logon failed, waiting <BackoffInterval>s before retry."), then
  • wait BackoffInterval seconds (>= 0) and restart the cycle.

...

• • .

MarketFactory will apply appropriate values to each of these three properties, based on individual Venue requirements. No Customer involvement is required.

This behaviour applies across all Gateways, irrespective of line protocol, Maker/Taker perspective, or trading model.

Unless otherwise specified by the venue, the values outlined above will be preset to the following:

...

In order to ensure that Venue-side session synchronisation issues are avoided, Whisperer implements the following policy:

...

Gateway Detection of Venue Sequence Number Gaps

Non-recoverable Inbound seqNum Gaps

If the incoming message has a sequence number less than expected and the PossDupFlag is not set, then a serious error has occurred. In this scenario, the Feed handler Gateway will issue a UserNotification(UserStatus=LoggedOff, Text="Session synchronization failure.").

...

If a recoverable sequence number gap is detected on receipt of the Venue's logon response, then the Feed Handler Gateway will:

• First issue an ErrorReport(Subject= VenueSeqNumError, Text="Issuing ResendRequest."), then
• a ResendRequest will be issued.

...

As a final verification, the Feed Handler Gateway will issue a TestRequest against the Venue; receipt of the Heartbeat response triggers Whisperer to notify the Client of successful session establishment via the UserNotification(UserStatus=LoggedOn).

The Client User must therefore be capable of receiving and processing re-sent Venue messages relating to it's previous session (marked as PossResend) in the interval between the UserRequest and the UserNotification.

Venue Detection of

...

Gateway Sequence Number Gaps

Non-recoverable Outbound seqNum Gaps

If the Feed HandlerGateway's outgoing Logon message has a lower than expected sequence number from the Venue's perspective, then a serious error has occurred. In this scenario, the Venue will terminate the session and the  Feed handler Gateway will issue a UserNotification(UserStatus=LoggedOff, Text="<Message provided by Venue>").

...

If the sequence number associated with Venue Logon message issued by the Feed Handler Gateway indicates a recoverable gap, then the Venue will typically respond with a Logon response, followed by a ResendRequest.

...

• First issue an ErrorReport(Subject= VenueSeqNumError, Text="Responding to Received ResendRequest."), then
• The gap will then be resolved via SequenceResetGapFill(s) and/or message resends, as mandated by the Venue message persistence requirements.
• Immediately after resolution of the sequence gap, Whisperer will formally Logout from the Venue and then re-Logon.
• As a final verification, the Feed Handler Gateway will issue a TestRequest against the Venue; receipt of the Heartbeat response triggers Whisperer to notify the Client of successful session establishment via the UserNotification(UserStatus=LoggedOn).

...

Any Client User messages that were delivered to the Feed Handler Gateway during Client Session synchronisation will be assigned message sequence numbers that follow sequentially from the end of the previous session. delivered to the Venue  immediately on successful completion of the standard FIX Session Synchronisation.

...

In all scenarios, the Client is notified of the event via UserNotification (UserStatus=LoggedOff).

Whatever the reason, once logged off, it is the Client's responsibility to initiate a new connection via UserRequest (UserRequestType=LogOnUser).

...

The client should not attempt to send venue messages when they do not have an active venue session open.

Prior to the establishment of the venue session, or after it is terminated, any business messages sent by the client will be rejected with an ErrorReport.

...