在线游戏TCP消息收发顺序不符问题排查求助

问题背景 #

开发的在线游戏中，多客户端连接服务器，消息顺序对游戏逻辑合规至关重要（如新游戏启动需所有客户端达成一致），但目前存在发送端同时作为接收端时，消息接收顺序与发送顺序不符的问题。调试日志显示发送序列为nwPoll→nwSyncNewGame→nwAnswer，但接收序列为nwSyncNewGame→nwRefresh→nwPoll。

核心排查方向 #

• TCP粘包/拆包问题：TCP是流式协议，不会自动划分消息边界。如果doReadyRead的消息解析逻辑没有正确处理消息边界，可能导致消息被拆分或合并，进而打乱解析顺序。比如发送的nwPoll和nwSyncNewGame字节流被合并，解析时先读取到完整的nwSyncNewGame内容，而nwPoll的部分数据留在缓冲区，后续才被解析。需要检查：

  • 是否采用了可靠的消息封包格式，比如固定长度的消息头（如先发送4字节表示消息总长度），或使用不会出现在消息内容中的唯一分隔符；
  • doReadyRead是否会循环处理缓冲区中所有完整的消息，而非仅处理一次就返回。

• 服务器端消息转发逻辑：由于发送端自身也能收到消息，说明服务器存在消息回传/群转发逻辑。需确认服务器是否严格按照消息接收顺序进行转发：

  • 服务器是否使用多线程处理不同消息，导致高优先级或处理更快的消息被先转发；
  • 服务器的消息队列是否存在插队、优先级排序等逻辑，破坏了原有的发送顺序。

• 客户端接收缓冲区处理逻辑：检查doReadyRead的实现细节：

  • 是否每次触发readyRead时，仅读取了部分缓冲区数据，未处理完所有待解析的消息；
  • 消息解析过程中是否存在错误，比如将某条消息的部分内容误解析为另一条消息（如日志中出现未发送的nwRefresh，需确认其来源是否为解析错误）。

• TCP发送顺序的实际验证：虽然代码中按顺序调用doSend且使用了waitForBytesWritten，但需确认：

  • waitForBytesWritten是否真的保证了数据按顺序写入内核缓冲区（注意该函数仅等待数据写入内核，而非发送到网络，但TCP本身会保证字节流的顺序）；
  • 是否存在其他异步操作干扰doSend的执行顺序，比如在doSend调用之间有耗时操作或事件循环触发。

• 信号槽连接方式的影响：虽然发送与接收均在主线程，但需确认信号槽的连接类型：

  • 如果使用Qt::QueuedConnection，槽函数会被放入事件队列执行，可能与其他主线程事件的执行顺序交织，影响消息处理的感知顺序（但此点不影响doReadyRead中日志打印的接收顺序）。

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