我想知道您在接收 FIX 消息时是否通常对会话名称进行硬编码?我注意到您可以收到缺少 SENDER 和 TARGET ID 的 FIX 消息。
例如,我的会话可能如下所示:
FIX.4.1:FIX_INBOUND->STANDALONE_INITIATOR
该信息不能从某些消息中建立,即 8=FIX.4.19=4935=D11=137388006585721=138=140=154=155=LNX10=042
那么我是否正确,您经常必须手动跟踪会话名称?
我想知道您在接收 FIX 消息时是否通常对会话名称进行硬编码?我注意到您可以收到缺少 SENDER 和 TARGET ID 的 FIX 消息。
例如,我的会话可能如下所示:
FIX.4.1:FIX_INBOUND->STANDALONE_INITIATOR
该信息不能从某些消息中建立,即 8=FIX.4.19=4935=D11=137388006585721=138=140=154=155=LNX10=042
那么我是否正确,您经常必须手动跟踪会话名称?
FIX 消息不应该丢失SenderCompID
并且TargetCompID
在标头中。向您发送该信息的人正在向您发送无效的 FIX 消息。
我无法解释为什么您的 QF 引擎不拒绝此“D”消息。也许您在配置中禁用了一些验证检查。(或者,QF 的 C++ 版本可能不会像其他 QF 端口那样验证这些字段。)
但是,我怀疑您的原始登录消息/响应具有正确的 ID,并且您的引擎使用这些 ID 来识别它为您的会话设置的套接字。设置套接字后,它停止验证 ID。老实说,它实际上并不需要在 TCP 套接字上——一旦会话建立,在该套接字上接收到的任何消息都必须是同一会话的一部分。
因此,对于您的问题,答案是“否”,您不必跟踪会话名称。这种情况非常不规则。您的交易对手正在向您发送不良信息。
但是,要解决此问题,您只需查看传递给 QF 回调的 SessionID。这将告诉您此消息来自哪个会话。
> FIX messages should never be missing SenderCompID and TargetCompID in
> the header. Whoever is sending that to you is sending you an invalid
> FIX message.
@Grant - SenderCompID 和 TargetCompID 在 FIX 5.0 之前不是强制性的标头字段。这是 FIX 4.1 的有效消息。
@Fututoad - 通常,旧版本上的消息通过其原始唯一订单 ID 或 ClOrdID (11=13738800658572) 进行跟踪,并根据交易者下订单的 OMS 进行验证(您应该在其中查找信息或用于跟踪交易的内容并确保交易者没有违反他们的风险限制)。
如今,随着 FIX 越来越受欢迎,现在在较新的 FIX(5.0 及更高版本)消息标题中需要这两个字段,以识别下订单的交易者和订单目标的交易对手。