Communication model¶

Introduction¶

FIX API uses session-based communication. A session is defined as communication between two parties: the initiator (client), the party that initiates communication, and the acceptor (server), the party that receives the connection request from the initiator.

The server validates client requests using the Logon message.

FIX session protocol¶

Each session maintains bi-directional messages between the client and the cTrader server. A session can include multiple physical connections and is maintained using sequence numbers.

Every new message within a single session receives a unique sequence number starting from 1 (one). Both parties rely on sequence numbers to maintain orderly communication. Missing messages are re-transmitted with a bilateral agreement between both parties.

Typical session flow:

1. The client starts the session with a Logon message.
2. The client exchanges application messages with the server.
3. The session ends with a Logout message.

cTrader FIX Protocol message categories¶

As defined in the FIX Protocol, the cTrader FIX server uses 2 different data levels: system and application.

Please note that this is the minimum set of messages required to support the necessary workflows and is subject to change over time as both business needs and the FIX standard evolve.

System (admin) messages¶

• Heartbeat (client ↔ cTrader) – used to check communication link between two parties.
• Test request (client ↔ cTrader) – used to test the health of the communication link.
• Logon (client → cTrader) – client authentication message.
• Logon (client → cTrader) – normal termination of session.
• Resend request (client ↔ cTrader) – request to retransmit certain application messages.
• Reject (client ↔ cTrader) – session level validation failure.
• Sequence reset (client ↔ cTrader) – in case of communication problems missing messages are recovered or the sequence is reset to ignore the missing messages.

Application messages¶

• Market data request (client → cTrader) – general request for market data.
• Market data incremental refresh (client ← cTrader) – responses to a market data request message.
• New order single (client → cTrader) – used to electronically submit the orders to a broker for execution.
• Execution report (client ← cTrader) – used to send order status information to a FIX client, such as confirmations, fills and unsolicited changes.
• Business message reject (client ← cTrader) – used to reject a FIX client request for non-session reasons.

FIX message structure¶

This section explains how the FIX API message is composed, describes the FIX message format and helps users understand the tag and value pair concept.

Each message must contain 3 parts:

• Header – each administrative or application message is preceded by a standard header. The header identifies the message type, FIX version, message length, destination, sequence number, origin and time.
• Body – the content in the body of the message is specified by the message type defined in the header.
• Footer – each message, administrative or application is terminated by a standard footer. The footer is used to segregate messages and contains the three-digit character representation of the CheckSum <10> value.

FIX message format¶

A FIX message is a collection of fields. Each field is a tag-value pair formatted as {tag}={value}. For example, 54=2, which means order type is sell.

Tag¶

• FIX uses predefined tags.
• Each tag represents a specific field.
• Each tag is assigned a predefined number.
• cTrader FIX specification provides a list of fields and corresponding tag numbers.

Value¶

• Values represent the value of the tag assigned to it.
• Values can only be one of the following data types: integer, floating point, character, time, date, data or string.

All messages within cTrader FIX API start with 8=FIX.x.y, where x.y is the version of FIX Protocol. At the end of every message there should be a field 10=xyz, where xyz represents the sum of all binary values in the message called the checksum.

Checksum helps to identify any transmission problems, in particular packet loss by allowing the recipient to know if any of the message is missing.

If the Symbol(55) tag is used in a FIX message to cTrader/cServer, you must specify the FIX symbol ID. That value can be different across brokers. You can find FIX Symbol ID field from that brokers cTrader application in the symbol information window.

Message example¶

8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|