Try TT Now

ADL®

Continuous vs. Discrete Event Messages

During the execution of an automated strategy, ADL will continuously send and receive information from an exchange server. In ADL, every piece of information is characterized as either a Continuous Message or a Discrete Event Message.

 
Recommended Tutorials For This Section

For a tactile learning experience, please try the following tutorials:

  • Continuous vs. Discrete Events
  • Getting Information About a Fill
  • Using Discrete Events for Timing Precision
  • Using Discrete Events to Trigger Downstream Actions
  • Routing Discrete Event Messages in a Specific Order
  • Enhancing Your Scalper Algorithm
Continuous Messages
  • Continuous Messages: Information that is continuously disseminated by an exchange. For instance, the bid quantity available at a specific price level is considered to be a Continuous Message since this information is essentially a continuous stream of data available at all times.
  • Continuous Messages from an exchange are channeled into an algorithm through few designated blocks such as the Instrument Attribute Block. Other downstream blocks may use these channeled Continuous Messages to produce continuous outputs of their own. Such continuous outputs flow through an algorithm via Numeric, True/False, Instrument or Variable ports.

    Example: The Instrument Attribute Block channels a stream of continuous data from an exchange

Discrete Event Messages
  • Discrete Event Messages: Information disseminated from or submitted to an exchange upon occurrences of market events that happen at a single moment in time (denoted as Discrete Events). For instance, a Fill Confirmation message from an exchange server is considered to be a discrete event message since this information is a pulse of data disseminated only at the moment of an order execution.
  • The following market events are considered to occur at a single moment in time: Fill Confirmation, Order Add Request/Confirmation, Order Modify Request/Confirmation, and Order Delete Request/Confirmation
  • Several designated blocks, such as the Order Block, may exchange discrete event messages directly with an exchange. When a block submits or receives a discrete event message, it will distribute a copy of the message throughout the rest of the algorithm in the form a single pulse. A discrete event message may flow through an algorithm via discrete event message ports.

    Example: The Order Block is one of several designated blocks in ADL which can submit and receive discrete event messages from an exchange server

  • Several blocks which do not interact directly with an exchange can also send a pulse of discrete event message throughout an algorithm at user-defined moments. However, since such discrete event messages are not associated with any real requests or confirmations, these messages are void of information and merely provide the function of triggering downstream blocks to perform an action at user-defined moments (e.g., resetting a block's continuous output values).
Using Discrete Event Messages For Timing Precision

Discrete event messages have a key characteristic: when a block outputs a pulse of discrete event message, an algorithm temporarily stops channeling continuous messages from the exchange servers. Continuous message channels will remain closed while the pulse of discrete event message propagates throughout the algorithm. In effect, this behavior will "freeze" the output of blocks such as the Instrument Field Block which channels streaming market data. In this static state, the pulse of discrete event message will traverse the pathway designed by the user, updating the output values of the blocks which lie in its path. Once this propagation is complete, the algorithm will resume channeling continuous messages from all exchange servers.

Note that such propagation takes place within microseconds and will not be perceivable in practice. With this mechanism, however, ADL allows the user to capture and use the market data existing precisely at the moment of a discrete event.

The following is a simplified illustration of this mechanism in effect:

1. The diagram below shows an example of an Instrument Field Block (yellow block on the left) channeling a continuous numeric value into the Order Block (blue block on the right). The Instrument Field Block channels the best bid price of an instrument specified by the user, and the Order Block uses this streaming data to quote buy orders at the best bid price for the specified instrument with the specified quantity (instrument and quantity inputs are not shown in the illustration).

2. When one or more of the quoted orders are executed, the Order Block receives a Fill Confirmation message from the exchange server and outputs a discrete event message in the form of a single pulse. At this time, the algorithm stops channeling continuous messages from the exchange server. The pulse of discrete event message propagates through the algorithm, following the pathway designed by the user. It updates the output values of the blocks which lie in its path.

3. Once the propagation is complete, the algorithm resumes channeling continuous messages from the exchange server.

View: Application In A Spreader Strategy

Application In A Spreader Strategy

To see why this characteristic is essential for the sound execution of an algorithm, consider the following example:

  1. Suppose that a spreader algorithm is designed to buy a 1:1 spread consisting of two legs: ZS Mar 11 (the "quote leg") and ZS May 11 (the "hedge leg"). Specifically, the algorithm is designed to quote a bid at the appropriate price for ZS Mar 11, leaning on the best bid price of ZS May 11.

    Example: ZS Mar11 - ZS May11 Spreader Algorithm

  2. Suppose that the quoted bid for ZS Mar 11 is executed. However, one microsecond following the fill, the best bid price of ZS May 11 (the lean price) changes before the algorithm can submit the corresponding hedge order.

    Example: Hedge Leg lean price changes following the fill

  3. In this case, it would be undesirable for the algorithm to submit a hedge order at the new best bid price of ZS May 11. However, by designing a block within the algorithm to generate and output a discrete event message upon the order execution in ZS Mar 11, the correct hedge price can be captured at the precise moment of the quote leg fill. To be specific, the algorithm will stop channeling continuous messages from the exchange server at the exact moment of the quote leg fill, thereby ignoring the change in the best bid price of ZS May 11 which occurred one microsecond after the fill.

    Example: Capturing the correct Hedge Price