socket模型区别

 如何监控socket的变化
 如何通知socket的变化
 

1.select  :
     应用场合:主要面向的是某些使用U n i x操作系统的计算机，它们采用的是B e r k e l e y套接字方案。s e l e c t模型已集成到Winsock 1.1中，它使那些想避免在套接字调用过程中被无辜“锁定”的应用程序，采取一种有序的方式，同时进行对多个套接字的管理.
     原理: 利用select函数，我们判断套接字上是否存在数据，或者能否向一个套接字写入数据.

2.WSAAsyncSelect :
     应用场合:用于帮助应用程序开发者面向一些早期的16位Windows平台（如WindowsforWorkgroups），适应其“落后”的多任务消息环境。应用程序仍可从这种模型中得到好处，特别是它们用一个标准的Windows例程（常称为“winproc”），对窗口消息进行管理的时候。该模型亦得到了MicrosoftFoundationClass微软基本类，MFC）对象CSocket的采纳,
     原理:利用WSAAsyncSelect来处理FD_READ、FD_WRITE、FD_ACCEPT、FD_CONNECT、FD_CLOSE消息

3 WSAEventSelect:
      应用场合: 各种异步Socket 程序. WSAWaitForMultipleEvents 限制最多只能等待64个Event . 
      原理: 将socket的各种变化通过Event来通知 区别WSAAsyncSelect 窗口消息来通知

4.OverlappedI/O:
       应用场合: 与WSAEventSelect模式类似
       原理: 将socket的各种变化通过Event来通知  并多了一个绑定的event处理过程.

5.Completionport:
       应用场合: 完成端口”模型是迄今为止最为复杂的一种I / O模型。然而，假若一个应用程序同时需要管理为数众多的套接字，那么采用这种模型，往往可以达到最佳的系统性能！但不幸的是，该模型只适用于Windows NT和Windows 2000操作系统。因其设计的复杂性，只有在你的应用程序需要同时管理数百乃至上千个套接字的时候，而且希望随着系统内安装的C P U数量的增多，应用程序的性
能也可以线性提升，才应考虑采用“完成端口”模型
        原理: 完成端口模型要求我们创建一个Wi n 3 2完成端口对象，通过指定数量的线程，对重叠I / O请求进行管理，以便为已经完成的重叠I / O请求提供服务

 

下面是我的一些理解，不知道是否正确，请指教。
综合几种I/O模式，我认为两种模式来实现服务器端的程序是比较好的，一个是最简单的阻塞模式，一个是IOCP。

说简单的阻塞模式好，是因为它实现简单，通常情况下最与服务器来说，是一个主线程用来accept用户的连接，用户连接来之后，单独的启动一个工作线程为其服务，那么可以在工作线程里按照顺序对接收到的数据进行处理，因此实现起来逻辑关系清晰，除了注意一些多线程的安全性，比较容易理解。问题是，当遇到大量的并发连接的时候，大量线程对资源的占用难以为继，因此一般需要多用户的服务器通常会选择其他的模式。

那么要说性能好，可扩展，那就一定是IOCP。从实现的复杂度来说，IOCP也并不是其他几种模式里最复杂的。IOCP里面的数据乱序问题大概是需要注意的地方，再有就是要注意多线程的安全性。

select模式，应该主要是为了与*nix和早期的win3.1系统兼容而使用的，每个处理都要先经过select，性能很难理想
WSAAsyncSelect模式，由于有每线程64object的限制，而且使用窗口的消息机制，也不会有很好的性能
WSAEventSelect，同样的具有64 event的问题。

那么后面的这几个模式到底应该什么情况下使用呢，是不是用IOCP搭建一个优质的框架，以后很多的服务器都可以复用了呢？