在 linux 的网络编程中,很长的时间都在使用 select 来做事件触发。在 linux 新的内核中,有了一种替换它的机制,就是 epoll 。
相比于 select , epoll 最大的好处在于它不会随着监听 fd 数目的增长而降低效率。因为在内核中的 select 实现中,它是采用轮询来处理的,轮询的 fd 数目越多,自然耗时越多。并且,在 linux/posix_types.h 头文件有这样的声明:
#define __FD_SETSIZE 1024
表示 select 最多同时监听 1024 个 fd ,当然,可以通过修改头文件再重编译内核来扩大这个数目,但这似乎并不治本。
epoll 的接口非常简单,一共就三个函数:
1. int epoll_create(int size);
创建一个 epoll 的句柄, size 用来告诉内核这个监听的数目一共有多大。这个参数不同于 select() 中的第一个参数,给出最大监听的 fd+1 的值。需要注意的是,当创建好 epoll 句柄后,它就是会占用一个 fd 值,在 linux 下如果查看 /proc/ 进程 id/fd/ ,是能够看到这个 fd 的,所以在使用完 epoll 后,必须调用 close() 关闭,否则可能导致 fd被耗尽。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll 的事件注册函数,它不同与 select() 是在监听事件时告诉内核要监听什么类型的事件,而是在这里先注册要监听的事件类型。
第一个 参数是 epoll_create() 的返回值,
第二个 参数表示动作,用三个宏来表示:
EPOLL_CTL_ADD :注册新的 fd 到 epfd 中;
EPOLL_CTL_MOD :修改已经注册的 fd 的监听事件;
EPOLL_CTL_DEL :从 epfd 中删除一个 fd ;
第三个 参数是需要监听的 fd ,
第四个 参数是告诉内核需要监听什么事, struct epoll_event 结构如下:
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
events 可以是以下几个宏的集合:
EPOLLIN : 表示对应的文件描述符可以读(包括对端 SOCKET 正常关闭);
EPOLLOUT : 表示对应的文件描述符可以写;
EPOLLPRI : 表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR : 表示对应的文件描述符发生错误;
EPOLLHUP : 表示对应的文件描述符被挂断;
EPOLLET : 将 EPOLL 设为边缘触发 (Edge Triggered) 模式,这是相对于水平触发 (Level Triggered) 来说的。
EPOLLONESHOT : 只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个 socket 的话,需要再次把这个 socket 加入到 EPOLL 队列里
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待事件的产生,类似于 select() 调用。参数 events 用来从内核得到事件的集合, maxevents 告之内核这个events 有多大,这个 maxevents 的值不能大于创建 epoll_create() 时的 size ,参数 timeout 是超时时间(毫秒,0 会立即返回, -1 将不确定,也有说法说是永久阻塞)。该函数返回需要处理的事件数目,如返回 0 表示已超时。
从 man 手册中,得到 ET 和 LT 的具体描述如下
EPOLL 事件有两种模型:
Edge Triggered (ET) 边缘触发 只有数据到来,才触发,不管缓存区中是否还有数据。
Level Triggered (LT) 水平触发 只要有数据都会触发。
假如有这样一个例子:
1. 我们已经把一个用来从管道中读取数据的文件句柄 (RFD) 添加到 epoll 描述符
2. 这个时候从管道的另一端被写入了 2KB 的数据
3. 调用 epoll_wait(2) ,并且它会返回 RFD ,说明它已经准备好读取操作
4. 然后我们读取了 1KB 的数据
5. 调用 epoll_wait(2)......
Edge Triggered 工作模式:
如果我们在第 1 步将 RFD 添加到 epoll 描述符的时候使用了 EPOLLET 标志,那么在第 5 步调用 epoll_wait(2) 之后将有可能会挂起,因为剩余的数据还存在于文件的输入缓冲区内,而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第 5 步的时候,调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中,会有一个事件产生在 RFD句柄上,因为在第 2 步执行了一个写操作,然后,事件将会在第 3 步被销毁。因为第 4 步的读取操作没有读空文件输入缓冲区内的数据,因此我们在第 5 步调用 epoll_wait(2) 完成后,是否挂起是不确定的。 epoll 工作在 ET 模式的时候,必须使用非阻塞套接口,以避免由于一个文件句柄的阻塞读 / 阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用 ET 模式的 epoll 接口,在后面会介绍避免可能的缺陷。
i 基于非阻塞文件句柄
ii 只有当 read(2) 或者 write(2) 返回 EAGAIN 时才需要挂起,等待。但这并不是说每次 read() 时都需要循环读,直到读到产生一个 EAGAIN 才认为此次事件处理完成,当 read() 返回的读到的数据长度小于请求的数据长度时,就可以确定此时缓冲中已没有数据了,也就可以认为此事读事件已处理完成。
Level Triggered 工作模式
相反的,以 LT 方式调用 epoll 接口的时候,它就相当于一个速度比较快的 poll(2) ,并且无论后面的数据是否被使用,因此他们具有同样的职能。因为即使使用 ET 模式的 epoll ,在收到多个 chunk 的数据的时候仍然会产生多个事件。调用者可以设定 EPOLLONESHOT 标志,在 epoll_wait(2) 收到事件后 epoll 会与事件关联的文件句柄从epoll 描述符中禁止掉。因此当 EPOLLONESHOT 设定后,使用带有 EPOLL_CTL_MOD 标志的 epoll_ctl(2) 处理文件句柄就成为调用者必须作的事情。
然后详细解释 ET, LT:
LT(level triggered) 是 缺省 的工作方式 ,并且同时支持 block 和 no-block socket. 在这种做法中,内核告诉你一个文件描述符是否就绪了,然后你可以对这个就绪的 fd 进行 IO 操作。如果你不作任何操作,内核还是会继续通知你的,所以,这种模式编程出错误可能性要小一点。传统的 select/poll 都是这种模型的代表.
ET(edge-triggered) 是高速工作方式 ,只支持 no-block socket 。在这种模式下,当描述符从未就绪变为就绪时,内核通过 epoll 告诉你。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了 ( 比如,你在发送,接收或者接收请求,或者发送接收的数据少于一定量时导致了一个 EWOULDBLOCK 错误)。但是请注意,如果一直不对这个 fd 作 IO操作 ( 从而导致它再次变成未就绪 ) ,内核不会发送更多的通知 (only once), 不过在 TCP 协议中, ET 模式的加速效用仍需要更多的 benchmark 确认(这句话不理解)。
在许多测试中我们会看到如果没有大量的 idle -connection 或者 dead-connection , epoll 的效率并不会比select/poll 高很多,但是当我们遇到大量的 idle- connection( 例如 WAN 环境中存在大量的慢速连接 ) ,就会发现epoll 的效率大大高于 select/poll 。(未测试)
另外,当使用 epoll 的 ET 模型来工作时,当产生了一个 EPOLLIN 事件后,
读数据的时候需要考虑的是当 recv() 返回的大小如果等于请求的大小,那么很有可能是缓冲区还有数据未读完,也意味着该次事件还没有处理完,所以还需要再次读取:
while(rs)
{
buflen = recv(activeevents[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;
}
还有,假如发送端流量大于接收端的流量 ( 意思是 epoll 所在的程序读比转发的 socket 要快 ), 由于是非阻塞的socket, 那么 send() 函数虽然返回 , 但实际缓冲区的数据并未真正发给接收端 , 这样不断的读和发,当缓冲区满后会产生 EAGAIN 错误 ( 参考 man send), 同时 , 不理会这次请求发送的数据 . 所以 , 需要封装 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;
}