基于C++/FIX8的FIX Dropcopy客户端会话管理与重传问题咨询

问题1：序列号跟踪与重传是否需要手动实现？ #

FIX8库默认会自动处理会话层的序列号跟踪、缺失消息检测和重传请求。对于客户端崩溃、网络故障这类场景，只要配置了会话的序列号持久化（比如通过SessionConfig启用本地存储），重启后库会自动恢复之前的序列号状态，并发起重传协商。无需手动实现这些会话层逻辑。

问题2：发送序列号实现异常的原因分析 #

第一种实现（递增序列号）出现重复MsgSeqNum的原因 #

• 核心问题是send_seqnum未作为会话实例独立的成员变量维护：如果send_seqnum是全局/静态变量，多个会话会共享同一值，导致同一会话内序列号无法正确递增；如果是成员变量但初始化错误（比如每次调用都重置为0），也会返回重复值。
• 多线程竞争：如果多个线程同时调用getNextSendSeqNo()，未加锁的++send_seqnum操作会失去原子性，导致序列号重复或不递增。
• 额外注意：Session::generate_sequence_reset()本身会自动处理序列号，手动调用set_custom_seqnum()可能覆盖库的内置逻辑，建议优先依赖库的序列号管理。

第二种实现（始终返回1）仅收到Logon的原因 #

FIX协议规定：除了携带ResetSeqNumFlag=Y的Logon消息外，后续所有发送的消息必须使用严格递增的MsgSeqNum。服务器收到MsgSeqNum=1的非Logon消息时，会判定为无效（预期序列号是Logon后的2）并直接丢弃，因此你只能收到Logon相关响应，其他消息无法被服务器处理。

问题3：如何彻底重置会话从头读取消息？ #

你当前的Logon消息存在构造错误，导致服务器未执行序列号重置：从提供的消息内容看，BodyLength(9)=0、MsgType(35)为空、CheckSum(10)为空，这些都是必填字段，必须正确计算和填充。正确步骤如下：

1. 正常注销会话：发送Logoff消息，等待服务器返回Logoff响应后断开连接。
2. 本地重置序列号：调用会话的reset_sequence_numbers()方法，或手动将发送/接收序列号重置为1。
3. 发送正确构造的Logon消息：
   • 确保MsgSeqNum=1、ResetSeqNumFlag=Y；
   • 所有必填字段（EncryptMethod、HeartBtInt、Username等）正确赋值；
   • 调用msg->finalize()自动计算BodyLength和CheckSum，避免手动填写错误。

问题4：两种序列号赋值方式的差异 #

• msg->set_custom_seqnum(1);
  这是FIX8提供的高层API，专门用于设置消息的自定义序列号。它会直接修改消息内部维护的序列号值，确保后续序列化时正确填充MsgSeqNum(34)字段，且不会绕过库的内部逻辑，是官方推荐的安全方式。

• *msg->Header() << new FIX8::My::MsgSeqNum(1)
  这是直接向消息Header中添加/覆盖MsgSeqNum字段，存在以下差异：

  1. 需确保FIX8::My::MsgSeqNum对应目标协议版本的字段类型，否则会出现字段不兼容；
  2. 手动操作Header可能绕过库的序列号跟踪逻辑，导致会话层序列号状态混乱；
  3. new出来的字段对象需确认是否由库自动释放，否则可能引发内存泄漏。

优先使用set_custom_seqnum()，仅在特殊场景下考虑直接操作Header字段。

内容的提问来源于stack exchange，提问作者bilge