用户提问 #

I have two questions regarding Windows IOCP (I/O Completion Ports) and Overlapped I/O:

1. Order of Asynchronous I/O Operations: #

In Jeffrey Richter's book Windows Via C/C++, the following statement is made:

"You should be aware of a couple of issues when performing asynchronous I/O. First, the device driver doesn't have to process queued I/O requests in a first-in first-out (FIFO) fashion."

This implies that when calling Overlapped I/O functions, the operations might not be processed in the order they were initiated. Here's an example:

// part of iocp tcp server
WSASend( ... ); // 1
WSASend( ... ); // 2
WSASend( ... ); // 3

Is Windows allowed to process the WSASend calls out of the order in which they were called? However, since TCP inherently guarantees message order, how is message sequencing ensured when using Overlapped I/O functions?

2. Completion Notification Order in IOCP: #

It's mentioned that in IOCP model servers, completion notifications might not arrive in the order the I/O was initiated. However, in my experience with IOCP servers, I've never encountered out-of-order message delivery.

• Why doesn't the completion notification order guarantee the sequence of operations?
• If the completion notifications are not in order, how is the message order still maintained?

I appreciate any insights or explanations that could help clarify these points!

问题解答 #

1. 异步I/O操作的执行顺序问题 #

首先明确：Windows确实允许设备驱动不按FIFO顺序处理排队的重叠I/O请求，包括你例子里的WSASend调用。但这和TCP的顺序保证并不冲突，核心原因在于TCP协议栈本身的机制：

当你调用WSASend提交多个发送请求时，即使驱动内部不按提交顺序处理，TCP协议栈会把所有要发送的数据段整理成一个有序的字节流，然后严格按顺序发送到网络上。也就是说，驱动可能先处理WSASend(3)，但TCP会把这段数据缓存起来，等前两段数据发送完成后再推送出去，最终接收端拿到的依然是完整的有序字节流。

举个实际的例子：假设你三次WSASend分别发送"Hello"、"World"、"!"，哪怕驱动先处理第三次的"!"，TCP也会把它放在发送队列的尾部，等前两段数据发送完毕后再发送，接收端最终还是会收到"HelloWorld!"。

另外要注意：这种乱序处理通常是驱动为了优化性能（比如合并相邻的I/O请求减少系统调用开销）才会触发的，不是必然发生的，但你必须在代码设计上考虑到这种可能性——不过完全不用操心TCP的顺序问题，协议层已经帮你做了兜底。

2. IOCP完成通知的顺序问题 #

首先，IOCP的完成通知顺序确实不保证和I/O请求的提交顺序一致，主要有两个原因：

• 不同的I/O请求可能对应不同的驱动处理线程，或者遇到不同的外部条件（比如网络拥塞程度不同），导致处理速度有差异。比如一个WSASend可能因为网络拥堵被延迟，而后续的另一个WSASend刚好赶上空闲的网络资源，先完成了处理。
• 驱动内部的调度逻辑可能优先处理某些类型的请求，或者合并多个小的I/O请求后批量完成，这也会导致完成通知的顺序被打乱。

那为什么你在实际开发中从没遇到过乱序的消息交付？这其实是TCP协议和常见IOCP服务器代码逻辑共同作用的结果：

• 虽然完成通知可能乱序，但TCP依然保证了数据在网络上的发送顺序。也就是说，哪怕WSASend(3)的完成通知先到，它对应的数据也一定是在WSASend(1)和WSASend(2)的数据之后到达接收端的。
• 很多IOCP服务器的代码会为每个连接维护一个发送队列：提交一个WSASend后，不会立刻提交下一个，而是等上一个的完成通知到达后再提交下一个。这种“串行提交”的方式自然会让完成通知按顺序到达，你也就看不到乱序的情况了。如果你的代码是并行提交多个WSASend，那理论上是有可能遇到完成通知乱序的场景的。

总结一下：IOCP的完成通知顺序和实际数据的发送/接收顺序是完全独立的两件事，TCP的顺序保证是在协议层实现的，和IOCP的通知顺序没有直接关联。

备注：内容来源于stack exchange，提问作者Baba