通信模型¶

简介 ¶

FIX API 使用基于会话的通信。 会话定义为两方之间的通信：发起方（客户端），即发起通信的一方，和接受方（服务器），即接收发起方连接请求的一方。

服务器使用登录消息验证客户端请求。

FIX 会话协议 ¶

每个会话在客户端和 cTrader 服务器之间维护双向消息。 一个会话可以包含多个物理连接，并使用序列号维护。

单个会话内的每个新消息都会收到一个从 1（一）开始的唯一序列号。 双方依靠序列号来维持有序通信。 缺失的消息会通过双方协议重新传输。

典型的会话流程：

1. 客户端以登录消息开始会话。
2. 客户端与服务器交换应用程序消息。
3. 会话以注销消息结束。

cTrader FIX 协议消息类别 ¶

根据 FIX 协议的定义，cTrader FIX 服务器使用两种不同的数据级别：系统和应用程序。

请注意，这是支持必要工作流程所需的最小消息集，随着业务需求和 FIX 标准的发展，可能会随时间而变化。

系统（管理）消息 ¶

• 心跳（客户端 ↔ cTrader） – 用于检查双方之间的通信链接。
• 测试请求（客户端 ↔ cTrader） – 用于测试通信链接的健康状况。
• 登录（客户端 → cTrader） – 客户端身份验证消息。
• 登出（客户端 → cTrader） – 会话的正常终止。
• 重发请求（客户端 ↔ cTrader） – 请求重新传输某些应用程序消息。
• 拒绝（客户端 ↔ cTrader） – 会话级验证失败。
• 序列重置（客户端 ↔ cTrader） – 在通信问题的情况下，恢复缺失的消息或重置序列以忽略缺失的消息。

应用程序消息 ¶

• 市场数据请求（客户端 → cTrader） – 一般市场数据请求。
• 市场数据增量刷新（客户端 ← cTrader） – 对市场数据请求消息的响应。
• 新单（客户端 → cTrader） – 用于以电子方式向经纪商提交订单以执行。
• 执行报告（客户端 ← cTrader） – 用于向 FIX 客户端发送订单状态信息，如确认、成交和未经请求的变更。
• 业务消息拒绝（客户端 ← cTrader） – 用于因非会话原因拒绝 FIX 客户端请求。

FIX 消息结构 ¶

本节解释 FIX API 消息的组成方式，描述 FIX 消息格式，并帮助用户理解标签和值对的概念。

每条消息必须包含 3 个部分：

• 头部 – 每个管理或应用程序消息前面都有一个标准头部。 头部标识消息类型、FIX 版本、消息长度、目的地、序列号、来源和时间。
• 主体 – 消息主体中的内容由头部中定义的消息类型指定。
• 尾部 – 每条消息（管理或应用程序）都以标准尾部结束。 尾部用于分隔消息，并包含 CheckSum <10> 值的三位字符表示。

FIX 消息格式 ¶

FIX 消息是字段的集合。 每个字段是一个标签-值对，格式为 {tag}={value}。 例如，54=2，表示订单类型为卖出。

标签 ¶

• FIX 使用预定义的标签。
• 每个标签代表一个特定字段。
• 每个标签都分配了一个预定义的数字。
• cTrader FIX 规范提供了字段列表和相应的标签号。

值 ¶

• 值表示分配给它的标签的值。
• 值只能是以下数据类型之一：整数、浮点数、字符、时间、日期、数据或字符串。

cTrader FIX API 中的所有消息都以 8=FIX.x.y 开头，其中 x.y 是 FIX 协议的版本。 每条消息的末尾应该有一个字段 10=xyz，其中 xyz 表示消息中所有二进制值的总和，称为校验和。

校验和有助于识别任何传输问题，特别是通过允许接收方知道是否有任何消息丢失来识别数据包丢失。

如果在 FIX 消息中使用 Symbol(55) 标签发送到 cTrader/cServer，您必须指定 FIX 交易品种 ID。 该值在不同经纪商之间可能不同。 您可以在该经纪商的 cTrader 应用程序的交易品种信息窗口中找到 FIX 交易品种 ID 字段。

消息示例 ¶

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|