Socket模型分析和总结.docxVIP

Socket Socket 模型详解(转) 两种 I/O 模式一.选择模型二.异步选择三.事件选择 四.重叠 I/O 模型五.完成端口模型 五种 I/O 模型的比较 1、 两种 I/O 模式  两种 I/O 模式 阻塞模式：执行 I/O 操作完成前会一直进行等待，不会将控制权交给程序。套接字默认为阻塞模式。可以通过多线程技术进行处理。 非阻塞模式：执行I/O 操作时，Winsock 函数会返回并交出控制权。这种模式使用起来比较复杂，因为函数在没有运行完成就进行返回，会不断地返回 WSAEWOULDBLOCK 错误。但功能强大。 如果你想在 Windows 平台上构建服务器应用，那么 I/O 模型是你必须考虑的。Windows 操作系统提供了选择（Select ）、异步选择（WSAAsyncSelect）、事件选择（WSAEventSelect）、重叠 I/O（Overlapped I/O）和完成端口（Completion Port)共五种 I/O 模型。每一种模型均适用于一种特定的应用场景。程序 员应该对自己的应用需求非常明确，而且综合考虑到程序的扩展性和可移植性等因素，作出自己的选择。客户端所做的事情相当简单，创建套接字，连接服务器，然后不停的发送和接收数据。 较容易想到的一种服务器模型就是采用一个主线程，负责监听客户端的连接请求，当接收到某个客户端的连接请求后，创建一个专门用于和该客户端通信的套接字和 一个辅助线程。以后该客户端和服务器的交互都在这个辅助线程内完成。这种方法比较直观，程序非常简单而且可移植性好，但是不能利用平台相关的特性。例如， 如果连接数增多的时候（成千上万的连接），那么线程数成倍增长，操作系统忙于频繁的线程间切换，而且大部分线程在其生命周期内都是处于非活动状态的，这大 大浪费了系统的资源。所以， 如果你已经知道你的代码只会运行在 Windows 平台上，建议采用Winsock I/O 模型。 一.选择模型 Select（选择）模型是Winsock 中最常见的 I/O 模型。之所以称其为“Select 模型”，是由于它的“中心思想”便是利用 select 函数，实现对 I/O 的管理。最初设计该模型时，主要面向的是某些使用 UNIX 操作系统的计算机，它们采用的是 Berkeley 套接字方案。Select 模型已集成到Winsock 1.1 中，它使那些想 避免在套接字调用过程中被无辜“锁定”的应用程序，采取一种有序的方式，同时进行对多个套接字的管理。由于 Winsock 1.1 向后兼容于 Berkeley 套接字实施方案，所以假如有一个 Berkeley 套接字应用使用了select 函数，那么从理论角度讲，毋需对其进行任何修改，便可正常运行。 服务器的几个主要动作如下： 创建监听套接字，绑定，监听； 创建工作者线程； 创建一个套接字数组，用来存放当前所有活动的客户端套接字，每 accept 一个连接就更新一次数组； 接受客户端的连接。 这里有一点需要注意的，就是我没有重新定义 FD_SETSIZE 宏，所以服务器最多支持的并发连接数为 64。而且，这里决不能无条件的 accept,服务器应该根据当前的连接数来决定是否接受来自某个客户端的连接。 一种比较好的实现方案就是采用 WSAAccept 函数，而且让WSAAccept 回调自己实现的Condition Function。 工作者线程里面是一个死循环，一次循环完成的动作是： 1.将当前所有的客户端套接字加入到读集 fdread 中； 2.调用 select 函数； 3.查看某个套接字是否仍然处于读集中，如果是，则接收数据。如果接收的数据长度为 0，或者发生WSAECONNRESET 错误，则表示客户端套接字主动关闭，这时需要将服务器中对应的套接字所绑定的资源释放掉，然后调整我们的套接字数组（将数组中最后一个套接字挪到当前的位置上） 除了需要有条件接受客户端的连接外，还需要在连接数为 0 的情形下做特殊处理，因为如果读集中没有任何套接字，select 函数会立刻返回，这将导致工作者线程成为一个毫无停顿的死循环，CPU 的占用率马上达到 100% 。 关系到套接字列表的操作都需要使用循环,在轮询的时候,需要遍历一次,再新的一轮开始时,将列表加入队列又需要遍历一次.也就是说,Select 在工作一次时,需要至少遍历2 次列表,这是它效率较低的原因之一.在大规模的网络连接方面,还是推荐使用 IOCP 或EPOLL 模型.但是 Select 模型可以使用在诸如对战类游戏上,比如类似星际这种,因为它小巧易于实现,而且对战类游戏的网络连接量并不大. 对于 Select 模型想要突破Windows 64 个限制的话,可以采取分段轮询,一次轮询 64 个.