linux-epoll研究
做linux网络编程的同学都清楚，2.6版本以前的linux内核大多都是用select作为非阻塞的事件触发模型，但是效率低，使用受限已经很明显的暴露了select（包括poll）的缺陷了，为了解决这些缺陷，epoll作为linux新的事件触发模型被创造出来。
一、epoll相对于select的优点：
1.支持一个进程socket描述符(FD)的最大数目
select支持的单进程socket描述符最大数目只有几千，而epoll支持的数目很大，等于系统最大打开的文件描述符数，这个文件描述符数跟内存有一定关系
2.IO效率不随FD数目增加而线性下降
select对事件的扫描是针对于所有创建的socket描述符进行的，也就是说，有多少个socket描述符，就需要遍历多少个句柄，所以IO效率是随描述符增加线性下降的；而epoll只遍历活跃的socket描述符，这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会。比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
3.使用mmap加速内核与用户空间的消息传递
select事件触发后会将信息从内核拷贝到用户空间，这种拷贝就影响了效率。而mmap将内核与用户空间的内存映射到一块内存上，内核将消息捕获后放入该内存空间，用户无需拷贝直接可以访问，减少了拷贝次数，提高了效率。
二、epoll工作模型
epoll事件有两种模型：
Edge Triggered (ET)，边缘触发是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。效率非常高，在并发，大流量的情况下，会比LT少很多epoll的系统调用，因此效率高。但是对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。
Level Triggered (LT)，水平触发是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。效率会低于ET触发，尤其在大并发，大流量的情况下。但是LT对代码编写要求比较低，不容易出现问题。LT模式服务编写上的表现是：只要有数据没有被获取，内核就不断通知你，因此不用担心事件丢失的情况。
三、值得注意的情况:
1.当使用epoll的ET模型来工作时，当产生了一个EPOLLIN事件后，读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：
while(rs) { buflen = recv(events[i].data.fd, buf, sizeof(buf), 0); if(buflen < 0) { // 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读 // 在这里就当作是该次事件已处理处. if(errno == EAGAIN) break; else return; } else if(buflen == 0) { // 这里表示对端的socket已正常关闭. } if(buflen == sizeof(buf) rs = 1; // 需要再次读取 else rs = 0; }
2.如果发送端流量大于接收端的流量，也就是说，epoll所在的程序读比转发的socket要慢，由于是非阻塞的socket，那么send()函数虽然返回，但实际缓冲区的数据并未真正发给接收端，这样不断的读和发，当缓冲区满后会产生EAGAIN错误(参考mansend)，同时，不理会这次请求发送的数据。所以，需要封装socket_send()的函数用来处理这种情况，该函数会尽量将数据写完再返回，返回-1表示出错。在socket_send()内部，当写缓冲已满(send()返回-1，且errno为EAGAIN)，那么会等待后再重试。这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部，但暂没有更好的办法。
ssize_t socket_send(int sockfd, const char* buffer, size_t buflen) { ssize_t tmp; size_t total = buflen; const char *p = buffer; while(1) { tmp = send(sockfd, p, total, 0); if(tmp < 0) { // 当send收到信号时,可以继续写,但这里返回-1. if(errno == EINTR) return -1; // 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满, // 在这里做延时后再重试. if(errno == EAGAIN) { usleep(1000); continue; } return -1; } if((size_t)tmp == total) return buflen; total -= tmp; p += tmp; } return tmp; }
四、实例
#include <iostream> #include <sys/socket.h> #include <sys/epoll.h> #include <netinet/in.h> #include <arpa/inet.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> using namespace std; #define MAXLINE 5 #define OPEN_MAX 100 #define LISTENQ 20 #define SERV_PORT 5000 #define INFTIM 1000 //设置非阻塞 void setnonblocking(int sock) { int opts; opts = fcntl(sock, F_GETFL); if(opts<0) { perror("fcntl(sock,GETFL)"); exit(1); } opts = opts|O_NONBLOCK; if(fcntl(sock,F_SETFL,opts)<0) { perror("fcntl(sock,SETFL,opts)"); exit(1); } } int main() { int i, maxi, listenfd,connfd, sockfd,epfd,nfds; ssize_t n; char line[MAXLINE]; socklen_t clilen; //声明epoll_event结构体的变量,ev用于注册事件,数组用于回传要处理的事件 struct epoll_event ev, events[20]; //生成用于处理accept的epoll专用的文件描述符 epfd = epoll_create(256); struct sockaddr_in clientaddr; struct sockaddr_in serveraddr; listenfd = socket(AF_INET, SOCK_STREAM, 0); //把socket设置为非阻塞方式 //setnonblocking(listenfd); //设置与要处理的事件相关的文件描述符 ev.data.fd = listenfd; //设置要处理的事件类型ET ev.events = EPOLLIN|EPOLLET; //ev.events=EPOLLIN; //注册epoll事件 epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev); bzero(&serveraddr, sizeof(serveraddr)); serveraddr.sin_family = AF_INET; char *local_addr="127.0.0.1"; inet_aton(local_addr,&(serveraddr.sin_addr));//htons(SERV_PORT); serveraddr.sin_port=htons(SERV_PORT); bind(listenfd,(sockaddr *)&serveraddr, sizeof(serveraddr)); listen(listenfd, LISTENQ); maxi = 0; for ( ; ; ) { //等待epoll事件的发生 nfds = epoll_wait(epfd, events, 20, 500); //处理所发生的所有事件 for(i = 0; i < nfds;++i) { if(events[i].data.fd == listenfd) { connfd = accept(listenfd, (sockaddr *)&clientaddr, &clilen); if(connfd < 0){ perror("connfd<0"); exit(1); } //setnonblocking(connfd); char *str = inet_ntoa(clientaddr.sin_addr); cout << "accapt a connection from " << str << endl; //设置用于读操作的文件描述符 ev.data.fd = connfd; //设置用于注测的读操作事件 ev.events = EPOLLIN|EPOLLET; //ev.events=EPOLLIN; //注册ev epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev); } else if(events[i].events&EPOLLIN) { cout << "EPOLLIN" << endl; if ( (sockfd = events[i].data.fd) < 0) continue; if ( (n = read(sockfd, line, MAXLINE)) < 0){ if (errno == ECONNRESET) { close(sockfd); events[i].data.fd = -1; } else std::cout<<"readline error"<<std::endl; } else if (n == 0) { close(sockfd); events[i].data.fd = -1; } line[n] = '\0'; cout << "read " << line << endl; //设置用于写操作的文件描述符 ev.data.fd = sockfd; //设置用于注册的写操作事件 ev.events = EPOLLOUT|EPOLLET; //修改sockfd上要处理的事件为EPOLLOUT //epoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &ev); } else if(events[i].events&EPOLLOUT) { sockfd = events[i].data.fd; write(sockfd, line, n); //设置用于读操作的文件描述符 ev.data.fd = sockfd; //设置用于注测的读操作事件 ev.events = EPOLLIN|EPOLLET; //修改sockfd上要处理的事件为EPOLIN epoll_ctl(epfd, EPOLL_CTL_MOD, sockfd, &ev); } } } return 0; }
上面的代码是ET模式
测试脚本1：
#!/usr/bin/python import socket import time sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(('127.0.0.1', 5000)) sock.send('1234567890') time.sleep(5)while(1): time.sleep(1)
输出1：
accapt a connection from 0.0.0.0 EPOLLIN read 12345
说明1：
运行server和client发现，server仅仅读取了5字节的数据，而client其实发送了10字节的数据，也就是说，server仅当第一次监听到了EPOLLIN事件，由于没有读取完数据，而且采用的是ET模式，状态在此之后不发生变化，因此server再也接收不到EPOLLIN事件了。当关闭客户端时，会另外触发一个事件，这个事件又触发了一次读操作，也就将后面的5个字节读取出来。
测试脚本2：
#!/usr/bin/python import socket import time sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(('127.0.0.1', 5000)) sock.send('1234567890') time.sleep(5) sock.send('1234567890') while(1): time.sleep(1)
输出2：
accapt a connection from 0.0.0.0 EPOLLIN read 12345 (5 sec...) EPOLLIN read 67890
说明2：
可以发现，在server接收完5字节的数据之后一直监听不到client的事件，而当client休眠5秒之后重新发送数据，server再次监听到了变化，只不过因为只是读取了5个字节，仍然有10个字节的数据(client第二次发送的数据)没有接收完。
如果上面的实验中，对accept的socket都采用的是LT模式，那么只要还有数据留在buffer中，server就会继续得到通知，可以将上面标黄的选项去掉则变为LT模式。
五、总结
ET模式仅当状态发生变化的时候才获得通知，这里所谓的状态的变化并不包括缓冲区中还有未处理的数据，也就是说，如果要采用ET模式，需要一直read/write直到出错为止，很多人反映为什么采用ET模式只接收了一部分数据就再也得不到通知了，大多是这个原因造成的；而LT模式是只要有数据没有处理就会一直通知下去的。
补充说明一下这里一直强调的"状态变化"是什么:
1)对于监听可读事件时，如果是socket是监听socket，那么当有新的主动连接到来为状态发生变化；对一般的socket而言，协议栈中相应的缓冲区有新的数据为状态发生变化。但是，如果在一个时间同时接收了N个连接(N>1)，但是监听socket只accept了一个连接，那么其它未 accept的连接将不会在ET模式下给监听socket发出通知，此时状态不发生变化；对于一般的socket，就如例子中而言，如果对应的缓冲区本身已经有了N字节的数据，而只取出了小于N字节的数据，那么残存的数据不会造成状态发生变化。
2)对于监听可写事件时，同理可推，不再详述。
不论是监听可读还是可写，对方关闭socket连接都将造成状态发生变化，比如在例子中，如果强行中断client脚本，也就是主动中断了socket连接，那么都将造成server端发生状态的变化，从而server得到通知，将已经在本方缓冲区中的数据读出。
把前面的描述可以总结如下：仅当对方的动作(发出数据,关闭连接等)造成的事件才能导致状态发生变化，而本方协议栈中已经处理的事件(包括接收了对方的数据，接收了对方的主动连接请求)并不是造成状态发生变化的必要条件，状态变化一定是对方造成的。所以在ET模式下的，必须一直处理到出错或者完全处理完毕，才能进行下一个动作，否则可能会发生错误。
部分转自他处-没有找到最终来源
