动机

• 项目的动机是为了简化网络通信领域的应用程序代码开发。重点关注性能和易用性。

它是如何简化的？

• 传统上，网络API提供的方法暴露了对非常低级别的数据 byte arrays 的访问，而应用层更愿意使用携带有关应用程序状态的 struct 结构。

• Rust的 std::net 模块也不例外，它将解释 byte array 的责任留给开发者，开发者需要执行多个步骤从数组中提取单个字节帧，将其转换为所需的数据结构，同时跟踪剩余的字节并管理许多其他细节。这里的实现细节直接影响到应用程序的性能和可靠性。

• 即使在解决了这些细节之后，开发者还需要解决许多额外的任务，例如

  • 如何处理部分读取？
  • 我能否在不同线程之间分割读取和写入？
  • 如果我将读取分割到单独的线程，我能否使用单个线程来管理所有读取？
  • ...等等

• 这个库解决了上述挑战，同时提供了高性能的网络代码，而不限制应用程序如何使用API。

请告诉我更多

• 在非常高的层面上，主要概念基于以下两个 struct 结构

  • Clt - 这是一个网络客户端，可以发起连接
  • Svc - 这是一个网络服务，它监听端口并为每个建立的连接创建一个 Clt
  • 然后 Clt 和 Svc 都提供了 send 和 recv 方法，签名大致如下
    • Clt::send(msg: &T) 与 Clt::recv() -> T - 其中 T 是在实例化 Clt 和 Svc 时指定的泛型类型

• 本库有三个实现。点击单独的链接获取更多详情

  • 非阻塞 - 目前这个实现最为完整，其 send()/recv() 方法接受一个 timeout 参数。这允许应用程序开发者设置 io 等待限制。内部实现依赖于 spin 锁并提供等待，以提供最佳延迟性能，因为它不允许 OS 停止运行线程，这会带来显著的延迟惩罚。此实现适用于对 低延迟 性能要求较高的场景。
  • 阻塞 - 这个实现最简单易用，因为所有方法调用都是按顺序阻塞，直到操作完成。这种易用性是以性能和可扩展性为代价的。此实现适用于典型的网络负载。
  • 异步 - 这个实现基于 Rust 的 async/await tokio 框架，然而，在撰写本文时，Rust 的异步 API 正在经历稳定化，并且尚未在 stable 工具链上提供。