protocols - 修复内部序列号

Question

我在卖方客户和进行货币转换的交易所之间有一个流程。有两个 FIX 适配器 - 一个接收来自卖方的消息并将消息提供给流程。
另一个 FIX 引擎从进程中获取消息并将它们以 FIX 形式发送到交换。

每条 FIX 消息都有一个由标记 34 标识的唯一序列号。 然而，似乎这些 FIX 引擎中的每一个都有一个传入序列号(FIX 引擎期望对方使用什么)和一个输出序列号(FIX 引擎发送到的序列号)对方)。

这些内部序列号是否独立于标签 34？

在此配置中，卖方 FIX ENGINE 的内部序列号在登录时重置为 1,1。 FIX ENGINE 到交换机的内部序列号不会重置为 1,1。

我猜这是因为交易所可能有 GTC 订单，并且两个引擎可能会在成功登录后“下沉”这些订单。

但是我不明白标签 34 和内部序列号之间的关系。

Answer 1

任何 FIX 应用程序必须为每个 session 维护两组序列号:传入和传出。这些序列号是相互独立的。

每次应用程序发送消息时，它都会增加传出序列号并将其设置在标记 34 中。

每次应用程序收到一条消息时，它都会增加预期的传入编号，并确保传入消息的标签 34 与其匹配。

如果您有两个 FIX session ，则每个 session 都在跟踪一对序列。

通常，提供者会希望在断开连接之间维护序列号。这对于订单管理连接尤其重要，例如，如果您的连接由于某种原因中断，您肯定想知道您错过的任何订单执行。

这对于市场数据馈送来说不是那么重要。如果您的连接中断一分钟，您无需关心中断时的价格——您现在只需要知道最新的价格。因此，序列会在登录时重置。

However I don't understand the relation between tag 34 and the internal sequence numbers.

这个问题听起来是特定于引擎的。您尚未指定您使用的引擎。

但应该没有太大关系。您发送的每条消息都应增加 34；内部存储器用于此目的。你收到的每条消息都应该有 34 比上一条高 1；同样，内部存储得到维护，因此应用程序可以跟踪它。

如果您正在使用任何 QuickFIX 引擎，那么您不必担心这一点。 QF 为您处理所有这些。 (如果你认为你需要弄乱 QuickFIX 中的序列号，你可能错了。这是一个常见的新手问题。只要正确设置你的配置，引擎就会完成剩下的工作。)