Winsock2 同步 IO ...等待 WSASend 在 WSAGetOverlappedResult 中使用 fWait==TRUE “完成”

Question

我和一位同事对 WSASend 重叠 IO 请求的“完成”构成存在分歧。 他断言在 WSAGetOverlappedResult 调用中使用 fWait 为 TRUE 只会等到消息排队等待发送。 他认为等待写/发送操作“完成”仅意味着消息已成功启动。 在我看来，这远不是到套接字另一侧的“完成”消息......这只是发送的开始而不是完成。 如果 TRUE 的 fWait 在字节被发送并被确认（或错误返回）之前没有阻塞，那么这远非同步......它实际上与异步 IO 相同，因为它只是触发并忘记。

几十年来，我一直在维护我们公司的通信库，了解如何做以及什么是“同步”IO，所以如果我的理解确实错了，我会感到震惊。 但我的同事是一位出色的开发人员，拥有大量 TCP/IP 经验，并且坚信他是对的。 说他甚至在 stackoverflow 上提出了这个问题，并被告知他是对的。 我无法想象我怎么会误解发送的“完成”来表示除了发送请求的字节之外的任何内容确实已发送和确认。 但是在LOL之前我错了

那么……谁是对的？ 等待 WSASend 请求“完成”到底意味着什么？ 只是等到消息在 TCP/IP 堆栈中排队等待发送......或者等待构成消息的所有数据包都被发送和确认？？？ 还是介于两者之间的真相？

Answer 1

你错了。

当不再处理请求时，发送请求完成。 一旦堆栈接管了操作，请求就不再被处理，它的资源可以用于其他目的。

如果你是对的，重叠的 I/O 几乎没有用。 谁愿意等到对方完全确认了先前的发送，然后才能将更多数据排队到 TCP 连接？

如果无法确定排队过程何时完成，重叠 I/O 将如何发挥作用？ 这是应用程序需要知道的，以便它可以发送另一块数据。

您总是会有死区时间，因为发送队列总是必须完全为空，然后才能在发送端排队更多数据。 呸！

无论如何，知道何时收到 ACK 是没有用的。 这并不意味着另一端的应用程序获得了数据。 所以它在应用层没有意义。 知道发送已排队在应用层确实有意义——这意味着您现在可以排队更多要发送的数据，并保证来自先前发送的所有数据将在来自任何数据之前传递到接收的应用层下一次发送。 应用程序需要知道什么。

当发送排队时，对 WASSend 的同步调用也会完成。 异步操作只是意味着您不必等待您在同步操作中等待的任何内容。 所以这是你的理解会很奇怪的另一个原因。

最后，没有标准或通用的方法来等待具有同步操作的远程 ACK。 因此，您必须认为异步操作默认提供的语义甚至不能用于同步操作。 这也很奇怪。

Answer 2

大卫是对的。

WSASend 将在该数据被移交给 TCPIP 堆栈（在其层缓冲）以在传输允许时发送时完成。 如果是阻塞调用，它会等到准备好挂起； 就像它是异步的一样，OVERLAPPED I/O 一旦挂起就会完成。

有人可能会问，为什么这甚至是必要的？ 这种行为对于通过 TCP 连接保持尽可能多的数据传输至关重要。 为了保持尽可能多的数据在传输中，发送者应该调用 WSASend 直到它挂起（回想一下，如果它是一个同步的 WSASend 调用，那么该线程将阻塞直到 WSASend 可以完成；如果它是异步的，则异步完成将在 WSASend 发生后发生通话可以挂起）。

为什么 WSASend 会挂起，为什么不立即完成？ 只有在传输（在内核中）准备好缓冲更多数据时，WSASend 才会完成。 因此，循环直到 WSASend 挂起将使该连接与足够的数据保持一致，以保持最大数据在传输中。

希望这是有道理的。

Answer 3

我的测试似乎表明我确实错了。 发送不存在同步行为......只是接收。 我看到这是一个性能帮助，但我 object 对所有文档说在 WSAGetOverlappedResult 中发送 TRUE 的 fWait 将等到 IO 请求“完成”。 这个词不仅仅意味着排队。 好吧..我很惊讶我的理解是错误的......但是 TCP 处理得很好，以前没有给我造成问题。

感谢您对我沮丧的答复的出色答复和耐心。 我对如何使用暗示我的理解是正确的文字编写所有文档感到非常失望......当一直等待 IO 到“结束”、“完成”、“完成”时，绝对不会等待。