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 到“結束”、“完成”、“完成”時，絕對不會等待。