boost.asio为异步IO提供了一份标准的C++的跨平台实现，特别针对网络IO提供了良好的支持，使之成为C++网络编程利器。关于如何使用asio，boost文档中已经有了详尽说明，而且附带的例子也很直观，我们不必再造轮子；本文则结合asio的基本应用，侧重于源代码的分析，特别是针对windows平台上的实现进行分析。
纵观asio源码，在统一的接口层之下，asio提供了大量的类来支持不同的平台（Windows、Unix...）、不同的IO类型（同步、异步）及IO模型（IOCP、Select、Poll）及网络协议（TCP，UDP，ICMP）。归纳起来，这一大堆类可以分为三层，分别是：
- IO Object层
- basic_ 模版层
- 服务实现层
本系列文章从io_service类型入手，开启代码分析行程，采用自底向上的方法，逐层推导，最后得到asio的体系结构；如果想先了解asio的整体结构，可以先跳到asio体系结构部分。
（理论上来说，行文伊始还是该先举个简单的例子说一下asio如何使用，不过这样的例子少说也要六七十行代码，为节约篇幅就不贴了；真想先看一个完整例子的，烦请移步下面链接瞧下那只麻雀：http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/tutorial/tutdaytime3/src.html）
·io_service类
从第一个boost.asio的教程开始，boost文档就一直在告诉我们：使用boost.asio第一步就是要创建一个io_service对象。那么io_service是个什么东西呢？
boost.asio文档说，io_service为下面的这些异步IO对象提供最核心的IO功能：
- boost::asio::ip::tcp::socket
- boost::asio::ip::tcp::acceptor
- boost::asio::ip::udp::socket
- deadline_timer.
接着，文档就会说，像下面这样，就可以简简单单声明一个io_service对象了：
| int main() { boost::asio::io_service io; |
上面的一行代码，表明无限地风光与潇洒，看起来简简单单一行，就几乎有了异步IO、网络操作的框架，那么他到底代表了什么，在后面，又有什么事情发生呢？io_service又是如何支撑起这些功能的呢？带着这些问题，我们开始分析吧……
从C++的角度看，上面的这一行代码，无非就是定义了一个io_service的实例，而C++的底层机制所隐藏起来的东西，无非就是初始化该对象的所有数据成员。再来看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_; |
暂时抛开那几个成员，再来看一下io_service比较重要的一个函数：run() 的实现，发现该函数也就是将真正的功能委托给成员impl_去做事儿了：
| std::size_t io_service::run() { boost::system::error_co std::size_t s = impl_.run(ec); boost::asio::detail::throw_error(ec); return s; } |
种种迹象表明，impl_是个巨牛的东西了。统揽io_service的实现，我们不难发现，该类的所有功能，几乎都是委托给了impl_成员去干了——典型的“有事秘书干”。不过想想也挺容易理解的，io_service提供了一个上层的接口，充当抛头露面的BOSS，真正的工作则委托给下一层的员工去实现——哪家公司不是这样呢？
所以，要想了解io_service的玄机，就需要弄清楚这三个数据成员到底是什么来历，特别是impl_的来历才行。
io_service的初始化
成员 init_ 在io_service的各个函数中，并没有显式用到。其存在的价值，就在于该类的构造函数里面，调用了初始化相关的代码，具体到Windows平台，就是WinSock的初始化，也就是调用 ::WSAStartup() 这一WinSock编程所必须调用的第一个函数；而其析构函数则进行清理工作，同样交由WinSock函数 :: WSACleanup() 完成。
也就是说，io_service通过init_数据成员的创建与销毁，自动完成了相关的初始化及清理工作。
io_service的实现委托
前面说过，impl_ 带着无限的神秘默默地完成了io_service::run()的功能。至于他到底是什么style，现在来揭开盖头吧。
从直接声明来看，impl_ 具有 impl_type& 类型。用SourceInsight不难发现该类型只不过是一个类型别名：
typedef detail::io_service_impl impl_type;
一波未平一波又起，这儿又冒出个io_service_impl。继续刨根问底，找到：
#if defined(BOOST_ASIO_HAS_IOCP)
namespace detail { typedef win_iocp_io_service io_service_impl; }
#else
namespace detail { typedef task_io_service io_service_impl; }
#endif
终于知道，在某些情况下，它是 win_iocp_ ,在某些情况下，是 task_ 。事实上，在Win NT 环境下,如果没有禁用IOCP，也就是没有声明 BOOST_ASIO_DISABLE_IOCP 这个预处理器指令，那么asio就采用 win_iocp_io_service 来做那些脏活累活；在剩下的其他平台，或者Win上禁用了IOCP，则使用 task_io_service 来做事儿了。
先稍微提一下，win_iocp_io_service 是对Windows环境下的IOCP（完成端口IO）模型的封装，该类作为boost.asio在Windows下的核心，我们在后面详细分析其实现。
io_service的服务管理
io_service的另外一个数据成员 service_registry_，又具备什么样的身份和功能呢？我们来看看 io_service 的构造函数：
| io_service::io_service() : service_registry_ ( new boost::asio::detail::service_registry( *this, static_cast<impl_type*>(0), (std::numeric_limits<std::size_t>::max)() ) ), impl_(service_registry_->first_service<impl_type>()) { } |
构造函数为了初始化service_registry_，动态分配了一个boost::asio::detail:: service_registry类对象。为了构造该对象，提供了三个参数：
- *this， 这个是io_service对象本身，作为所有服务的owner存在。
- static_cast<impl_type*>(0)，一个空指针对象，主要是为了模版参数类型推导。在service_registry的构造过程中，也会自动创建一个该类型的对象，作为第一个service对象。具体到Win平台，即为构造一个 win_iocp_io_service 对象。
- (std::numeric_limits<std::size_t>::max)()：提供一个最大的整数作为service构造时的参数——目前还没看到这个参数的用途。
再来观察service_registry的实现，发现其实际就是一个链表，管理io_service所容纳的所有service对象（win_iocp_io_service就是一种service）。每种service都有一个id，链表以此id作为标志，在客户通过io_service来请求一种服务时，例如调用 use_service<ServiceType>(io_service&) 时，service_registry会查找链表，如果有对应类型的服务，就返回该类型服务实例的指针；否则就创建一个新的对象，并加入到链表末端，再返回此新创建的实例；通过这种形式，io_service确保每种类型的服务都只有一个实例存在。
asio提供了这样几个函数，来进行service的管理和使用——这也为扩展asio提供了可能，例如可以自己定义一种服务，使用add_service加入io_service进行管理。
- template <typename Service>
Service& use_service(io_service& ios);
- template <typename Service>
void add_service(io_service& ios, Service* svc);
- template <typename Service>
bool has_service(io_service& ios);
io_service::service类型及跨平台策略
|
|
|
|
|
|
| boost::asio::io_service |
| |
|
|
| class boost::asio::io_service::::id |
|
|
|
|
| |
|
| class boost::asio::io_service::work |
| |
|
|
|
| |
|
| enum boost::asio::io_service::fork_event |
| |
|
|
|
| |
|
| class boost::asio::io_service::strand |
| |
|
|
|
| |
|
| class boost::asio::io_service::service |
| |
|
|
|
|
|
io_service内部定义了这样一些类型，来为其服务:
- io_service::id，所有service具体类的标识
- io_service::service,所有service具体类的基类
- io_service::strand,对所有并发提交的hanlder串行化执行
- io_service::work，通知io_service有事儿要干的类，有点令人讨厌的主儿
- io_service::fork_event，fork事件通知
针对service类型，asio从其派生出了数十个类分别完成不同的功能，例如在Win上充当io_service的win_iocp_io_service类，以及为各种IO Object类型提供服务的类，如对应于TCP的stream_socket_service，对应于UDP的datagram_socket_ service。下图显示了asio常用到的服务类，及其针对不同平台的适配类之间的关系。
图中左边的类，会在我们的应用程序中直接用到（由于asio又对这些类提供了一层动态组装，所以代码中不会去直接声明这些类型的实例，但是剥掉动态组装的外衣，我们声明的仍然是这些类的实例，具体在下面一部分说明），作为 应用层 的类；而右边部分，则是针对不同平台所提供的不同实现，作为 平台适配层。
应用层类在编译时，根据所在平台（其实是喂给编译器的各种预处理宏，如BOOST_ASIO_ HAS_IOCP），选择对应的类进行编译。例如用于TCP的服务类stream_socket_service是这样进行选择的：
template <typename Protocol>
class stream_socket_service
{
private:
// The type of the platform-specific implementation.
#if defined(BOOST_ASIO_HAS_IOCP)
typedef detail::win_iocp_socket_service<Protocol> service_impl_type;
#else
typedef detail::reactive_socket_service<Protocol> service_impl_type;
#endif
// The platform-specific implementation.
service_impl_type service_impl_;
…
};
其他需要进行平台决策的类型，都是采用这种技术，来选择不同的实现的。
从io_service::service派生的完整的类列表如下：
- boost::asio::detail::win_iocp_io_service
- boost::asio::detail::task_io_service
- boost::asio::detail::select_reactor
- boost::asio::detail::epoll_reactor
- boost::asio::detail::dev_poll_reactor
- boost::asio::detail::kqueue_reactor
- boost::asio::ip::resolver_service
- boost::asio::socket_acceptor_service
- boost::asio::stream_socket_service
- boost::asio::datagram_socket_service
- boost::asio::raw_socket_service
- boost::asio::seq_packet_socket_service
- boost::asio::serial_port_service
- boost::asio::signal_set_service
- boost::asio::deadline_timer_service
- boost::asio::waitable_timer_service
- boost::asio::detail::strand_service
- boost::asio::posix::stream_descriptor_service
- boost::asio::ssl::old::context_service
- boost::asio::ssl::old::stream_service
- boost::asio::ssl::old::detail::openssl_context_service
- boost::asio::ssl::old::detail::openssl_stream_service
- boost::asio::windows::object_handle_service
- boost::asio::windows::random_access_handle_service
- boost::asio::windows::stream_handle_service
还有几个非常重要的类，他们作为劳苦大众在金字塔底层默默提供service功能，但却没有从io_service::service派生；他们是上述那些服务类在各个平台的具体实现，为金字塔中间层的服务类提供再服务的（不难想象，提供服务的方式，又是那种“有事儿秘书干”的方式）：
- boost::asio::detail::win_iocp_socket_service
- boost::asio::detail::win_iocp_handle_service
- boost::asio::detail::reactive_descriptor_service
- boost::asio::detail::reactive_serial_port_service
- boost::asio::detail::reactive_socket_service
- boost::asio::detail::win_iocp_serial_port_service
- boost::asio::detail::win_object_handle_service
·io objects
asio的文档，告诉我们在声明一个io_service对象之后，就可以创建io对象去干活了，例如：
| int main(int argc, char* argv[]) { boost::asio::io_service io_service;
tcp::resolver resolver(io_service); tcp::resolver::query query("www.boost.org", "80"); tcp::resolver::iterator iterator = resolver.resolve(query);
|
上图中main()的第二行代码声明了一个tcp::resolver对象，后续进行地址解析的逻辑，都是围绕此resolver对象展开的。那么这个resolver是一个什么样的类型呢？阅读源代码我们在boost::asio::ip::tcp类内部看到了这样的类型别名定义：
typedef basic_resolver<tcp> resolver;
是否似曾相识呢？ 是的，这和我们STL中的string, iostream等一样，使用的都是某个模板类的一个实例。这里的resolver是basic_resolver在tcp模版参数下的实例，string是basic_string在char模版参数下的实例——boost库和STL库统一风格的一个体现。
asio大量采用这种技术，所有和resolver一样提供io功能的类，都是某个baisc_ 模版类的实例化。下面我们来研究一下asio的io object逻辑。
io object 类关系网
继续向上追溯basic_resolver，知道该类从basic_io_object派生，主要负责地址解析相关的操作，提供的主要接口有resolver(), async_resolve()等。
查看整个asio的源代码，我们发现从basic_io_object派生的类不少，他们分别负责一些具体的事务，例如basic_socket_acceptor可以作为一个服务器进行侦听，提供了诸如bind(), listen()等接口；再如basic_socket类是对socket IO 操作的封装，提供了receive(), async_receive(), read_some(), async_readsome(), write_some(), async_write_some()等接口。
整个asio中的io object关系网，我们用下图来显示：
这些io object的功能，简述如下：
- basic_deadline_timer 提供定时器功能，可以同步等待，也可以异步等待。
- basic_waitable_timer 和basic_deadline_timer具有同样的功能，主要区别为该定时器可以和C++ 11中引入的chrono库协作。
- basic_signal_set 支持信号相关的操作，异步方式等待单个或者多个信号的发生。
- basic_socket_acceptor 作为服务器进行侦听，接收连接请求。
- basic_serial_port 对串口操作进行支持。
- basic_resolver 地址解析类。
- basic_stream_socket 提供同步、异步方式的基于流的socket操作。
- basic_datagram_socket 提供同步、异步方式的基于数据报文的socket操作。
- basic_raw_socket提供同步、异步方式的基于raw数据的socket操作
- basic_seq_packet_socket提供同步、异步方式的基于有序包的socket操作
- basic_socket_streambuf ?
- basic_object_handle 对windows handle的封装，可以以异步或者同步方式等待
- basic_random_access_handle对windows 可随机访问的handle的封装，可以以异步或者同步方式等待
- basic_stream_handle对windows面向流handle的封装，可以以异步或者同步方式等待
- basic_descriptor 对POSIX描述符进行封装。
另外一点，所有这些io object的构造函数，都要求有一个io_service& 作为参数，使用这一参数，这些io_object对象知道了自己的归属，之后自己所要派发出去的同步、异步操作请求，都将通过自己所在的这个io_service对象来完成。这也就说明了，为什么创建io_service对象是整个asio程序的第一步。
io object服务委托
上述的这些io object类，提供了应用开发中常用的各种“实际”功能，例如地址解析，以及socket读写等，那么这些io object类和第一部分中的service类之间存在着什么样的关系呢？ 会不会是这些io object只是一个应用的接口，而具体的功能则委托给service类来完成呢？ 如果是这样的，那么又是如何实现的呢？
带着这些问题，我们继续研究resolver类的源代码，看看他所提供的功能，到底是如何实现的。
resolver是如何委托的
我们知道，resolver类是在boost::asio::ip::tcp类中的一个类型别名：
typedef basic_resolver<tcp> resolver;
那么，resolver类所提供的async_resolve()接口，就来自于basic_resolver类。再来看看basic_resolver::async_resolve()的实现——该函数有两个重载，我们以其中一个为例：
| template <typename ResolveHandler> void async_resolve(const query& q, BOOST_ASIO_MOVE_ARG(ResolveHandler) handler) { // If you get an error on the following line it means that your handler does // not meet the documented type requirements for a ResolveHandler. BOOST_ASIO_RESOLVE_HANDLER_CHECK( ResolveHandler, handler, iterator) type_check;
return this->service.async_resolve(this->implementation, q, BOOST_ASIO_MOVE_CAST(ResolveHandler)(handler)); } |
可见，async_resolve()果然是委托给了某个service类来做事的——再一次，典型的有事儿秘书干。那么，这儿的“this->service” 又是什么呢？
通过跟踪代码的执行，知道该service其实是第一部分曾经提到过的boost::asio::ip::resolver_service，而它又委托给了boost::asio::detail::resolver_service——这家伙再无其他可以委托的对象了，只有苦逼的自己做事儿了——其基本思路就是先创建一个用以地址解析的resolve_op，用这个op来代表本次异步操作，之后启动op去做事情。至于op又是什么东西，稍后在operation部分做介绍；先贴出这段苦主：
| // boost::asio::detail::resolver_service template <typename Handler> void async_resolve(implementation_type& impl, const query_type& query, Handler handler) { // Allocate and construct an operation to wrap the handler. typedef resolve_op<Protocol, Handler> op; typename op::ptr p = { boost::addressof(handler), boost_asio_handler_alloc_helpers::allocate( sizeof(op), handler), 0 }; p.p = new (p.v) op(impl, query, io_service_impl_, handler);
BOOST_ASIO_HANDLER_CREATION((p.p, "resolver", &impl, "async_resolve"));
start_resolve_op(p.p); p.v = p.p = 0; } |
PS：
- 做过Symbian开发的对这种形式似曾相识，这多少和Active Object异曲同工
- 那几行创建op的代码还不是很明白
OK，至此，整个async_resolve()从上到下就拉通了。概括起来，就是io object将具体功能委托给服务类，服务类又委托给和平台实现相关的服务类来完成最后的功能。
io_object的服务创建
通过resolver的执行，我们知道了其层层委托关系，那么resolver所委托的this->service又是怎么来的呢？下面部分，我们来分析io_object所做的服务管理工作。
首先来看该service的具体类型。
要想知道service是如何创建的，我们就要追根朔源找到resolver的具体类型声明，看看到底是如何将service拉上贼船的。好吧，我们再次从头开始（别嫌啰嗦）：
typedef basic_resolver<tcp> resolver;
针对这个模版实例，将basic_resolver展开：
template <typename InternetProtocol,
typename ResolverService = resolver_service<InternetProtocol> >
class basic_resolver: public basic_io_object<ResolverService>
à
template <tcp,
typename ResolverService = resolver_service<tcp> >
class basic_resolver: public basic_io_object< resolver_service<tcp> >
再对basic_io_object进行展开：
template <typename IoObjectService>
class basic_io_object
à
template < resolver_service<tcp> >
class basic_io_object
在basic_io_object内部展开：
typedef IoObjectService service_type;
à
typedef resolver_service<tcp> service_type;
于是，可以确定basic_io_object::service的类型为 resolver_service<tcp>&；从而将io object和下层的service关联起来。
再来看basic_io_object::service的初始化。我们来看其构造函数：
| explicit basic_io_object(boost::asio::io_service& io_service) : service(boost::asio::use_service<IoObjectService>(io_service)) { service.construct(implementation); } |
很明显，在构造过程中，使用use_service的返回值来初始化该service成员；我们知道，use_service会在io_service所维护的service链表中查找该类型，如果没有，就创建一个新的service实例；在此，就可以确保resolve_service<tcp>的实例已经被创建出来了，该服务就可以工作了（当然，不要忘记，该service事实上又委托了一层，而这个最底层的service实例，在此resolve_service<tcp>的构建过程中，内部再次调用use_service()创建出来了。过程如下：
除此之外，在构造函数体中，调用了service的construct函数，做进一步的初始化。（PS：是否有Symbian中的二段构造的影子呢？）
asio 的io逻辑总结
前面部分以resolver为例，分析了resolver的功能和对应service之间的关系，纵观所有的io object，都是采用了这种模式，总结起来有如下几点：
· asio提供了多个basic_ 模版类。
· 应用层使用对应的basic_ 模版类的typedef的具体类，对外提供服务接口。
· io object内部，将操作委托给底层服务类。
· 底层服务类再次将操作委托给平台实现层，完成实际的工作。
·asio的体系结构
三层类关系图
根据前面的分析，我们知道asio有着这样的逻辑：
- 参考STL，提供basic模版，对外使用basic模版的实例提供接口。
- basic模版将具体操作委托给下层服务类完成。
- 下层服务类再把操作委托给平台相关的服务类。
鉴于此，我们将asio体系划分为三层：io object层，basic_ 模版类层，服务层。
- 第一层：io object层，作为应用程序直接使用的对象，是各种basic_ 模版类的typedef实例类。
- 第二层：basic_ 模版类层，提供对外操作的接口，并把具体操作转发给服务类。
- 第三层：服务层。提供具体操作的底层实现，这一层又分为两层：
- 操作接收层
- 平台适配层
基本的体系结构关系如下图所示。 注意：图中并非全部asio中的类。
动态组装
前面已经提过，resolver和STL中的string一样，都是使用了basic_模板类的一个具体实例。这种在编译时动态地选择对应的组件进行编译，我们姑且称为动态组装。这种技术使得我们可以对asio的service进行扩展。例如自己实现一个resolver的service类，然后告诉basic_resolver，你要使用自己的service类，而非默认的那个……
不过话说回来，自己对boost或者STL进行扩展，需要点实力的
·asio的windows实现
Operation
还记得前面我们在分析resolver的实现的时候，挖了一个关于operation的坑？为了不让自己陷进去，现在来填吧；接下来我们就来看看asio中的各种operation。
和前面提到过的service的类似，这里的operation也分为两大系：IOCP Enable和Disable系列。这里我们重点关注下图中红色部分表示的IOCP Enable系列operation。
OVERLAPPED基类
从上图可以看到，所有IOCP Enable的operation，其基类都是struct OVERLAPPED结构，该结构是Win32进行交叠IO一个非常重要的结构，用以异步执行过程中的参数传递。所有的operation直接从该结构继承的结果，就是所有operation对象，可以直接作为OVERLAPPED结构在异步函数中进行传递。
例如在win_iocp_socket_service_base中，为了启动一个receive的异步操作, start_receive_op函数就直接把传递进来的operation指针作为OVERLAPPED结构传递给::WSARecv函数，从而发起一个异步服务请求。
| void win_iocp_socket_service_base::start_receive_op( win_iocp_socket_service_base::base_implementation_type& impl, WSABUF* buffers, std::size_t buffer_count, socket_base::message_flags flags, bool noop, operation* op) { update_cancellation_thread_id(impl); iocp_service_.work_started();
if (noop) iocp_service_.on_completion(op); else if (!is_open(impl)) iocp_service_.on_completion(op, boost::asio::error::bad_descriptor); else { DWORD bytes_transferred = 0; DWORD recv_flags = flags; int result = ::WSARecv(impl.socket_, buffers, static_cast<DWORD>(buffer_count), &bytes_transferred, &recv_flags, op, 0); DWORD last_error = ::WSAGetLastError(); if (last_error == ERROR_NETNAME_DELETED) last_error = WSAECONNRESET; else if (last_error == ERROR_PORT_UNREACHABLE) last_error = WSAECONNREFUSED; if (result != 0 && last_error != WSA_IO_PENDING) iocp_service_.on_completion(op, last_error, bytes_transferred); else iocp_service_.on_pending(op); } } |
执行流程
关于operation对象的创建、传递，以及完成handler的执行序列等，使用下图可以清晰的描述。
下表反映了Windows环境下，部分的异步请求所对应的服务、win函数、operation等信息：
| 异步请求 | 服务 | start op | Win32函数 | 对应operation |
| ip::tcp::socket:: async_connect | win_iocp_socket_service | start_connect_op() | ::connect | reactive_socket_connect_op |
| ip::tcp::socket:: async_read_some | start_receive_op() | ::WSARecv | win_iocp_socket_recv_op | |
| ip::tcp::socket:: async_receive | start_receive_op() | ::WSARecv | win_iocp_socket_recv_op | |
| ip::tcp::socket:: async_write_some | start_send_op() | ::WSASend | win_iocp_socket_send_op | |
| ip::tcp::socket:: async_send | start_send_op() | ::WSASend | win_iocp_socket_send_op | |
| ip::tcp::acceptor:: async_accept | start_accept_op() | :: AcceptEx | win_iocp_socket_accept_op | |
|
|
|
|
|
|
| ip::tcp::resolver:: async_resolve | resolver_service | start_resolve_op() | :: getaddrinfo | resolve_op |
静态的do_complete
不知你是否注意到，在operation的类图中，所有从operation继承的子类，都定义了一个do_complete()函数，然而该函数声明为static，这又是为何呢？
我们以win_iocp_socket_recv_op为例来进行说明。该类中的do_complete是这样声明的：
static void do_complete(io_service_impl* owner,
operation* base,
const boost::system::error_code& result_ec,
std::size_t bytes_transferred)
该类的构造函数，又把此函数地址传递给父类win_iocp_operation去初始化父类成员，这两个类的构造函数分别如下，请注意加粗代码：
win_iocp_socket_recv_op ::
win_iocp_socket_recv_op(socket_ops::state_type state,
socket_ops::weak_cancel_token_type cancel_token,
const MutableBufferSequence& buffers, Handler& handler)
: operation(&win_iocp_socket_recv_op::do_complete),
state_(state),
cancel_token_(cancel_token),
buffers_(buffers),
handler_(BOOST_ASIO_MOVE_CAST(Handler)(handler))
{
}
win_iocp_operation ::win_iocp_operation(func_type func)
: next_(0),
func_(func)
{
reset();
}
至此，我们明白，将do_complete声明为static，可以方便获取函数指针，并在父类中进行回调。那么，不仅要问，既然两个类存在继承关系，那么为何不将do_complete声明为虚函数呢？
再回头看看这些类的最顶层基类，就会明白的。最顶层的OVERLAPPED基类，使得将operation对象作为OVERLAPPED对象在异步函数中进行传递成为可能；如果将do_complete声明为虚函数，则多数编译器会在对象起始位置放置vptr，这样就改变了内存布局，从而不能再把operation对象直接作为OVERLAPPED对象进行传递了。
当然，一定要用虚函数的话，也不是不可能，只是在传递对象的时候，就需要考虑到vptr的存在，这会有两个方面的问题：一是进行多态类型转换时，效率上的损失；二是各家编译器对vtpr的实现各不相同，跨平台的asio就需要进行多种适配，这无疑又过于烦躁了。于是作者就采取了最为简单有效的方式——用static函数来进行回调——简单，就美。
win_iocp_io_service的实现
在Windows NT环境下（IOCP Enabled），win_iocp_io_service代表着io_service，是整个asio的运转核心。本节开始来分析该类的实现。
从类的命名也可以看出，IOCP是该实现的核心。IOCP（IO Completion Port， IOCP）在windows上，可以说是效率最高的异步IO模型了，他使用有限的线程，处理尽可能多的并发IO请求。该模型虽说可以应用于各种IO处理，但目前应用较多的还是网络IO方面。
我们都知道，在Window是环境下使用IOCP，基本上需要这样几个步骤：
- 使用Win函数CreateIoCompletionPort()创建一个完成端口对象；
- 创建一个IO对象，如用于listen的socket对象；
- 再次调用CreateIoCompletionPort()函数，分别在参数中指定第二步创建的IO对象和第一步创建的完成端口对象。由于指定了这两个参数，这一次的调用，只是告诉系统，后续该IO对象上所有的完成事件，都投递到绑定的完成端口上。
- 创建一个线程或者线程池，用以服务完成端口事件；
所有这些线程调用GetQueuedCompletionStatus()函数等待一个完成端口事件的到来；
- 进行异步调用，例如WSASend()等操作。
- 在系统执行完异步操作并把事件投递到端口上，或者客户自己调用了PostQueuedCompletionStatus()函数，使得在完成端口上等待的一个线程苏醒，执行后续的服务操作。
那么，这些步骤，是如何分散到asio中的呢？ 来吧，先从完成端口创建开始。
完成端口的创建
如上所述，完成端口的创建，需要调用CreateIoCompletionPort()函数，在win_iocp_io_service的构造函数中，就有这样的操作：
| win_iocp_io_service::win_iocp_io_service( boost::asio::io_service& io_service, size_t concurrency_hint) : boost::asio::detail::service_base<win_iocp_io_service>(io_service), iocp_(), outstanding_work_(0), stopped_(0), stop_event_posted_(0), shutdown_(0), dispatch_required_(0) { BOOST_ASIO_HANDLER_TRACKING_INIT;
iocp_.handle = ::CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, static_cast<DWORD>((std::min<size_t>)(concurrency_hint, DWORD(~0)))); if (!iocp_.handle) { DWORD last_error = ::GetLastError(); boost::system::error_code ec(last_error, boost::asio::error::get_system_category()); boost::asio::detail::throw_error(ec, "iocp"); } } |
win_iocp_io_service的构造函数，负责创建一个完成端口，并把此完成端口对象的句柄交给一个auto_handle进行管理——auto_handle的唯一用途，就是在对象析构时，调用::CloseHandle()把windows句柄资源关闭，从而保证不会资源泄露。
我们在windows环境下，声明一个boost::asio::io_service对象，其内部就创建了一个win_iocp_io_service的实例；因此，一个io_service对象就对应着一个完成端口对象——这也就可以解释，为什么所有的IO Object都需要一个io_service参数了——这样，大家就好公用外面定义好的完成端口对象。
除了io_service对象会创建一个完成端口对象，事实上，在asio中，另外一个service也会创建一个，这就是boost::asio::ip::resolver_service。该类对应的detail实现boost::asio::detail::resolver_service中，有一个数据成员是: io_service，这样就同样创建了一个完成端口对象：
namespace boost {
namespace asio {
namespace detail {
class resolver_service_base
{
...
protected:
// Private io_service used for performing asynchronous host resolution.
scoped_ptr<boost::asio::io_service> work_io_service_;
...
至于该完成端口的用途如何，我们在后续部分再来说明——搽，又开始挖坑了。
完成端口的绑定
在创建了io对象后，例如socket，就需要将此对象和完成端口对象绑定起来，以指示操作系统将该io对象上后续所有的完成事件发送到某个完成端口上，该操作同样是由CreateIoCompletionPort()函数完成，只是所使用的参数不同。
在win_iocp_io_service中，这个操作由下面的代码完成——请注意参数的差别：
| boost::system::error_code win_iocp_io_service::register_handle( HANDLE handle, boost::system::error_code& ec) { if (::CreateIoCompletionPort(handle, iocp_.handle, 0, 0) == 0) { DWORD last_error = ::GetLastError(); ec = boost::system::error_code(last_error, boost::asio::error::get_system_category()); } else { ec = boost::system::error_code(); } return ec; } |
通过代码搜索，我们发现函数win_iocp_socket_service_base::do_open()内部调用了register_handle();该函数的作用是打开一个socket(其中调用了socket函数socket()去创建一个socket)，也就是说，在打开一个socket后，就把该socket绑定到指定的完成端口上，这样，后续的事件就会发送到完成端口了。
此外还有另外的和assign相关的两个函数也调用了register_handle()，不再贴出其代码了。
线程函数
IOCP要求至少有一个线程进行服务，也可以有一堆线程；io_service早就为这些线程准备好了服务例程，即io_service::run()函数。
- 如果应用只打算使用一个线程进行服务，那么在主线程中准备好了异步请求后，调用io_service::run()即可。注意，必须先发起一个异步请求，然后才能调用run()。参考一下run()的实现就会明白。
- 如果打算用多个线程进行服务，可以创建多个线程，指定io_service::run() 作为线程函数即可。一个最简单的示例是：
| void server::run() { // Create a pool of threads to run all of the io_services. std::vector<boost::shared_ptr<boost::thread> > threads; for (std::size_t i = 0; i < thread_pool_size_; ++i) { boost::shared_ptr<boost::thread> thread( new boost::thread( boost::bind(&boost::asio::io_service::run, &io_service_) ) ); threads.push_back(thread); }
// Wait for all threads in the pool to exit. for (std::size_t i = 0; i < threads.size(); ++i) threads[i]->join(); } |
由于io_service::run()又是委托win_iocp_io_service::run()来实现的，我们来看看后者的实现：
| size_t win_iocp_io_service::run(boost::system::error_code& ec) { if (::InterlockedExchangeAdd(&outstanding_work_, 0) == 0) { stop(); ec = boost::system::error_code(); return 0; }
win_iocp_thread_info this_thread; thread_call_stack::context ctx(this, this_thread);
size_t n = 0; while (do_one(true, ec)) if (n != (std::numeric_limits<size_t>::max)()) ++n; return n; } |
run()首先检查是否有需要处理的操作，如果没有，函数退出；win_iocp_io_service使用 outstanding_work_ 来记录当前需要处理的任务数。如果该数值不为0，则委托do_one函数继续处理——asio中，所有的脏活累活都在这里处理了。
win_iocp_io_service::do_one函数较长，我们只贴出核心代码
| size_t win_iocp_io_service::do_one(bool block, boost::system::error_code& ec) { for (;;) { // Try to acquire responsibility for dispatching timers and completed ops. if (::InterlockedCompareExchange(&dispatch_required_, 0, 1) == 1) ? #1 { mutex::scoped_lock lock(dispatch_mutex_);
// Dispatch pending timers and operations. op_queue<win_iocp_operation> ops; ops.push(completed_ops_); timer_queues_.get_ready_timers(ops); post_deferred_completions(ops); ? #2 update_timeout(); }
// Get the next operation from the queue. DWORD bytes_transferred = 0; dword_ptr_t completion_key = 0; LPOVERLAPPED overlapped = 0; ::SetLastError(0); BOOL ok = ::GetQueuedCompletionStatus(iocp_.handle, &bytes_transferred, &completion_key, &overlapped, block ? gqcs_timeout : 0); ? #3 DWORD last_error = ::GetLastError();
if (overlapped) { win_iocp_operation* op = static_cast<win_iocp_operation*>(overlapped); ? #4 boost::system::error_code result_ec(last_error, boost::asio::error::get_system_category());
// We may have been passed the last_error and bytes_transferred in the // OVERLAPPED structure itself. if (completion_key == overlapped_contains_result) { result_ec = boost::system::error_code(static_cast<int>(op->Offset), *reinterpret_cast<boost::system::error_category*>(op->Internal)); bytes_transferred = op->OffsetHigh; }
// Otherwise ensure any result has been saved into the OVERLAPPED // structure. else { op->Internal = reinterpret_cast<ulong_ptr_t>(&result_ec.category()); op->Offset = result_ec.value(); op->OffsetHigh = bytes_transferred; }
// Dispatch the operation only if ready. The operation may not be ready // if the initiating function (e.g. a call to WSARecv) has not yet // returned. This is because the initiating function still wants access // to the operation's OVERLAPPED structure. if (::InterlockedCompareExchange(&op->ready_, 1, 0) == 1) { // Ensure the count of outstanding work is decremented on block exit. work_finished_on_block_exit on_exit = { this };? #5 (void)on_exit; ? #6
op->complete(*this, result_ec, bytes_transferred); ? #7 ec = boost::system::error_code(); return 1; } } else if (!ok) { ... |
做一下简要说明：
- #1： 变量 dispatch_required_ 记录了由于资源忙，而没有成功投递的操作数；所有这些操作都记录在队列 completed_ops_ 中；
- #2： 将所有需要投递的操作，投递出去；至于什么样的操作需要投递，何时投递，以及为先前会投递失败，失败后如何处理等，我们后续说明——再次挖坑了。
- #3： IOCP的核心操作函数 GetQueuedCompletionStatus() 出现了。该函数导致线程在完成端口上进行等待，直到超时或者某个完成端口数据包到来。
- #4： 注意这里将 OVERLAPPED 结构直接转换为 operation 对象。相关内容在前面的operation:OVERLAPPED基类部分已经有说明。
- #5： 该变量保证在操作完成，return之后，win_iocp_io_service对象所记录的任务数 outstanding_work_ 会自动减1——是啊，辛辛苦苦做的事儿，能不记录下来嘛！
- #6： 这一行从功能上讲没有什么特别的用途；不过有了这一行，可以抑制有些编译器针对 #5 所声明的变量没有被使用的编译器警告；
- #7： 调用operation对象的complete()函数,从而调用到异步操作所设定的回调函数。具体流程参考operation：执行流程。
任务投递
上述的线程函数，会在 GetQueuedCompletionStatus() 函数上进行等待，直到超时或者有完成端口数据包到来；
完成端口数据包，有两个来源：一个是用户所请求的异步操作完成，异步服务执行者（这里是操作系统）向该完成端口投递完成端口数据包；另外一种情况是，用户自己使用IOCP的另外一个核心函数 PostQueuedCompletionStatus() 向完成端口投递数据包；
一般的异步操作请求，是不需要用户自己主动向完成端口投递数据的，例如async_read, asyn_write等操作；
有另外一些操作，由于没有对应或者作者并没有采用支持OVERLAPPED IO操作的Win32函数，就需要实现者自己管理完成事件，并进行完成端口数据包的投递，比如：
- async_resolve：由于系统没有提供对应的OVERLAPPED IO操作，需要实现者自己管理，所以其自己进行投递
- async_connect：由于作者并没有采用支持OVERLAPPED IO的ConnectEx()版本的连接函数，而是采用了标准的socket函数connect()进行连接，所以也需要自己进行投递
另外还有一些io_service提供的操作，例如请求io_service执行代为执行指定handler的操作：
- dispatch(handler)
- post(handler)
所有这些需要自己投递完成端口数据包的操作，基本上都是这样一个投递流程：
- 调用win_iocp_io_service::post_immediate_completion(op)
- 调用work_started() 给 outstanding_work_ 加 1
- 调用post_deferred_completion(op)
- 由于自行管理，主动将op->ready_ 置为 1，表明op就绪
- 调用 PostQueuedCompletionStatus(op) 进行投递
- 如果投递失败，则把该op放置到等待dispatch的队列 completed_ops_ 中，待下一次do_one()执行时，再次投递
OK，至此，基本分析完了operation的投递，总数填了一个前面挖下的坑。
Resolver自己的IOCP
前面说过，Resolver自己会创建一个IOCP，为什么会这样呢？ 由于Win32下面没有提供对应于地址解析的overlapped版本的函数，为了实现async_resolve操作，作者自己实现了这样一个异步服务。在resolver_service内部，有一个io_service数据成员，该数据成员创建了一个IOCP；除此之外，该service内部还启动一个工作线程来执行io_service::run()，使用此线程来模拟异步服务。
使用resolver进行async_resolve的详细过程如下：
| Main Thread (IOCP#1) | Resolver Thread (IOCP #2) | |
|
|
|
|
| 1. 构建 主io_service 对象, IOCP#1 被创建 |
|
|
|
|
|
|
| 2. 构建 resolver对象， IOCP#2 被创建， 同时该resolver持有 主io_service的引用 |
|
|
|
|
|
|
| 3. 发起异步调用：resolver.async_resolve() |
|
|
|
|
|
|
| 4. resolve_op 被创建 |
|
|
|
|
|
|
| 5. Resolver 线程启动， 主线程开始等待 |
|
|
|
|
|
|
|
|
| 6. 开始运行，激活等待事件，并在 IOCP#2上开始等待 |
|
|
|
|
| 7. 线程恢复执行；将op投递到 IOCP#2 |
|
|
|
|
|
|
|
|
| 8. 执行op->do_complete() 操作， 地址解析完成后，将op再回投给IOCP#1 |
|
|
|
|
| 9. do_one() 得到 从Resolver线程投递回 来的op， 开始执行op->do_complete() 操作，此时回调async_resolve所设置的handler |
|
|
|
|
|
|
| 10. 结束 |
|
|
请注意step8 和 step9， 执行同样一个op->do_complete()函数，为什么操作不一样呢？ 看其实现就知道，该函数内部，会判断执行此函数时的owner，如果owner是主io_service对象，则说明是在主线程中执行，此时进行handler的回调；否则就说明在工作线程中，就去执行真正的地址解析工作；
任务的取消
针对socket上提交的异步请求，可以使用cancel()函数来取消掉该socket上所有没执行的异步请求。
使用该函数，在Windows Vista（不含）以前的版本，有几点需要注意：
- 需要定义 BOOST_ASIO_ENABLE_CANCELIO 来启用该功能
- cancel()函数在内部调用Win32函数 CancelIo()。
- 该函数只能取消来自当前线程的异步请求
- 对于正在执行的异步操作，则要看异步服务提供者是如何实现的了，可能会被取消，也可能不会；
针对这些问题，另外的替代方案是：
- 在Window是上定义 BOOST_ASIO_DISABLE_IOCP 来禁用IOCP，使用老式的reactor模式（及select IO）。
- 或者使用close()来关闭socket，如此一来所有未被执行的请求则都会被取消掉。
在windows vista及后续版本中，cancel()函数在内部调用Win32函数 CancelIoEx()，该函数可以取消来自任何线程的异步操作请求，不存在上述问题。
需要注意的是，即使异步请求被取消了，所指定的handler也会被执行，只是传递的error code 为： boost::asio::error::operation_aborted。
win_iocp_socket_service实现
该service提供了windows下所有socket相关的功能，是asio在windows环境中一个非常重要的角色，他所提供的函数主要分下面两类：
- XXXXX(), async_XXXXX()： 对某个操作的同步、异步函数接口；主要被上层服务调用；例如connect(), async_connect()等；
- start_XXXXX_op() : 向windows发出对应的异步操作请求，例如WSARecv；
不过关于该类的实现前面已经做了较多的涉及，不再单独详述了。
前摄器模式
现在我们已经把Windows环境下所涉及到的关键部件都涉及到了，此刻我们再回过头来，从高层俯瞰一下asio的架构，看看是否会有不一样的感受呢？ 事实上，asio的文档用下面的图来说明asio的高层架构——前摄器模式，我们也从这个图开始:
呵呵，其实这张图，从一开始就是为了表达Proactor（前摄器）模式的，基本上它和asio没半毛钱关系，只不过asio既支持同步IO，又支持异步IO，在异步IO部分，是参照Proactor模式来实现的。下面我们来分别说说asio的前摄器模式中的各个组件：
- Initiator，（初始化器？）中文名还真不清楚，不过其实就是客户代码，甚至可以简单理解到main函数，所有的是是非非，都是从这儿开始的。
- Asynchronous Operation, 定义的一系列异步操作，对应到Windows平台，诸如AcceptEx，WSASend，WSARecv等函数。在asio中，这些函数封装在win_iocp_socket_service， resolver_service类中。
- Asynchronous Operation Processor, 异步操作处理器，他负责执行异步操作，并在操作完成后，把完成事件投放到完成事件队列上。
仅仅从asio使用者的角度看，高层的stream_socket_service类就是一个这样的处理器，因为从tcp::socket发送的异步操作都是由其完成处理的。但是从真正实现的角度看，这样的异步操作在Windwos上，大部分由操作系统负责完成的，另外一部分由asio自己负责处理，如resolver_service,因此Windows操作系统和asio一起组成了异步操作处理器。
- Completion Handler,完成事件处理器；这是由用户自己定义的一个函数（函数对象），在异步操作完成后，由前摄器负责把该函数调用起来。
在Windows平台上，io_service类通过win_iocp_io_service类的do_one()函数把每个异步操作所设定的completion handler调用起来。
- Completion Event Queue， 完成事件队列，存储由异步操作处理器发送过来的完成事件，当异步事件多路分离器将其中一个事件取走之后，该事件从队列中删除；
在Windows上，asio的完成事件队列由操作系统负责管理；只不过该队列中的数据有两个来源，一个是Windows内部，另外一个是asio中自己PostQueuedCompletionStatus()所提交的事件。
- Asynchronous Event Demultiplexer,异步事件多路分离器，他的作用就是在完成事件队列上等待，一旦有事件到来，他就把该事件返回给调用者。
在Windows上，这一功能也是由操作系统完成的，具体来说，我认为是由GetQueuedCompletionStatus完成的，而该函数时由do_one()调用的，因此，从高层的角度来看，这个分离器，也是由io_service负责的。
- Proactor，前摄器，负责调度异步事件多路分离器去干活，并在异步操作完成时，调度所对应的Completion Handler。在asio中，这部分由io_service来做，具体Windows就是win_iocp_io_service。
基于上述信息，我们重绘practor模式架构图如下：
·其他
asnyc_read VS. async_read_some VS. async_receive
async_read是一个全局函数；后面两个则于ip::tcp::socket的成员个函数；都可以用来异步读取操作，他们有什么样的差别呢。先来看async_read_some和async_receive，他们的文档说明如下：
- async_read_some: Start an asynchronous read. This function is used to asynchronously read data from the stream socket. The function call always returns immediately.
- async_receive: Start an asynchronous receive. This function is used to asynchronously receive data from the stream socket. The function call always returns immediately.
从文档来看，只有一个单词的差别，一个是read,一个是receive；反正都是从socket中获取数据，这两个词有什么差别呢？我是看不出他们的差别，那就看代码吧：
| template <typename MutableBufferSequence, typename ReadHandler> void async_read_some(const MutableBufferSequence& buffers, BOOST_ASIO_MOVE_ARG(ReadHandler) handler) { // If you get an error on the following line it means that your handler does // not meet the documented type requirements for a ReadHandler. BOOST_ASIO_READ_HANDLER_CHECK(ReadHandler, handler) type_check;
this->get_service().async_receive(this->get_implementation(), buffers, 0, BOOST_ASIO_MOVE_CAST(ReadHandler)(handler)); }
template <typename MutableBufferSequence, typename ReadHandler> void async_receive(const MutableBufferSequence& buffers, BOOST_ASIO_MOVE_ARG(ReadHandler) handler) { // If you get an error on the following line it means that your handler does // not meet the documented type requirements for a ReadHandler. BOOST_ASIO_READ_HANDLER_CHECK(ReadHandler, handler) type_check;
this->get_service().async_receive(this->get_implementation(), buffers, 0, BOOST_ASIO_MOVE_CAST(ReadHandler)(handler)); } |
好了，有了源代码，就无从狡辩了吧。他们都是使用底层服务的async_recevie来读取数据，因此他们的功能是一样的，都是从socket获取一定的数据，但是该函数并不保证能够从获得指定长度的数据——也即不保证填满缓冲区；
如果想要保证异步操作完成时获取到指定数量（缓冲区的长度）的数据，那么使用全局函数async_read。该函数内部启动一个 read_op ，该op内部，会多次调用stream.async_read_some，直到缓冲区填满，或者读操作结束；
这既是这三个函数的异同之所在。
妖怪async_read
前面一节提到过，全局函数 async_read 会启动read_op并在该op内部反腐调用async _read_some()来读取数据直到缓冲区慢，或者EOF出现；如果要来看一下read_op的operator()，你多半会感觉看到妖怪了。乖，别怕，来看看吧：
| void operator()(const boost::system::error_code& ec, std::size_t bytes_transferred, int start = 0) { std::size_t n = 0; switch (start) { case 1: n = this->check_for_completion(ec, total_transferred_); for (;;) { stream_.async_read_some( boost::asio::buffer(buffer_ + total_transferred_, n), BOOST_ASIO_MOVE_CAST(read_op)(*this)); return; default: total_transferred_ += bytes_transferred; if ((!ec && bytes_transferred == 0) || (n = this->check_for_completion(ec, total_transferred_)) == 0 || total_transferred_ == boost::asio::buffer_size(buffer_)) break; }
handler_(ec, static_cast<const std::size_t&>(total_transferred_)); } } |
不知道你是否会和我一样感觉毛骨悚然，惊叫switch-case的邪乎。是的，说他妖怪，就妖怪在switch的那两个case标签，第一个 “case 1” 还算人性，第二个标签default就完全是妖怪了，它放置在for循环的内部——是的，编译器是允许的，假设程序流程首先跳转到default标签，在执行完default分支后，他会像正常的for循环流程一样，继续for loop的，这就是这个妖怪。
自己写的一个简单的测试及输出：
| void jumpinto( int state ) { int i = 0; switch( state ) { case 1: cout << "case 1: begin for()" << endl; for( ; ; ) { cout << " in for loop, i = " << i++ << endl; //return; default: cout << "case default " << endl; if( i > 2 ) { cout << " i > 2, break" << endl; break; } }// end for };//end switch }
int main() { jumpinto(0); return 0; }
输出如下： D:\studyprograms\test>caseblock.exe case default in for loop, i = 0 case default in for loop, i = 1 case default in for loop, i = 2 case default i > 2, break |
关于为何作者要这样写，暂时还没理解到。更多信息移驾翊坤宫再议：http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
优雅退出
使用asio开发的应用要中途退出，或者开发的server要停止，咱如何优优雅雅地清理asio组件呢？ 呵呵，肯定可以，asio已经提供了一些手段：signal。下面是从asio示例代码中提取出的一些代码，以示说明。
| class server : private boost::noncopyable { public: explicit server(const std::string& address, const std::string& port, const std::string& doc_root, std::size_t thread_pool_size) : signals_(io_service_pool_.get_io_service()), acceptor_(...) { signals_.add(SIGINT); signals_.add(SIGTERM);
#if defined(SIGQUIT) signals_.add(SIGQUIT); #endif // defined(SIGQUIT)
signals_.async_wait(boost::bind(&server::handle_stop, this)); }
private: void handle_stop() { io_service_.stop(); }
boost::asio::io_service io_service_; boost::asio::signal_set signals_; boost::asio::ip::tcp::acceptor acceptor_; }; |
·总结：
至此，我们对boost.asio的基本体系结构以及在windows上的实现，做了一个梳理；个人认为常用到的操作及其实现都涉及到了。当然，本文并没有对非Win环境下的实现、SSL，串口、buffer管理、以及如何使用asio等进行讨论。
针对asio，个人也是刚刚接触正在学习，觉得要想使用好他，还是首先要了解socket的基本操作，在windows环境下，还要了解IOCP模型，然后才能用好它。欢迎讨论。
最后，向Christopher M. Kohlhoff (chris@kohlhoff.com)跪一下。
转载地址：http://blog.163.com/henan_lujun/blog/static/19538333201341451545880/
295
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
