在生产中是否可以使用quickfix / j从消息生成会话名称

时间:2013-07-02 16:15:18

标签: quickfix fix-protocol

我想知道你在接收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

所以我认为您经常需要手动跟踪会话名称吗?

2 个答案:

答案 0 :(得分:1)

标题中的FIX消息永远不会丢失SenderCompIDTargetCompID。无论是谁发送给你的是向你发送无效的FIX信息。

我无法解释为什么你的QF引擎没有拒绝这个“D”消息。也许您已在配置中禁用了一些验证检查。 (或者QF的C ++版本不会像其他QF端口那样验证这些字段。)

但是,我怀疑您的原始登录消息/响应具有正确的ID,并且您的引擎使用这些ID来标识它为您的会话设置的套接字。设置套接字后,它停止验证ID。说实话,它确实不需要在TCP套接字上 - 一旦建立会话,在该套接字上收到的任何消息都必须是同一会话的一部分。

因此,对于您的问题,答案是“否”,您不必跟踪会话名称。这种情况非常不规律。您的对手方正在向您发送错误消息。

但是,要解决此问题,您只需查看传递给QF回调的SessionID即可。那将告诉你这条消息来自哪个会话。

答案 1 :(得分:0)

> 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 - 在FIX 5.0之前,SenderCompID和TargetCompID不是必需的头字段。这是FIX 4.1的有效信息。

@Fututoad - 通常,旧版本的消息由其始发唯一订单ID或ClOrdID(11 = 13738800658572)进行跟踪,并根据交易者为此订单进行的OMS进行验证(您应查看该信息或您使用的内容)跟踪交易并确保交易者不会违反其风险限制)。

如今,随着FIX越来越受欢迎,现在需要更新的FIX(5.0以后)消息标题中的这两个字段来识别发出订单的交易者和订单所针对的交易对手。

  • 8 = FIX.4.1 *标准使用
  • 9 = 49 *长度
  • 35 = D * New Order Single
  • 11 = 13738800658572 *原始唯一订单ID(ClOrdID)
  • 1 = 1 *帐户
  • 38 = 1 *订单数量
  • 40 = 1 *市场
  • 54 = 1 *买方
  • 55 = LNX * Ticker
  • 10 = 042 * Checksum