三种模式的简介与比较.pptVIP

select，poll，epoll三种通信模式的比较;select为什么会出现;int iResult = ioctlsocket(s, FIOBIO, (unsigned long *)ul); iResult = recv(s, buffer,1024); 这一次recv的调用不管套接字连接上有没有数据可以接收都会马上返回。原因就在于我们用ioctlsocket把套接字设置为非阻塞模式了。不过 你跟踪 一下就会发现，在没有数据的情况下，recv确实是马上返回了，但是也返回了一个错误：WSAEWOULDBLOCK，意思就是请求的操作没有成功完成。 看到这里很多人可能会说，那么就重复调用recv并检查返回值，直到成功为止，但是这样做效率很成问题，开销太大。 select模型的出现就是为了解决上述问题。 select模型的关键是使用一种有序的方式，对多个套接字进行统一管理与调度 。 ;函数原型： int select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); nfds: 整型变量，他比所有的文件描述符集合中的最大值大1（为什么大1，因为文件描述符从0开始计数，这里代表数量吧） readfds：文件描述符监视文件集合中的任何文件是否有数据可读，可以被recv()、read()等进行读数据操作 writefds:文件描述符监视文件集合中的任何文件是否有数据可写，可以被send()、write()等进行写数据操作 exceptfds：监视文件集中是否发生错误 timeout： 设置所监视的文件集合中的事件没有发生时，最长的等待时间;关于fd_set的一些说明 1. fd_set 结构体 fd_set是文件句柄的集合。 FD_ZERO 清空这个集合； FD_SET　往这个集合里面加入一个文件句柄； FD_ISSET 查看某一个文件句柄是否被设置了； fd_set 是一组文件描述符(fd)的集合。由于fd_set类型的长度在不同平台上不同，因此应该用一组标准的宏定义来处理此类变量： fd_set set; FD_ZERO(set); /* 将set清零 */ FD_SET(fd, set); /* 将fd加入set */ FD_CLR(fd, set); /* 将fd从set中清除 */ FD_ISSET(fd, set); /* 判断fd是否处于可用状态 是为true　*/ 关于select函数的具体用法，这里就不再阐述;select函数的优缺点;缺点：有两个很致命的缺点;poll()函数;poll函数优缺点：;对比select和poll，epoll具有以下这些优点： 1.支持一个进程打开大数目的socket描述符(FD) select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完 美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。 2.IO效率不随FD数目增加而线性下降 传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是活跃的， 但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对活跃的socket进行 操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有活跃的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个伪AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速L