boost asio acceptor 构造

 boost::asio::io_service io_svc;
 boost::asio::ip::address_v4 lis_ip; // 默认监听本机所有IP
 boost::asio::ip::tcp::endpoint lis_ep(lis_ip, );   // 监听端口: 20017
 // 一般情况构造acceptor 是按下面的方法进行构造
 boost::asio::ip::tcp::acceptor acc(io_svc, lis_ep);
 // 然后就可以直接使用acc 对象调用acc.async_accept(...) 函数了。

另外一种，如下：

 // 但是如果 想要将acc 对象的实例放到一个类中，该类的构造函数中对该acceptor 进行实例化，
 // 同时在构造函数中不进行监控操作，那么就需要上面的构造进行分解开来了。
 boost::asio::io_service io_svc;
 boost::asio::ip::tcp::acceptor  acc(io_svc);
 
 // 下面几步其实是将: boost::asio::ip::tcp::acceptor acc(io_svc, lis_ep) 拆解开来，分开调用。
 // 这样方便我们自己实现类对象的各步骤。
 boost::asio::ip::address_v4 lis_ip; // 默认监听本机所有IP
 boost::asio::ip::tcp::endpoint lis_ep(lis_ip, );   // 监听端口: 20017
 acc.open(lis_ep.protocol());
 acc.bind(lis_ep);
 acc.listen();
 // 接下来就可以调用acc.async_accept(...) 函数了。

提示：boost::asio::ip::tcp::acceptor 是没有空参构造函数的。

一大问题：

刚刚发现，将acceptor 的构造拆分成多个函数调用与直接使用构造函数进行构造对客户端的连接处理不同，而且效率差别很大。

具体场景为：

　　服务器：一个io_service 开10个线程，并发5个acceptor.async_wait() 调用。所有连接的所有处理全是调用异步函数。

　　客户端：一个io_service 开5个线程，直接循环50个async_connect()，没有任何sleep。客户端每次去仅仅的发送一个消息，马上就断开连接。

现象：

　　1、服务器使用上面说到的第一种方式进行构造acceptor (即：直接构造)，这时50个连接都能被服务器正常处理。客户端将个数调整到500 个可以350 个以上的连接;

　　2、服务器使用第二种方式进行构造acceptor (即：分成多个步骤)，这时这50个连接有20个左右未能成功连接上服务器。

暂时得到的结论是：使用第一种方式进行构造acceptor  比第二种方式进行构造accpetor 处理客户端的连接速度快很多。