说明
Acceptor 是 TcpServer的一部分, 用于接受Tcp连接,主要完成服务端的 create,bind, listen,accept这几个阶段。
成员变量
重点关注:
1. loop:主线程循环, 在主线程进行监听连接。
2.acceptSocket:监听套剪子的封装。
3. newConnectionCallback_: TCPServer的函数,用于监听到新连接回调。
4.idleFd: 解决accept出现EMFILE后的问题(文章最后整理)
EventLoop* loop_; //这个循环时主循环
Socket acceptSocket_; //监听套接字
Channel acceptChannel_; //通道,观察是否有连接请求
NewConnectionCallback newConnectionCallback_; //连接回调函数,如果有连接连上了,用这个函数处理连接套接字
bool listening_; //监听套接字是否处于监听状态
int idleFd_;
方法
1. Acceptor():构造函数,完成过create,bind这两个过程,并在channel中注册监听套接字的可读事件回调hangleRead。
Acceptor::Acceptor(EventLoop* loop, const InetAddress& listenAddr, bool reuseport)
: loop_(loop),
acceptSocket_(sockets::createNonblockingOrDie(listenAddr.family())), //创建socket并设置为非阻塞状态
acceptChannel_(loop, acceptSocket_.fd()),
listening_(false),
idleFd_(::open("/dev/null", O_RDONLY | O_CLOEXEC))
{
assert(idleFd_ >= 0);
acceptSocket_.setReuseAddr(true);
acceptSocket_.setReusePort(reuseport);
acceptSocket_.bindAddress(listenAddr); //绑定地址
acceptChannel_.setReadCallback(
std::bind(&Acceptor::handleRead, this));
}
2. listen:执行listen这个过程,同时让channel监听可读事件(原理就是往epoll上挂在监听套接字的可读事件)
//主要调用Socket::listen(),把listening_置为true,通道也开始监听读事件
void Acceptor::listen()
{
loop_->assertInLoopThread();
listening_ = true;
acceptSocket_.listen(); //开启监听
acceptChannel_.enableReading(); //往事件循环注册可读事件
}
3. handleRead:处理监听socket的可读事件,即新连接到来
接受一个新连接,并分配文件描述符,成功则调用回调函数即可(TcpServer注册的函数)。
接受失败见下文EMFILE错误解释。
// 监听socket有事件发生
// 调用Socket::accept()接受连接,连接成功的话,调用newConnectionCallback_()回调函数,处理这个连接,没有回调函数的话就直接关闭这个连接
// 如果连接失败,失败原因是文件描述符太多的话
void Acceptor::handleRead()
{
loop_->assertInLoopThread();
InetAddress peerAddr;
//FIXME loop until no more
int connfd = acceptSocket_.accept(&peerAddr);
if (connfd >= 0)
{
// string hostport = peerAddr.toIpPort();
// LOG_TRACE << "Accepts of " << hostport;
if (newConnectionCallback_)
{
newConnectionCallback_(connfd, peerAddr); //生成TCPConnection,并注册连接、断开、可读、写完成事件.
}
else
{
sockets::close(connfd);
}
}
else
{
LOG_SYSERR << "in Acceptor::handleRead";
// Read the section named "The special problem of
// accept()ing when you can't" in libev's doc.
// By Marc Lehmann, author of libev.
if (errno == EMFILE)
{
::close(idleFd_);
idleFd_ = ::accept(acceptSocket_.fd(), NULL, NULL);
::close(idleFd_);
idleFd_ = ::open("/dev/null", O_RDONLY | O_CLOEXEC);
}
}
Accept出现EMFILE错误问题分析
如何优雅的处理 accept 出现 EMFILE 的问题 - Linux开发那些事儿 - 博客园 (cnblogs.com)
总结博文:
- Listen阶段把所有已经完成三次握手的tcp连接放到全连接队列中,并通知应用层accept(),这时候可能出现EMFILE问题
- LT模式的EMFILE问题:由于 每次 accept 都失败了,相当于 listenfd 上的可读事件没有处理,epoll 会不停的触发 listenfd 上的可读事件,应用层也就会不停的调用 accept,然后又出现 accept 调用失败,如此这般不停的执行无效的循环,白白浪费了CPU的资源。
- ET模式的EMFILE问题:第一次accept失败后,由于没有处理可读事件,epoll不会再通知listenfd的可读事件了,后面新的连接到来也就不会通知了,也就无法接收新的客户端连接了。
解决方案:muduo的Acceptor handleRead做法
- 事先准备一个空闲的文件描述符 idlefd,相当于先占一个"坑"位
- 调用 close 关闭 idlefd,关闭之后,进程就会获得一个文件描述符名额
- 再次调用 accept 函数, 此时就会返回新的文件描述符 clientfd, 立刻调用 close 函数,关闭 clientfd
- 重新创建空闲文件描述符 idlefd,重新占领 "坑" 位,再出现这种情况的时候又可以使用
还有一种解决方案:ET模式下通常的做法是发生EMFILE之后epoll_ctl(...MOD...)一下监听套接字以便再次触发。也就是重新注册监听套接字的可读事件(当然没有上面的方案好,但也是一种思路)