打算基于asio写多种序列化库的测评，在底层用同一个asio构造函数的方式，然后上层测试脚本里切换序列化的实现。
但是最开始按着demo写逻辑就出现了问题，我想先纯面向过程，就没像demo里写一个connection类，然后就探究到一直会闪退的问题。

最后定位到时ip::tcp::socket析构的时候会断开连接。

socket的析构会断开连接

socket的大概是这样的结构：

typedef basic_stream_socket<tcp> socket;
template <typename Protocol, typename Executor>
class basic_stream_socket
  : public basic_socket<Protocol, Executor>;
{};

template <typename Protocol, typename Executor>
class basic_socket: public socket_base
{
// ....
  ~basic_socket()
  {
  }

#if defined(BOOST_ASIO_WINDOWS_RUNTIME)
  detail::io_object_impl<
    detail::null_socket_service<Protocol>, Executor> impl_;
#elif defined(BOOST_ASIO_HAS_IOCP)
  detail::io_object_impl<
    detail::win_iocp_socket_service<Protocol>, Executor> impl_;
#elif defined(BOOST_ASIO_HAS_IO_URING_AS_DEFAULT)
  detail::io_object_impl<
    detail::io_uring_socket_service<Protocol>, Executor> impl_;
#else
  detail::io_object_impl<
    detail::reactive_socket_service<Protocol>, Executor> impl_;
#endif
};

大概是这样的关系，虽然basic_socket, basic_stream_socket和tcp都没有在析构函数里做逻辑。但是实际实现操作系统连接句柄的impl_的析构函数里有做逻辑的，而且实现的方式还挺巧妙。
Windows的io_uring_socket_service和Linux的reactive_socket_service都没有在析构里做逻辑，这一部分是在detail::io_object_impl里做的。

template <typename IoObjectService,
    typename Executor = io_context::executor_type>
class io_object_impl
{
public:
  typedef IoObjectService service_type;
  // Construct an I/O object using an executor.
  explicit io_object_impl(int, const executor_type& ex)
    : service_(&boost::asio::use_service<IoObjectService>(
          io_object_impl::get_context(ex))),
      executor_(ex)
  {
    service_->construct(implementation_);
  }

  // Destructor.
  ~io_object_impl()
  {
    service_->destroy(implementation_);
  }

private:
  // The service associated with the I/O object.
  service_type* service_;
};

也就是io_object_impl本身实现的是IoObjectService的生命周期管理，对操作系统的io对象进行统一的封装，给上层提供统一的接口。然后通过模板类可以切换实际实现的方式。

同时如小标题所示，ip::tcp::socket这类对象在析构的时候会断开连接，所以在asio实际使用过程中，一定要抓住socket的生命周期。

ip::tcp::socket

顺便深入看一下tcp的连接实现细节，我们以Linux的视角看一下实现细节。

socket_base

我们从最底层看起，basic_socket继承自socket_base，socket_base是一个定义了全双工半双工状态，当前等待状态的抽象类。它的抽象体现在析构函数实现在protetecd里，只有子类对象可以被析构。

class socket_base
{
public:
  /// Different ways a socket may be shutdown.
  enum shutdown_type
  {
#if defined(GENERATING_DOCUMENTATION)
    /// Shutdown the receive side of the socket.
    shutdown_receive = implementation_defined,

    /// Shutdown the send side of the socket.
    shutdown_send = implementation_defined,

    /// Shutdown both send and receive on the socket.
    shutdown_both = implementation_defined
#else
    shutdown_receive = BOOST_ASIO_OS_DEF(SHUT_RD),
    shutdown_send = BOOST_ASIO_OS_DEF(SHUT_WR),
    shutdown_both = BOOST_ASIO_OS_DEF(SHUT_RDWR)
#endif
  };
  // ....
protected:
  /// Protected destructor to prevent deletion through this type.
  ~socket_base()
  {
  }
};

basic_socket

template <typename Protocol, typename Executor>
class basic_socket
  : public socket_base
{
  detail::io_object_impl<
    detail::reactive_socket_service<Protocol>, Executor> impl_;
};

这个对象是对套接字做的一个高级抽象，类似于Linux里万物都是socket，可以read and write，具体的上层协议本身是定义在Protocol里面，Protocol包含协议本身以及endpoint，也就是地址。

例如TCP的endpoint就是IP和地址，感觉如果未来KCP或者其他协议，可以直接定义一个新的endpoint类，增加多个channel就能实现很多东西，没必要用多个实际上的操作系统套接口？
这些实际操作系统的实现又落地在impl_里，impl_实际上是一个io_object，不同的系统会是不同的实现，但是保持统一的对外接口，大概如下图：

我们从最底下向上看，在每个操作系统底层其实有两个部分，service_和implement_，他们互为一组向上和向下的关系抽象，implement_是service_类里的一个struct，主要包含该操作系统API下的资源细节，通常包含套接口句柄，上层协议类型，以及其他的一些数据。
例如在Linux下，所有的socket都是用int类型的一个句柄，无论是Tcp还是文件还是Udp协议都是同一个句柄。所以implement_里存了套接口以及具体的Tcp还是Udp协议。
service_则是对操作系统的API提供的一层service抽象，将不同的操作系统的IO接口提供成统一的API，这里实现了创建、连接、收发消息和关闭连接。
而整个service_会被basic_socket用作操作系统无关的io对象的实现，而基于这些，basic_socket向上层提供了连接和异步的基本能力，创建、管理、异步等待等…
再进一步basic_stream_socket则是向上层提供了进一步的读写能力。

本次就先读到这里吧。

End.