基于UDP的自定义协议使用0超时recv()是否存在竞态条件？

问题背景 #

我们基于UDP开发的自定义协议已稳定运行多年，两台设备以100Hz频率互传缓冲区数据：

• 启动时明确缓冲区划分的UDP数据报总数及每个数据报对应内容
• 发送端每100Hz触发一次，循环复制本地缓冲区到数据报后调用send()发送
• 接收端以0超时非阻塞模式循环调用recv()，直到无数据返回时停止，期间将数据写入对应本地缓冲区

此前仅需传输2个数据报时一切正常，新增缓冲区后需传输3个数据报，出现以下异常：

• 测试环境无问题，但客户设备抓包显示3个数据报均已发送，软件仅能稳定接收前两个，偶尔收到第三个
• 怀疑是硬件差异或竞态条件导致

推测的问题根源 #

发送端send()循环与接收端非阻塞recv()循环存在竞态：发送端发出第二个数据报后，接收端完成前两个的接收处理并发起下一轮非阻塞recv()时，发送端尚未发出第三个数据报，导致recv()立即返回无数据，接收端误以为本轮传输完成，丢弃了后续到达的第三个数据报。

解决方案可行性分析 #

1. 利用已知数据报总数处理（最轻量化改造） #

这是成本最低的适配方案，完全契合现有协议的启动约定：

• 接收端每次触发接收时，不再以recv()无返回作为终止条件，而是持续接收直到收集到启动时约定的总数据报数
• 必须为每个数据报添加唯一序号标识，避免重复接收旧周期的数据报，同时可按需补充丢包后的重传逻辑
• 优势：无需大幅修改协议格式，仅调整接收端循环终止逻辑，完美适配现有100Hz传输节奏

2. 为recv()设置合理超时阻塞 #

将非阻塞recv()改为带短超时的阻塞模式：

• 超时时间建议设置为10-15ms（略大于100Hz的10ms周期间隔），确保发送端的第三个数据报有足够时间到达接收端
• 接收端循环调用带超时的recv()，直到收集到足够数据报或超时结束
• 优势：代码改动极小，仅调整recv()的超时参数，能有效规避因网络延迟、硬件调度差异导致的竞态漏收

3. 添加握手机制（最严谨但改造量大） #

适合对传输可靠性要求更高的场景：

• 可选方案1：发送端发送完所有数据报后，追加发送一个"传输完成"标记包；接收端收到标记后再终止本轮接收，若超时未收到则触发重传请求
• 可选方案2：接收端每收到一个数据报就回复ACK包，发送端确认所有ACK收到后再结束本轮发送
• 注意：需为握手机制添加超时重传逻辑，避免ACK或标记包丢失导致的死锁
• 优势：彻底解决竞态和UDP丢包问题，大幅提升协议可靠性；劣势：需要修改协议格式及两端逻辑，需精细调整超时参数以适配100Hz的实时节奏

内容的提问来源于stack exchange，提问作者T.E.D.