固定内部序列号

Question

我有一个过程之间的销售客户端和交易所进行货币会话。有两个修复适配器-一个接收来自销售端的消息，并将消息提供给流程。和另一个修复引擎，它从进程中获取消息，并将它们在补丁中发送到交换。

每个FIX消息都有一个被标记34削弱的唯一序列号。但是，这些修复引擎似乎每个都有一个传入序列号( FIX引擎对计数器方的期望)和一个传出序列号( FIX引擎发送给计数器方的内容)。

这些内部序列号是否与标签34无关？

在此配置中，在登录时将销售侧修复引擎的内部序列号重置为1,1。固定引擎到交换的内部序列号不会重置为1,1。

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

然而，我不明白标签34和内部序列号之间的关系。

Answer 1

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

• 每次应用程序发送消息时，它都会增加输出序列号，并将其设置在标记34中。
• 每次应用程序收到一条消息时，它都会增加预期的传入号码，并确保传入消息的标记34与其匹配。

如果您有两个固定会话，那么每个会话都在跟踪一对序列。

通常，提供程序希望在断开连接之间维护序列号。这对于订单管理连接尤其重要，例如，您肯定想知道，如果您的连接由于某种原因而中断，那么任何订单都会被填充。

这对于市场数据输入来说并不那么重要。如果你的连接下降了一分钟，你就不会在意降价时的价格--你现在只需要知道最新的价格。因此，序列在登录时重置。

然而，我不明白标签34和内部序列号之间的关系。

这个问题听起来是引擎特有的。你还没有说明你用的是什么引擎。

但这不重要。您发送的每条消息都应该增加34；内部存储将用于此。您收到的每条消息都应该有34条比最后一条高出1；同样，内部存储也被维护，这样应用程序就可以跟踪这一点。

如果您使用的是任何QuickFIX引擎，那么您就不必担心这个问题了。QF帮你处理这一切。(如果您认为需要处理QuickFIX中的序列号，则可能是错误的。这是个普通的新手问题。只要正确设置配置，引擎就会完成剩下的工作。)