quickfix - FIX协议(protocol)中使用TargetSubID作为测试数据的标志是否正确?

标签 quickfix fix-protocol quickfixj camel-quickfix

我们目前正在开发 FIX 连接,通过该连接可以标记仅应验证的数据。已决定使用特定的 TargetSubID 来标记此数据。但这意味着新的 session 。

假设我们将消息发送到 session FIX.4.4:S->T。如果我们随后收到一条只能使用 TargetSubID V 进行验证的消息,则这意味着 session FIX.4.4:S->T/V。如果未配置此 session ,我们会收到错误

Unknown session: FIX.4.4:S->T/V

如果我们在另一个 session 旁边显式配置此 session ,则会出现错误

quickfix.Session – [FIX/Session] Disconnecting: Encountered END_OF_STREAM

什么,如bhageera says ,就是您使用相同的凭据登录。

(...) the counterparty I was connecting to allows only 1 connection per user/password (i.e. session with those credentials) at a time.

我不是 FIX 专家,但我想知道 TargetSubID 是否不只是在这里被滥用。如果没有,我想知道该怎么做。我们使用camel-quickfix开发FIX客户端。

最佳答案

这在很大程度上取决于您的系统是什么样的以及您最终想要实现的目标。

通常评估的维度是:

  • 最大限度地提高灵活性
  • 最大限度地减少支持测试所需的额外逻辑量
  • 最大限度地减少从测试环境意外连接到生产环境时发生不良事件的风险(无论您怎么想,都有可能发生)。

就我自己而言,我不会使用可能涉及 session /路由行为的标签进行测试,除非我需要的只是路由功能并且我的系统可靠地按照我期望的方式运行(可能不是您的情况)。

相反,我会考虑其中之一:

  • 从用户定义的范围 (5000-9999) 中选择一些内容
  • 使用以某种可逆方式损坏的符号系统标签之一(例如 Symbol(55))(例如标签 55 中的“TEST_VOD.L”而不是“VOD.L”)

来自自定义范围的标签将提供很大的灵活性,损坏的符号系统标签将确保测试订单在意外发送到产品时会被退回。

对于任一解决方案,您可能都需要基于标记的路由和转换层。如果您使用的是基于 Java 的东西(我希望使用 javax.scripting/Nashorn),那么这两个操作都可以在几个小时内以通用形式完成。

关于quickfix - FIX协议(protocol)中使用TargetSubID作为测试数据的标志是否正确?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47788283/

相关文章:

c++ - quickfix/c++ 中的重复组

python - 如何在 QuickFix DataDictionary 中嵌套重复组?

fix-protocol - FIX 验证消息的实用程序

java - 在 fromApp 方法和 filStorePath 中的消息文件中收到不同的修复消息

quickfix - QuickFIX/J 的数据库表

quickfix - quickfix 消息存储的目的是什么?

quickfix - QuickFIX/J 中 "group"和 "component"之间的区别

c++ - 运行快速修复引擎

c# - 获取 QuickFix/n 的 session 属性(用户名和密码)

java - 快速修复 - 我是否应该在代码中处理序列重置和重新发送请求