Communication Model

Introduction¶

FIX API uses Session Based communication. A session is defined as a communication between two parties, the Initiator (Client), who is the party who initiates the communication and the Acceptor (Server), the party who 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 Client and cTrader entity. A session can include multiple physical connections. A session is maintained using sequence numbers.

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

Typical Session Flow:

1. Client starts the session with LOGON Message
2. Exchange Application Messages with Server
3. Ends with LOGOUT message

cTrader FIX Protocol Message Categories¶

As defined in the FIX Protocol, the cTrader FIX server is using two different data levels: System and Application.

Please note that this is the minimum set of messages required to support the necessary work flows 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
• Logout (Client → cTrader) - Normal Termination of Session
• Resend Request (Client ↔ cTrader) - Request to retransmit the certain application messages
• Reject (Client ↔ cTrader) - Session level validation failure
• Sequence Reset (Client ↔ cTrader) - In case of communication problems missing messages are recovered or 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. This section also describes the FIX message format and helps to understand the FIX 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 = Sell

Tag¶

• FIX uses predefined Tags
• Each Tag represent the 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, 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 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 info-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|