yang79tao的专栏

介绍ascs依赖从standalone asio改为Boost.Asio之后的变化。

单线程版本，需要你显示地以sp.start_service(0);单线程模式指的并不是只能有一个service线程，而是一个io_context一个service线程，对于每个io_context来说，就是单线程模式，asio对单线程模式有优化，比如事件队列的增删操作省去加锁等。注意，如上所说，单线程版本的确可按普通版本运行，只是构造service_pump的时候，默认所有参数即可，然后以大于0启动，但这样反而不如普通版本效率高（只是理论上的，单线程模式下会多一些if判断）。单线程模式其实就是基于。

本文介绍了不通过继承重写虚函数的方式来使用 ascs 库，而是通过注册事件回调函数来实现。

QQ交流群：198941541可靠UDP基于KCP（https://github.com/skywind3000/kcp），用户需要熟悉KCP的窗口大小，重传模式，流控等，ascs还是原来的的原则，不封装KCP，用户通过ikcpcb* get_kcpcb() 得到ikcpcb做任意想要的配置，当然应该在数据收发之前（构造函数里面和reset虚函数里面，后者会在socket被重用之后马上被调用）。reliable_socket_base继承自原来的 UDP socket_base，所以如果你不创建KC

QQ交流群：198941541多io_context比单io_context来说，基本上在所有情况下都有性能优势（当然也你还是应该在自己的实现生产环境下面做一些调优，以找到最优的io_context数量加service线程数量），多io_context有一些自身特定的要求，罗列如下：一：需要定义ASCS_AVOID_AUTO_STOP_SERVICE宏（但库没办法做静态代码检测，所以你不定义也编译得过），这是因为，拿服务端举例，一个servcer_base只包涵一个acceptor，一个accept

QQ交流群：198941541消息发送完成通知即on_msg_send和on_all_msg_send，消息派发指的是on_msg和on_msg_handle（包括批量异步派发和单条异步派发），先抛出结论，不要对这两类回调的先后顺序做任何假设，即便是on_msg_send与on_msg也一样（它们都属于收发线程，还记得在上一篇教程里面说的每个socket里面都有两个线程吗？）。我们说一个很特殊的案例，a发送一个消息给b，b再原样返回，a接收这个返回，然后ab都停止数据收发，这个案例看起来最像是有先后

QQ交流群：198941541debug_assistant是我放到腾讯云（132.232.4.104）上给大家测试用的，总共监听了3个端口：tcp(9527), tcp(9528) 和 udp(9527)，第一个采用默认的 length + body 协议，第二个采用流式无协议，所有的服务都是把消息原样返回，所以这个demo没什么好说的，唯一一个之前没说过的演示是实现自己的object_pool：template<typename Object>class timed_object

QQ交流群：198941541无锁队列即non_lock_queue，只要你用的container（默认是list，非线程安全）是线程安全的，就一定可以用无锁队列。我们重点要讲的是，如果container非线程安全，哪种类型的业务可以用无锁队列（file_server就用了无锁发送缓存队列）。先说说socket里面到底有多少线程，service线程可以开很多，但是由于用的asio的strand，它可以保证不并发，所以我们仍然把这种情况看成单线程（虽然线程id不一样），基于这样的前提，每一个socke

一个类似ftp的文件传输工具的实现介绍，当然是基于ascs。

QQ交流群：198941541这一组合用于乒乓测试，其实concurrent_client + concurrent_server也是乒乓测试，只是测试方向不一样而已，其实这一组乒乓测试更像是echo_client + echo_server的测试，大家不用纠结名字。既然是乒乓测试，那必须是收到消息之后再转发（或者发送下一个消息），从结果可以明显的看出来，乒乓测试的效率出奇的错差，原因也一目了然，它完全没有用上ascs的收发缓存，也没有用上SOCKET的收发缓存。所以你得祈求你的业务不是乒乓测试这种

QQ交流群：198941541这个组合用于测试并发性，在concurrent_client里面指定连接数量和最大的可接受延迟，然后开始测试，它会定时检测服务端的响应时间，如果超过最大延迟就断开这条连接，所以最后稳定下来之后的连接数量，就是在满足这个最大延迟情况下，服务端支持的最大连接数，测试永不停止，直到输入quit退出concurrent_client。这个测试中你会发现，当业务逻辑（消息原样返回）非常简单时，用1个service线程也许能达到最高的吞吐量，这说明在极端情况下，线程的切换也会影响总

QQ交流群：198941541echo_client + echo_server用于性能测试，同时echo_server还多开了两个端口用于服务demo client，这个在前一篇教程里面已经说过了。先说说echo_client，它演示了 关闭对象生命同期跟踪（宏ASCS_DELAY_CLOSE），同步批量派发消息（宏ASCS_SYNC_DISPATCH，此时你在on_msg里面处理消息），异步批量派发消息（宏ASCS_DISPATCH_BATCH_MSG，此时和单条派发消息一样，也是在on_msg

QQ交流群：198941541按理说每个demo都应该像是一个UT test，仅演示一个或者很少许的功能，但由于个人偷懒的原因，想演示得更多，又不想新增加demo工程的个数，造成demo变得巨复杂，感觉使用ascs库比直接使用asio还麻烦，为此专门出几期教程介绍这些demo，很多新接触ascs的朋友，喜欢从demo上修改得到自己想要的功能，本人并不推荐这么做，而是应该把ascs 简明开发教程 先读完，再从前面四篇教程里面生成的代码上去添加自己的业务逻辑，这样不容易把自己搞晕。这个demo演示了同.

QQ交流群：198941541前面讲过，ascs支持定时器（由asio实现），socket和object_pool都继承自timer对象，所以你几乎可以在任意地方使用定时器。下面罗列一下使用定时器需要注意的地方以及定制化定时器等：如果定义宏ASCS_USE_STEADY_TIMER，将使用asio::steady_timer实现定时器，否则用asio::system_timer；对于st_asio_wrapper库，宏ST_ASIO_USE_STEADY_TIMER表示使用boost::asio::

QQ交流群：198941541这次我们再进行一次深入的对象生命周期管理的探讨（这里的对象，其实就是socket），对象生命周期管理是object_pool做的，所以single_client是没有生命周期管理的，那是开发者的事。object_pool用shared_ptr管理对象，那第一感觉是不需要什么生命周期管理了，因为shared_ptr就是做这个的，但ascs在发起异步调用时，并没有把关联对象用shared_ptr包装并传给回调函数对象（而传的是this指针），这会造成当回调函数被调用时，关联

QQ交流群：198941541ascs需要的解包器其实是一个i_unpacker<typename Unpacker::msg_type>对象指针，但构造client_socket_base和server_socket_base时，为什么需要具体的打包解包器类呢（或者通过宏ASCS_DEFAULT_PACKER和ASCS_DEFAULT_UNPACKER定义）？这是因为ascs无法创建i_unpacker对象，它是抽象的。所以假设你有两个解包器unpacker1和unpacker2，只要它们

QQ交流群：198941541解包器必须从ascs::i_unpacker继承，i_unpacker接口定义如下：template<typename MsgType>class i_unpacker{public: typedef MsgType msg_type; typedef const msg_type msg_ctype; typedef std::list<msg_type> container_type; typedef ASCS_RECV_BU

QQ交流群：198941541解包器必须从 ascs::i_packer继承，i_packer接口定义如下：template<typename MsgType>class i_packer{public: typedef MsgType msg_type; typedef const msg_type msg_ctype; typedef std::list<msg_type> container_type;protected: virtual ~i_pa

QQ交流群：198941541发送消息类型由打包器决定，打包器都继承自template<typename MsgType> class i_packer，继承之后，你将自动得到如下定义：template<typename MsgType>class i_packer{public: typedef MsgType msg_type; typedef const msg_type msg_ctype; typedef list<msg_type> c.

QQ交流群：198941541查询显然是容器上的操作，所以这里说的查询优化对server_base和multi_client_base类均有效。查询除了大家熟悉的find，exist等调用外，do_something_to_all和do_something_to_one也算，如果你经常需要多线程查询，那么用共享锁是推荐的做法，前提是std::shared_mutex或者std::timed_shared_mutex可用。通过宏ASCS_SHARED_LOCK_TYPE定义共享锁的类型（比如std::

QQ交流群：198941541消息发送总是由使用者触发，所以速度限制由你自己实现。重点是消息接收的限速，默认情况下，ascs库总是尽量的多接收多派发消息，如果你想要接收限速，可以有几种方法：1.同步消息接收，这个跟消息发送一样，由使用者触发，所以你可以自己实现速度限制；2.被动消息接收，ascs会在连接建立起来之后，自动调用一次recv_msg，以后将完全由使用者自己调用recv_msg来接收数据，可多次调用，但只会有一次读取的效果；3.故意在on_msg_handle里面返回fa...

QQ交流群：198941541如果你的socket的创建很耗时，你可以在服务器启动之前预先创建足够多的socket对象，定义宏ASCS_ASYNC_ACCEPT_NUM，或者重写virtual int server_base::async_accept_num()即可。比如你写个网游服务器，一台服务最多支持10000个玩家，可以让服务器在启动之前先预先创建10000个玩家，这样玩家登陆就会非常快，提高用户体验。但有个问题你必须要知道，ascs在每接受一条连接之后，会马上再创建一个socket，以总是

QQ交流群：1989415411.什么是service线程？是的是ascs库使用的工作线程，个数由service_pump::start_service(int)指定，默认8个。可以运行时增加，调用service_pump::add_service_thread(int)即可，如果你想运行时减少，则需要定义宏ASCS_DECREASE_THREAD_AT_RUNTIME，然后调用serv...

QQ交流群：198941541同步消息发送需要定义宏ASCS_SYNC_SEND，定义之后你将得到sync_send_msg，sync_send_native_msg，sync_safe_send_msg和 sync_safe_send_native_msg函数用于同步消息发送，签名跟异步消息发送函数（send_msg，send_native_msg，safe_send_msg和 sa...

QQ交流群：198941541还记得以前我们说过，数据经过解包器之后（所以我称之为消息）开始派发，派发有三种方式：1.重写virtual size_t on_msg(list<OutMsgType>& msg_can)虚函数，需要定义ASCS_SYNC_DISPATCH宏，我称之为同步派发，即解包之后消息不放入缓存，而是直接回调on_msg函数（一次解包是可以得到...

QQ交流群：198941541以tcp为例，udp和tcp类似（只是类的名字不同），ssl和tcp完全一样，只是命名空间不一样：service_pump相当于asio::io_context，它负责创建（可动态）service线程（调用asio::io_context::run的线程），启停各种service，service_pump和asio::io_context一样，本身与网络编程无...

QQ交流群：198941541客户端：multi_client +断线自动重连（此时开不开启对象重用都一样）：add_socket -> on_connect -> on_recv_error -> on_close -> after_close -> on_connect -> ...multi_client +对象重用（关闭自动重连，注意...

QQ交流群：198941541服务端天生支持多连接，想只支持一条连接反而需要额外的工作量，这个我们留到讲服务端启动优化时再说，敬请期待。由于服务端连接是被动生成的，所以它不能像客户端那样管理连接（仅限于ascs 简明开发教程（3）里面介绍的方法）。为此你必须建议你自己的映射关系，先说说ascs多连接管理原理：每个新接受的连接，服务端会得到一个server_socket_base对象并为...

QQ交流群：198941541接前一篇：ascs 简明开发教程（2）为了让客户端支持任意条数的连接，我们需要修改一下ascs 简明开发教程（1）里面的代码，用multi_client代替single_client，如下：#include <iostream>#include <ascs/ext/tcp.h>using namespace ascs;us...

接前一篇：ascs 简明开发教程（1）那么ascs在后面做了什么，让这个cs程序能快速的搭建起来呢？首先看server的定义：typedef ascs::tcp::server_socket_base<ASCS_DEFAULT_PACKER, ASCS_DEFAULT_UNPACKER> server_socket;typedef ascs::tcp::server_b...

ascs前面的as跟asio前面的as意义完全一样，这也从侧面说明了ascs与asio的关系，后面的cs是client/server结构的意思。ascs是基于asio的cs框架，并不是简单的对asio的封装，因为asio已经封装的够好了，而且据说它已经在被纳入c++标准的过程中，...