我在卖方客户端和进行货币兑换的交易所之间有一个流程。有两个 FIX 适配器 - 一个接收来自卖方的消息并将消息提供给流程。另一个 FIX 引擎从进程中获取消息并将它们在 FIX 中发送到交换。
每条 FIX 消息都有一个由标签 34 标记的唯一序列号。但是，这些 FIX 引擎中的每一个似乎都有一个 INCOMING SEQUENCE 号（FIX 引擎对交易对方的期望）和一个 OUTGOING SEQUENCE NUMBER（FIX 引擎发送到什么对方）。
这些内部序列号是否独立于标签 34？
在此配置中，卖方 FIX ENGINE 的内部序列号在登录时重置为 1,1。FIX ENGINE 到交换机的内部序列号不会重置为 1,1。
我猜这是因为可能有 GTC 订单在交易所停留，并且两个引擎可能会在成功登录后“沉没”这些闲置订单。
但是我不明白标签 34 和内部序列号之间的关系。
任何 FIX 应用程序必须为每个会话维护两组序列号：传入和传出。这些序列号彼此独立。
如果您有两个 FIX 会话，则每个会话都跟踪一对序列。
通常，提供者会希望在断开连接之间维护序列号。这对于订单管理连接尤其重要，例如，如果您的连接由于某种原因断开，您肯定想知道您错过的任何订单执行。
这对于市场数据馈送不是那么重要。如果您的连接中断了一分钟，您不必关心中断时的价格——您只需要知道现在的最新价格。因此，序列在登录时重置。
但是我不明白标签 34 和内部序列号之间的关系。
这个问题听起来是特定于引擎的。您尚未指定您使用的引擎。
但这应该没什么大不了的。您发送的每条消息都应增加 34；内部存储用于此目的。您收到的每条消息都应该比上一条高 34；再次，内部存储被维护，因此应用程序可以跟踪它。
如果您使用任何 QuickFIX 引擎，那么您不必担心这一点。QF 为您处理这一切。（如果你认为你需要弄乱 QuickFIX 中的序列号，你可能错了。这是一个常见的新手问题。只需正确设置你的配置，引擎会完成剩下的工作。）