boost asio ——深入框架

要用好它，就必须先了解它，而且不能停止于表面，必须深入到内部。而了解一件事物，先要了解它的框架，再了解它的细节。了解了框架，我们就有了提纲挈领的认识。

关于 boost asio 框架结构，在其文档中，用了这样一张图来描述：

 

简单解释一下：

这里由使用者（Initiator）启动一个异步操作（Asynchronous Operation），在启动异步的同时它要负责创建一个异步回调对象（Completion Handler），然后该异步操作被交给了异步操作执行者（Asynchronous Operation Processor），由它负责执行异步操作，并在完成后将一个完成事件插入完成事件队列（Completion Event Queue）；另一方面，前摄器（Proactor，这个词很难准确翻译，也有翻译为主动器，可能借义于proactive）驱动异步事件分派器（Asynchronous Event Demultiplexer）从完成事件队列中获取事件，这是一个阻塞的过程，一旦获取到完成事件，前摄器从事件上找出与该事件关联的回调对象，并执行回调。

这是一个标准的前摄器模式，这个模式是在 ACE 网络库中使用的概念。关于该模式的研究很多，搜索一下 ACE Proactor 就可以找到很多资料。上面的描述也比较容易理解，唯一比较难搞懂的是异步事件分派器（Asynchronous Event Demultiplexer），好像它的存在并不起多大作用，其实它的作用大着呢，特别是在多线程中，它要保证异步完成事件的及时分派，提高多线程并发度，以及降低线程切换开销。在 windows 完成端口的文档中有这方面的机制介绍。

总得来说，这是一个概念性的模型，仅用这个模型来描述 boost asio，根本体现不了 boost asio 的优点。即使从使用者的角度，仅掌握这样的模型也是不够，boost asio 还有很多值得学习借鉴的地方。

我们需要结合这个模型来深入 boost asio 的实现框架。

 boost asio 是如何实现前摄器模式的呢？我们使用 boost asio 第一步都需要创建一个 boost::asio::io_service，我们就从 io_service 开始开启我们的探秘之旅。

 io_service 类的定义很简单，总共就三个成员变量：

#if defined(BOOST_WINDOWS) || defined(__CYGWIN__)
  detail::winsock_init<> init_;
#elif defined(__sun) || defined(__QNX__) || defined(__hpux) || defined(_AIX)
  || defined(__osf__)
  detail::signal_init<> init_;
#endif

  // The service registry.
  boost::asio::detail::service_registry* service_registry_;

  // The implementation.
  impl_type& impl_;

其实简单反而意味着强大，因为这表明 boost asio 已经把功能结构划分的很清晰了。

三个成员变量中的 init_ 与结构没有太大关系，windows 平台的 winsock_init 里面调用了 WSAStartup，linux 平台的 signal_init 里面屏蔽了 SIG_PIPE 信号。这两个东东几乎是在我们刚开始接触网络编程就遇到的知识点。

其次我们再来看看 impl_ 成员，从名字上看应该是 io_service 的实现类，确实 io_service 的很多接口是直接转发给了 impl_ 成员，比如 run、poll、stop、reset、post、dispatch

inline std::size_t io_service::run(boost::system::error_code& ec)
{
  return impl_.run(ec);
}
inline std::size_t io_service::poll(boost::system::error_code& ec)
{
  return impl_.poll(ec);
}
inline void io_service::stop()
{
  impl_.stop();
}

inline void io_service::reset()
{
  impl_.reset();
}

template <typename Handler>
inline void io_service::dispatch(Handler handler)
{
  impl_.dispatch(handler);
}

template <typename Handler>
inline void io_service::post(Handler handler)
{
  impl_.post(handler);
}

但是 impl_type 是什么呢？它的定义如下：

#if defined(BOOST_ASIO_HAS_IOCP)
  typedef detail::win_iocp_io_service impl_type;
#elif defined(BOOST_ASIO_HAS_EPOLL)
  typedef detail::task_io_service<detail::epoll_reactor<false> > impl_type;
#elif defined(BOOST_ASIO_HAS_KQUEUE)
  typedef detail::task_io_service<detail::kqueue_reactor<false> > impl_type;
#elif defined(BOOST_ASIO_HAS_DEV_POLL)
  typedef detail::task_io_service<detail::dev_poll_reactor<false> > impl_type;
#else
  typedef detail::task_io_service<detail::select_reactor<false> > impl_type;
#endif

原来是根据不同的平台支持特性，选择了不同的实现，要把这么多种实现融合起来，没有一个很好的架构是很难做到的。

我们再来看看 service_registry_，对这个成员变量的使用体现在 use_service、add_service、has_service 三个函数中：

template <typename Service>
inline Service& use_service(io_service& ios)
{
  // Check that Service meets the necessary type requirements.
  (void)static_cast<io_service::service*>(static_cast<Service*>(0));
  (void)static_cast<const io_service::id*>(&Service::id);

  return ios.service_registry_->template use_service<Service>();
}

template <typename Service>
void add_service(io_service& ios, Service* svc)
{
  // Check that Service meets the necessary type requirements.
  (void)static_cast<io_service::service*>(static_cast<Service*>(0));
  (void)static_cast<const io_service::id*>(&Service::id);

  if (&ios != &svc->io_service())
    boost::throw_exception(invalid_service_owner());
  if (!ios.service_registry_->template add_service<Service>(svc))
    boost::throw_exception(service_already_exists());
}

template <typename Service>
bool has_service(io_service& ios)
{
  // Check that Service meets the necessary type requirements.
  (void)static_cast<io_service::service*>(static_cast<Service*>(0));
  (void)static_cast<const io_service::id*>(&Service::id);

  return ios.service_registry_->template has_service<Service>();
}

看起来是个集合容器，里面的元素是服务（Service），服务有编号（id）。从 service_registry 的实现可以进一步了解到下面细节：

1. 服务都是用一个类来实现的，唯一的接口要求是必须有 shutdown_service 接口
2. 服务是延迟创建的，只有第一次被使用的时候才创建
3. 每种类型的服务在同一个 service_registry （也是同一个io_service）里面最多只有一个实例
4. 当service_registry （也就是io_service）被销毁（析构）时，服务会被 shutdown ，然后被销毁

 继续分析每个服务，还可以看到服务有下列特性：

1. 服务在构造后就开始运作
2. 服务在 shutdown 后停止运作
3. 服务通过句柄（implementation_type）对外暴露其功能
4. 服务之间有依赖性

最后，总结出所有的服务大概分为三类：

第一类服务是底层系统服务，是对操作系统平台提供功能的封装，有：

• detail::win_iocp_io_service
• detail::win_iocp_socket_service
• detail::task_io_service
• detail::reactive_socket_service

• detail::epoll_reactor
• detail::kqueue_reactor
• detail::dev_poll_reactor
• detail::select_reactor

• detail::resolver_service

中间四个都是 reactor，不能想象，所有的 reactor 应该有相同的对外服务接口。这里的 task_io_service 和 reactive_socket_service 是对 reactor 的再封装，所以上层的服务不会直接依赖 reactor，而是依赖 task_io_service 和 reactive_socket_service。

第二类服务是上层接口服务，面向具体的功能对象（Object），他们会针对运行平台选择依赖对应的底层服务

• socket_acceptor_service（ip::basic_socket_acceptor -> ip::tcp::acceptor）
• stream_socket_service（ip::basic_stream_socket -> ip::tcp::socket）
• datagram_socket_service（ip::basic_datagram_socket -> ip::udp::socket）
• raw_socket_service（ip::basic_raw_socket -> ip::icmp::socket）
• deadline_timer_service（basic_deadline_timer -> deadline_timer）
  • detail::deadline_timer_service
• ip::resolver_service（ip::basic_resolver -> ip::tcp::resolver, ip::udp::resolver, ip::icmp::resolver）

 前四个 socket 相关的服务会在不同的平台，选择依赖 win_iocp_socket_service 和 reactive_socket_service<xxx_reactor>，deadline_timer_service （具体实现在

detail::deadline_timer_service中）会选择 win_iocp_io_service 和 task_io_service<xxx_reactor>，ip::resolver_service 没得选择，只有依赖 detail::resolver_service。

第三类服务是一些特殊功能的服务，比如 detail::strand_service 等，他们对整体框架没有影响。

虽然 boost asio 中提供了这么多服务，但是上层应用并不会直接使用这些服务，服务通过句柄对外暴露其功能，而句柄被功能对象（Object）封装，然后提供给上层应用使用。

这里的功能对象（Object），就是我们在第二类服务后面的“（）”里面给出的类，每个对象都包含着一个对相应服务的C++引用，以及服务对外暴露的句柄。

至此，我们了解了 boost asio 中通过一系列的服务封装了操作系统的底层功能，并且通过动态组装的方式把这些服务管理起来。可以看出，boost asio 使用了一种相当简单的方式，就解决了平台的多样性，甚至于模式的多样性；同时服务的动态加载和集中管理，为功能扩展提供了方便途径；另外对象中只包含句柄，提高了安全性。

再回过头来看看，我们心中还有个疑问，那就是 boost asio 是怎么实现前摄器（Proactor）模式的呢？其实前摄器（Proactor）的各个角色都是通过服务来表达的。

先看 windows 平台

Asynchronous Operation Processor 的功能是由 win_iocp_socket_service、resolver_service 完成，Proactor 功能由 win_iocp_io_service 完成，win_iocp_io_service 也包含 Asynchronous Event Demultiplexer 和 Completion Event Queue 的功能，不过其实是对 windows IOCP 的系统功能的封装。

再看看 linux 平台

Asynchronous Operation Processor 的功能是由 reactive_socket_service、resolver_service 完成，Proactor、Asynchronous Event Demultiplexer 和 Completion Event Queue功能都是由 task_io_service 完成。

最后，io_service 其实代表了Proator 这一端，socket、timer、resolver 等等代表了 Initiator 这一端。这就是上层使用者角度看到的景象。