Socket模型.docVIP

Socket模型详解(转) 一.选择模型 二.异步选择 三.事件选择 四.重叠I/O模型 五.完成端口模型 五种I/O模型的比较 两种I/O模式 1、 两种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函数，那么从理论角度讲，毋需对其进行任何修改，便可正常运行。 服务器的几个主要动作如下： 1.创建监听套接字，绑定，监听； 2.创建工作者线程； 3.创建一个套接字数组，用来存放当前所有活动的客户端套接字，每accept一个连接就更新一次数组； 4.接受客户端的连接。 这里有一点需要注意的，就是我没有重新定义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个.例如套接字列表为128个,在第一次轮询时,将前64个放入队列中用Select进行状态查询,待本次操作全部结束后.将后64个再加入轮询队列中进行轮询处理.这样处理需要在非阻塞式下