The Lab

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

Whisperer is solely responsible for the management and correct handling of Venue-side FIX 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 the Feed Handler with Logon & LogonResponse,
  • The Client then instructs the Feed Handler to establish a connection to the Venue via a UserRequest (UserRequestType=LogOnUser) message.
  • The Feed Handler 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 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.

FIX Session Reset

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

For persisted (non-Pricing) session types where Venues reset FIX sessions on a daily basis, the Feed Handler 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 will typically reset the session on every FIX Session Logon.

FIX Session Establishment

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

  • On a failed logon attempt the Feed Handler will wait RetryInterval seconds (> 0), and repeat.
  • Once MaxAttempts (> 0) failed logons occur in a row, the Feed Handler will
  • wait BackoffInterval seconds (>= 0) and restart the cycle.


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

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


Should the Client User wish to instruct the Feed Handler to cease attempting to connect to the Venue at any time during this cycle, then it may issue a UserRequest (UserRequestType=LogOffUser) message.


Venue Connection - FIX Session Synchronisation

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


Feed Handler Detection of Venue Sequence Number Gaps

If a sequence number gap is detected on receipt of the Venue's logon response, then a ResendRequest will be issued.

Whilst a sequence gap exists, no other Venue messages will be processed until the sequence gap is resolved - via SequenceResetGapFill(s) and message resends, as the Venue deems necessary.

Once the sequence gap is resolved, Whisperer will formally Logout from the Venue and then re-Logon. Standard Logon processing will thus only progress when complete, clean session synchronisation is guaranteed.

As a final verification, the Feed Handler 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 resent Venue messages relating to it's previous session (marked as PossResend) in the interval between the UserRequest and the UserNotification.


Venue Detection of Feed Handler Sequence Number Gaps

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

Whisperer will respond to this via SequenceResetGapFill(s) and/or message resends, as mandated by the Venue. Immediately after resolution of the sequence gap, Whisperer will formally Logout from the Venue and then re-Logon.


Client Session Synchronisation

Any Client User messages that were delivered to the Feed Handler 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.

This is not technically a FIX session synchronisation event and whilst the PossDupFlag will be set to mark it as a resend,  the sequence number used will be new.

The Venue may possibly respond with a Reject or BusinessMessageReject, in which case the User will receive an ErrorReport as notification.


Venue Logoff

Venue logoff may be initiated as a result of any of the following:

  • A request from the Client via UserRequest (UserRequestType=LogOffUser).
  • The Venue initiates a Logout (e.g. End of Day).
  • Whisperer detects a dropped connection
  • Whisperer shutdown

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


4.0 Schema_Heartbeat.03



TODO

user sends initiates a transaction after after receiving a loggedout user notification

  • No labels