Socket I/O模型

网络程序入门后的第一件是就是学会选择合适的io模型，这对于一个网络程序来说非常重要，特别是性能。当前Windows支持的各种Socket I/O模型如下： 

select模型 
WSAAsyncSelect模型 
WSAEventSelect模型 
Overlapped I/O 事件通知模型 
Overlapped I/O 完成例程模型 
IOCP模型 

（这里以下的介绍援引csdn里“flyinwuhan（制怒·三思而后行）”的一篇诙谐有趣而又生动的文章做说明。） 

老陈有一个在外地工作的女儿，不能经常回来，老陈和她通过信件联系。他们的信会被邮递员投递到他们的信箱里，这和Socket模型非常类似。 

select模型 

老陈非常想看到女儿的信。以至于他每隔10分钟就下楼检查信箱，看是否有女儿的信~~~~~ 
在这种情况下，“下楼检查信箱”然后回到楼上耽误了老陈太多的时间，以至于老陈无法做其他工作。 

select模型和老陈的这种情况非常相似：周而复始地去检查......如果有数据......接收/发送....... 

//相当于有个while循环一直在等待消息的到来，导致浪费CPU时间。

WSAAsyncSelect模型 

后来，老陈使用了微软公司的新式信箱。这种信箱非常先进，一旦信箱里有新的信件，盖茨就会给老陈打电话：喂，大爷，你有新的信件了！从此，老陈再也不必频繁上下楼检查信箱了，牙也不疼了，你瞅准了，蓝天......不是，微软~~~~~~~~ 
微软提供的WSAAsyncSelect模型就是这个意思。 
WSAAsyncSelect模型是Windows下最简单易用的一种Socket I/O模型。使用这种模型时，Windows会把网络事件以消息的形势通知应用程序。 

//有所改进，在发送消息之前先发送命令，用来通知将有消息到来，然后接收方再等待消息的到来，提高CPU利用率。

WSAEventSelect模型 

后来，微软的信箱非常畅销，购买微软信箱的人以百万计数......以至于盖茨每天24小时给客户打电话，累得腰酸背痛，喝蚁力神都不好使~~~~~~ 
微软改进了他们的信箱：在客户的家中添加一个附加装置，这个装置会监视客户的信箱，每当新的信件来临，此装置会发出“新信件到达”声，提醒老陈去收信。盖茨终于可以睡觉了。 

//在接收端设置消息响应函数，当有消息到来时启动消息响应函数用来通知接收端消息将到。

Overlapped I/O 事件通知模型 

后来，微软通过调查发现，老陈不喜欢上下楼收发信件，因为上下楼其实很浪费时间。于是微软再次改进他们的信箱。新式的信箱采用了更为先进的技术，只要用户告诉微软自己的家在几楼几号，新式信箱会把信件直接传送到用户的家中，然后告诉用户，你的信件已经放到你的家中了！老陈很高兴，因为他不必再亲自收发信件了！ 

Overlapped I/O 事件通知模型和WSAEventSelect模型在实现上非常相似，主要区别在“Overlapped”，Overlapped模型是让应用程序使用重叠数据结构(WSAOVERLAPPED)，一次投递一个或多个Winsock I/O请求。这些提交的请求完成后，应用程序会收到通知。什么意思呢？就是说，如果你想从socket上接收数据，只需要告诉系统，由系统为你接收数据，而你需要做的只是为系统提供一个缓冲区~~~~~ 
Listen线程和WSAEventSelect模型一模一样，Recv/Send线程则完全不同： 
 

Overlapped I/O 完成例程模型 

老陈接收到新的信件后，一般的程序是：打开信封----掏出信纸----阅读信件----回复信件......为了进一步减轻用户负担，微软又开发了一种新的技术：用户只要告诉微软对信件的操作步骤，微软信箱将按照这些步骤去处理信件，不再需要用户亲自拆信/阅读/回复了！老陈终于过上了小资生活！ 

//当有消息到来时接收端直接启动响应函数进行消息接收处理

Overlapped I/O 完成例程要求用户提供一个回调函数，发生新的网络事件的时候系统将执行这个函数： 
procedure WorkerRoutine( const dwError, cbTransferred : DWORD; const 
lpOverlapped : LPWSAOVERLAPPED; const dwFlags : DWORD ); stdcall; 
然后告诉系统用WorkerRoutine函数处理接收到的数据： 
WSARecv( m_socket, @FBuf, 1, dwTemp, dwFlag, @m_overlap, WorkerRoutine ); 
然后......没有什么然后了，系统什么都给你做了！微软真实体贴！ 
while ( not Terminated ) do//这就是一个Recv/Send线程要做的事情......什么都不用做啊！！！ 


IOCP模型 

微软信箱似乎很完美，老陈也很满意。但是在一些大公司情况却完全不同！这些大公司有数以万计的信箱，每秒钟都有数以百计的信件需要处理，以至于微软信箱经常因超负荷运转而崩溃！需要重新启动！微软不得不使出杀手锏...... 
微软给每个大公司派了一名名叫“Completion Port”的超级机器人，让这个机器人去处理那些信件！ 

“Windows NT小组注意到这些应用程序的性能没有预料的那么高。特别的，处理很多同时的客户请求意味着很多线程并发地运行在系统中。因为所有这些线程都是可运行的 [没有被挂起和等待发生什么事]，Microsoft意识到NT内核花费了太多的时间来转换运行线程的上下文[Context]，线程就没有得到很多 CPU时间来做它们的工作。大家可能也都感觉到并行模型的瓶颈在于它为每一个客户请求都创建了一个新线程。创建线程比起创建进程开销要小，但也远不是没有开销的。我们不妨设想一下：如果事先开好N个线程，让它们在那hold[堵塞]，然后可以将所有用户的请求都投递到一个消息队列中去。然后那N个线程逐一从消息队列中去取出消息并加以处理。就可以避免针对每一个用户请求都开线程。不仅减少了线程的资源，也提高了线程的利用率。理论上很不错，你想我等泛泛之辈都能想出来的问题，Microsoft又怎会没有考虑到呢?”-----摘自nonocast的《理解I/O Completion Port》 

先看一下IOCP模型的实现： 

//创建一个完成端口 
FCompletPort := CreateIoCompletionPort( INVALID_HANDLE_VALUE, 0,0,0 ); 

//接受远程连接，并把这个连接的socket句柄绑定到刚才创建的IOCP上 
AConnect := accept( FListenSock, addr, len); 
CreateIoCompletionPort( AConnect, FCompletPort, nil, 0 ); 

//创建CPU数*2 + 2个线程 
for i:=1 to si.dwNumberOfProcessors*2+2 do 
begin 
AThread := TRecvSendThread.Create( false ); 
AThread.CompletPort := FCompletPort;//告诉这个线程，你要去这个IOCP去访问数据 
end; 

OK，就这么简单，我们要做的就是建立一个IOCP，把远程连接的socket句柄绑定到刚才创建的IOCP上，最后创建n个线程，并告诉这n个线程到这个IOCP上去访问数据就可以了。 

再看一下TRecvSendThread线程都干些什么： 

procedure TRecvSendThread.Execute; 
var 
...... 
begin 
while (not self.Terminated) do 
begin 
//查询IOCP状态（数据读写操作是否完成） 
GetQueuedCompletionStatus( CompletPort, BytesTransd, CompletKey, POVERLAPPED(pPerIoDat), TIME_OUT ); 

if BytesTransd <> 0 then 
....;//数据读写操作完成 

//再投递一个读数据请求 
WSARecv( CompletKey, @(pPerIoDat^.BufData), 1, BytesRecv, Flags, @(pPerIoDat^.Overlap), nil ); 
end; 
end; 

读写线程只是简单地检查IOCP是否完成了我们投递的读写操作，如果完成了则再投递一个新的读写请求。 
应该注意到，我们创建的所有TRecvSendThread都在访问同一个IOCP（因为我们只创建了一个IOCP），并且我们没有使用临界区！难道不会产生冲突吗？不用考虑同步问题吗？ 
呵呵，这正是IOCP的奥妙所在。IOCP不是一个普通的对象，不需要考虑线程安全问题。它会自动调配访问它的线程：如果某个socket上有一个线程A正在访问，那么线程B的访问请求会被分配到另外一个socket。这一切都是由系统自动调配的，我们无需过问。