muduo源码剖析 - Acceptor

说明

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)

总结博文：

1. Listen阶段把所有已经完成三次握手的tcp连接放到全连接队列中，并通知应用层accept()，这时候可能出现EMFILE问题
2. LT模式的EMFILE问题：由于 每次 accept 都失败了，相当于 listenfd 上的可读事件没有处理，epoll 会不停的触发 listenfd 上的可读事件，应用层也就会不停的调用 accept，然后又出现 accept 调用失败，如此这般不停的执行无效的循环，白白浪费了CPU的资源。
3. ET模式的EMFILE问题：第一次accept失败后，由于没有处理可读事件，epoll不会再通知listenfd的可读事件了，后面新的连接到来也就不会通知了，也就无法接收新的客户端连接了。

解决方案：muduo的Acceptor handleRead做法

• 事先准备一个空闲的文件描述符 idlefd，相当于先占一个"坑"位
• 调用 close 关闭 idlefd，关闭之后，进程就会获得一个文件描述符名额
• 再次调用 accept 函数, 此时就会返回新的文件描述符 clientfd, 立刻调用 close 函数，关闭 clientfd
• 重新创建空闲文件描述符 idlefd，重新占领 "坑" 位，再出现这种情况的时候又可以使用

还有一种解决方案：ET模式下通常的做法是发生EMFILE之后epoll_ctl(...MOD...)一下监听套接字以便再次触发。也就是重新注册监听套接字的可读事件（当然没有上面的方案好，但也是一种思路）