多路转接I/O select/poll/epoll高并发模型详解
多路转接I/O select/poll/epoll高并发模型详解
多路IO转接服务器也叫做多任务IO服务器。该类服务器实现的主旨思想是，不再由应用程序自己监视客户端连接，取而代之由内核替应用程序监视文件。
主要使用的方法有三种
select
1.select能监听的文件描述符个数受限于FD_SETSIZE,一般为1024，单纯改变进程打开的文件描述符个数并不能改变select监听文件个数
2.解决1024以下客户端时使用select是很合适的，但如果链接客户端过多，select采用的是轮询模型，会大大降低服务器响应效率。
#include void FD_CLR(int fd, fd_set *set); //把文件描述符集合里fd清0
int FD_ISSET(int fd, fd_set *set); //测试文件描述符集合里fd是否置1
void FD_SET(int fd, fd_set *set); //把文件描述符集合里fd位置1
void FD_ZERO(fd_set *set); //把文件描述符集合里所有位清0
返回值：
成功：所监听的 所有的监听集合中满足条件的总数
失败：-1 error
注：
select返回时会改变readfds/writefds/exceptfds的状态，因此需要保存一份readfds/writefds/exceptfds副本，以免阻碍下一次的监听。
优缺点：
优点：
支持跨平台
缺点：
1. 文件描述符上限-1024，即同时监听的文件描述符个数1024
2. 返回的是满足条件的总数，不能具体确定是哪一个文件描述符-for(int i = 1; i <=1024; i++)
-----解决办法：poll的思想
即自定义数据结构—数组，提高查找效率
3. 监听集合和满足监听条件的集合是同一个集合，因此需要将原有的监听集合保存。
server
/* server.c */
#include poll
#include epoll
epoll是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率，因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合，另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。
目前epell是linux大规模并发网络程序中的热门首选模型。
epoll除了提供select/poll那种IO事件的电平触发（Level Triggered）外，还提供了边沿触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。
可以使用cat命令查看一个进程可以打开的socket描述符上限。
cat /proc/sys/fs/file-max
如有需要，可以通过修改配置文件的方式修改该上限值。
sudo vi /etc/security/limits.conf
在文件尾部写入以下配置,`soft`软限制，`hard`硬限制。如下图所示。
* soft nofile 65536
* hard nofile 100000
基础API
1.创建一个epoll句柄，参数size用来告诉内核监听的文件描述符的个数，跟内存大小有关。
#include 2.控制某个epoll监控的文件描述符上的事件：注册、修改、删除。
#include 注：
epoll底层实现使用以下数据结构：
红黑树：将我们传递的信息封装成结构体，添加到红黑树上
双向链表：存放的是就绪的事件，即当调用epoll_wait返回时，将准备好的文件描述符所对应的结构体返回给用户
文件结构指针：指向epoll文件
server
#include client
/* client.c */
#include epoll进阶
事件模型
EPOLL事件有两种模型：
Edge Triggered (ET) 边缘触发只有数据到来才触发，不管缓存区中是否还有数据。
Level Triggered (LT) 水平触发只要有数据都会触发。
思考如下步骤：
1.假定我们已经把一个用来从管道中读取数据的文件描述符(RFD)添加到epoll描述符。
2.管道的另一端写入了2KB的数据
3.调用epoll_wait，并且它会返回RFD，说明它已经准备好读取操作
4.读取1KB的数据
5.调用epoll_wait……
在这个过程中，有两种工作模式：
ET模式
ET模式即Edge Triggered工作模式。
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，那么在第5步调用epoll_wait之后将有可能会挂起，因为剩余的数据还存在于文件的输入缓冲区内，而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第5步的时候，调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用ET模式的epoll接口，在后面会介绍避免可能的缺陷。
1)基于非阻塞文件句柄
2)只有当read或者write返回EAGAIN(非阻塞读，暂时无数据)时才需要挂起、等待。但这并不是说每次read时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。
LT模式
LT模式即Level Triggered工作模式。
与ET模式不同的是，以LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll，无论后面的数据是否被使用。
LT(level triggered)：LT是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。
ET(edge-triggered)：ET是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知。请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once).
实例一：
基于网络C/S非阻塞模型的epoll ET触发模式
server
/* server.c */
#include client
/* client.c */
#include 总结：
epoll模型
epoll—> 服务器 —> 监听 —>cfd—> 可读 —>epoll_wait返回 —>read()—> 处理逻辑 —>write()—>epoll继续监听epoll反应堆模型libevent库 核心思想实现
epoll—> 服务器 —> 监听 —>cfd—> 可读 —>epoll_wait返回 —>read()—> 将cfd从红黑树上摘下 —> 设置监听cfd写事件，修改操作(TCP中有一个滑动窗口机制) —> 处理逻辑 —> 等待epoll_wait返回 —>write()回写客户端 —> 将cfd从红黑树上摘下 —> 设置监听cfd读事件，修改操作 —>epoll继续监听- 在
epoll中用ert[i].events = EPOLLIN, evt[i].data.fd = cfd，而在epoll反应堆中将其改用为*ptr，*ptr指向一个结构体，即指向自己本身结构体。
struct
{
int fd;
void *arg;
void (*func)(void *arg); //此时参数arg指向自己本身的结构体
};
epoll反应堆反复的将cfd从红黑树上摘下的原因是：Tcp的滑动窗口机制。因为当客户端将滑动窗口填满时，此时相当于服务器端阻塞，不能将数据回写给客户端，因此，此时应判断客户端是否可写，若可写，再将数据回写给客户端。- 非阻塞使用
fcntl,open，open不适用与于套接字，因为套接字不是用open打开的。