我应该读取前 9 个字节，其中应包括数据包的协议(protocol)和传入大小。
当完成端口返回 9 个字节时哪个更好？ (性能/良好实践或美学方面)
- 在套接字上发送另一个重叠读取，这次使用数据包的大小以便在下一次完成时接收它？
- 使用阻塞套接字在例程中读取整个数据包，然后发布另一个与 recv 重叠的 9 字节？
- 读取 block (决定大小)，比如 - 4096，并有一个计数器继续读取每个重叠完成，直到数据被读取(假设它会完成 12 次，直到所有数据包被读取)。
最佳答案
答案取决于您使用的基础架构。通常，最好的办法是什么都不做。我知道这听起来很奇怪，所以让我解释一下。当操作系统与 NIC 通信时，它通常至少有一对 RX/TX 环形缓冲区，并且在商用硬件的情况下，很可能通过 PCIe 总线与设备通信。在 PCIe 总线之上有一个 DMA 引擎，它使 NIC 可以在不使用 CPU 的情况下从主机内存读取和写入主机内存。换句话说，当 NIC 处于事件状态时，它将始终自行读取和写入数据包，而 CPU 干预最少。当然，有很多细节，但您通常可以认为在驱动程序级别上发生的事情 - 读取和写入始终由 NIC 使用 DMA 执行，无论您的应用程序是否读取/写入任何内容或不。现在，在它之上有一个操作系统基础设施，允许用户空间应用程序向 NIC 发送数据或从 NIC 接收数据。当您打开套接字时，操作系统将确定您的应用程序对哪种数据感兴趣，并在与网络接口(interface)通信的应用程序列表中添加一个条目。发生这种情况时，应用程序开始接收放置在内核中某种应用程序队列中的数据。不管你是否调用read，数据都放在那里。放置数据后，应用程序将收到通知。内核中的通知机制各不相同，但它们都有一个相似的想法——让应用程序知道数据可用于调用 read()。一旦数据进入该“队列”，应用程序就可以通过调用 read() 来获取它。阻塞读取和非阻塞读取之间的区别很简单——如果读取是阻塞的，内核将简单地暂停应用程序的执行，直到数据到达。在非阻塞读取的情况下，控制权在任何情况下都会返回给应用程序——无论是否有数据。如果发生后者，应用程序可以继续尝试(也就是在套接字上旋转)，或者等待内核通知数据可用，然后继续读取它。现在让我们回到“无所事事”。这意味着套接字被注册为只接收一次通知。注册后，应用程序无需执行任何操作，只需收到一条通知，提示“数据已存在”。所以应用程序应该做的是收听该通知并在数据存在时执行只读。一旦收到足够的数据，应用程序就可以开始以某种方式处理它。知道了所有这些，让我们看看这三种方法中哪一种更好...
Post another overlapped read on the socket, this time with the size of the packet so it receives it in the next completion?
这是一个很好的方法。理想情况下，您不必“发布”任何内容，但这取决于操作系统界面的好坏。如果您不能一次“注册”您的应用程序，然后在每次有新数据可用时继续接收通知并在新数据可用时调用 read()，那么发布异步读取请求是下一个最佳选择。
Read inside the routine the whole packet using blocking sockets and then post another overlapped with recv with 9 bytes?
如果您的应用程序完全没有其他事情可做并且您只有一个套接字可以读取，这是一种很好的方法。换句话说——这是一种简单的方法，非常容易编程，操作系统自己负责完成，等等。请记住，一旦你有多个套接字要读取，你将不得不做一个非常愚蠢的事情，比如每个套接字有一个线程(太糟糕了!)，或者使用第一种方法重写您的应用程序。
Read in chunks (decide the size) say - 4096 and have a counter to keep reading each overlapped completion until the data was read (say it would complete 12 times till all the packet was read).
这是要走的路!事实上，这与方法 #1 几乎相同，只是进行了很好的优化，以尽可能少地执行与内核的往返，并一次读取尽可能多的内容。首先，我想用这些细节来纠正第一种方法，但后来我注意到您已经自己完成了。
希望对您有所帮助。祝你好运!
关于c++ - IOCP - 发布重叠或读取数据包？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14911166/