zchuang

单连接比连接池性能好的原因，@shenxuebing 可以参考一下 #506 描述的内容，单连接模式可以同时处理多个请求，连接池只能一个连接处理一个请求 @TousakaRin 已经提到，这就决定了单连接模式小包场景下通过粘包功能可以提升系统吞吐量，但是面对糟糕的广域网环境容错性较差，而连接池模式小包无法实现粘包sys-read/write的占比会非常高，但面对广域网网络抖动具有很好容错。

目前提升带宽的方式有两种： - 第一种，建链模式为连接池模式，通过提升client端的线程并发来提升带宽。 - 第二种，建链模式为单连接模式，通过提升client端的进程数据来提升带宽。 这两种方式可以试试 @jinxing1985

这里有个示例，每个client channel初始化时传入不同的ip是不是就能解决了 ``` #include #include int main() { brpc::Channel channel1; brpc::Channel channel2; brpc::ChannelOptions options; // 方式1：直接传入多个 IP:Port（用逗号分隔） std::string ip1 = "192.168.1.10:8080"; if (channel1.Init(ip1.c_str(), "rr", &options) != 0) { LOG(ERROR)

@wwbmmm I've added ProgressiveTimeoutRead which is a ProgressiveReader wrapper class, when OnReadPart is invoked, it sets up a bthread_timer to monitor the idle timeout for the progressive socket reader. ProgressiveTimeoutRead...

> 是否还得配套内存管理相关的 API 设计？ 比如 RDMA 网络，用户可以 zcopy 发送 attachment，而不是把用户数据从用户 buffer copy 到 IOBuf 上再 zcopy 发送。 还有 RDMA 的单边操作，要怎么支持呢？ 1、应该不需要重新设计内存管理相关API，目前brpc rdma通信还没有做到zcopy发送attachment吧，该方案下推到transport层逻辑只做架构层面的改进，如果该方案被接纳后续可以在rdma transport子类上进行迭代升级zcopy发送到attachment的逻辑。 2、了解到RDMA单边操作只在rdma endpoint实现，上面改造方案应该不涉及，直接沿用原有的使用方式。

> 是的，每个协议可能还有一些特殊的使用方式。上层应该怎么提供接口呢？ 目前尝试实现一下rdma和tcp的子类transport，上层RPC流程模块依然调用的是原Socket类提供的函数，下层transport承接了类系统socket调用的方法部分，协议的特殊使用方式都可以下推到transport子类来实现，这样原Socket类改造成公共的Transport context角色了

> 这个改进建议的目的应该是把新增传输层协议的实现方式改为更集中拓展性更强的实现方式？ @Shaozheng528 嗯，是的，主要为了方便扩展新的通信传输层协议。 > [#207](https://github.com/apache/brpc/issues/207) 提到的 EndPoint 多形式，[#1560](https://github.com/apache/brpc/pull/1560) 应该实现了。 @chenBright 当前设计Transport接口都是从Socket已有方法抽取出来，并且和底层通信传输层关联性较高的部分，其中tcp endpoint和rdma endpoint均有被这些方法调用访问，为了把不同的endpoint调用拆分到对应的Transport实现类中。这里可以分别衍生出RdmaTransport和TcpTransport承接不同通信endpoint的调用，这样就能降低Socket类扩展新的传输协议成本，只需实现Transport接口部分即可完成新的传输协议对接，以下是对socket类下推方法抽出来的公共接口定义和类图部分可以参考。 Transport接口定义： ``` class Transport{ public: virtual void BeforeRecycled(Socket* socket) = 0; virtual int WaitAndReset(Socket* socket, int32_t...

> 最上面的Transport层接口是DoConnect/DoRead/DoWrite，为什么到这里变成了WaitAndReset/StartWrite/KeepWrite/DoWrite/OnInputEvent呢？感觉前者更合理些。后者耦合了太多逻辑，比如bthread操作、多路复用、健康检查等。 是的，当前方案只是将存在rdma宏定义的方法简单抽取出来，然后拆分到不同transport子类上，按照这个思路符合的方法只有WaitAndReset/StartWrite/KeepWrite/DoWrite/OnInputEvent这些，DoConnect/DoRead因为不需要对tcp和rdma调用做差异化处理，就没有下推。考虑到后续Transport支持更多通信协议的方式演进，目前也有些观点可以一起讨论下： 1. Transport层作为多协议打通抽象，需要抽象出更加合理接口层，同时需要考虑兼顾多个协议的方向演进，这块希望后续社区贡献者以及设备厂商共同努力推进。 2. Socket作为架构改造的切入点，后期可以作为上层应用的对接下层Transport的context角色来演进。 上面初步设计的Socket.h抽象接口还不完善，还需要跟社区一起详细讨论给出更优的Socket.h和transport层接口，一起推进共建多协议兼容的特性。 个人想法后续演进可以小步多次迭代方式来做，第一步，按照既定的socket方法下推方式，打通完善Socket-Transport调用流程，第二步，统一抽象Transport层更合理的公共接口，反补到上层调用。当然当前下推方式和方法， @wwbmmm @chenBright 大佬帮忙一起看看还有哪些方法更合适？ > 还有这里TransportWrapper的作用是什么呢？ TransportWrapper是Transport子类实例的包装类，这里会把不同协议Transport统一包装管理，包装类会协助公共方法与Transport子类方法绑定以及处理协议差异点逻辑的包装，上游socket只关注功能方法调用。以下是相关示例代码： transport_wrapper.h ```cpp namespace brpc { class Socket; class TransportWrapper { friend class Socket; public: #if...

> 这种方法看似简单，但实际实现可能会遇到问题，这些方法里面会访问Socket的私有成员，这就意味着具体Transport的实现里面，还要访问Socket的私有成员。这样并没有从根本上解决Socket和Transport解耦的问题，而且会引入新的问题——Socket里和Transport无关的一些代码被复制到多个Transport的实现代码里，增加了维护成本。 > > 因此，我不建议这种改法，我觉得可以这样： > > 将Socket里面，和特定transport相关的私有成员抽取出来到各自的transport中，如 按照这个方式我梳理了下感觉可行，结合个人的理解对需要下推的代码部分梳理，主要思路就是把RDMA宏定义代码段下推到Transport接口中并标识出所属源方法，然后对代码公共部分合并抽象出Transport接口。以下是具体的抽象结果和整理的改进想法，@wwbmmm 可以一起再探讨下看看。 **trasnport接口最新定义：** **源代码梳理和改进思路：**