使用IOCP的UDP场景下WSARecvFrom返回值行为疑问

核心结论 #

不要忽略返回0的情况，但必须通过OVERLAPPED结构体的InternalHigh成员获取实际接收字节数，绝对不能依赖lpNumberOfBytesRecvd。

详细解释 #

• IOCP模式下的参数规范：当使用IOCP搭配重叠IO调用WSARecvFrom时，文档明确要求lpNumberOfBytesRecvd必须传NULL。这种场景下，即使操作立即完成返回0，lpNumberOfBytesRecvd也不会被更新，实际接收字节数会写入OVERLAPPED.InternalHigh——你遇到的现象完全符合这个规范。
• 返回0的真实含义：这里的返回0表示UDP数据已经在系统缓冲区中，接收操作立即同步完成，并非错误（UDP无连接，不存在“连接关闭”的语义）。此时不需要等待IOCP的GetQueuedCompletionStatus通知，直接处理缓冲区数据即可。
• “忽略返回0”的误区：论坛说法是对规范的误解。正确做法不是忽略，而是跳过IOCP等待流程，直接用InternalHigh的字节数处理已接收的数据。忽略的话会直接丢失这部分立即到达的UDP包。
• 文档表述模糊的原因：WinAPI重叠IO设计兼容两种使用场景：

  一种是不绑定IOCP（用事件通知或完成例程），这种场景下操作立即完成时，lpNumberOfBytesRecvd会被正确填充；
  另一种是绑定IOCP，此时要求lpNumberOfBytesRecvd为NULL，数据量通过OVERLAPPED传递。
  文档没有明确区分两种场景的参数行为差异，导致开发者混淆。

关键注意点 #

• 若WSARecvFrom返回ERROR_IO_PENDING，才需要通过GetQueuedCompletionStatus等待异步完成通知，此时从GetQueuedCompletionStatus的lpNumberOfBytesTransferred参数获取字节数；
• 若返回0，直接读取OVERLAPPED.InternalHigh，然后处理缓冲区数据，之后重新投递下一个WSARecvFrom接收请求。

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