刚开始光看名字还以为是以前听说过的‘管道’，但这里其实应该是不一样的。在本端到远端的通信中需要走中转的时候，会走代理通道---proxychannel，但是在通道建立之前需要两端进行握手之类的协商，这时候会先创建一个协商通道，就是这个pipline。

这个 pipeline 是什么

softbus_proxychannel_pipeline.c 是一个通用的、轻量的点对点"控制通道"封装层,它本身不是代理通道,而是给"两个设备之间建一条直连的裸通道、在上面按类型收发控制消息"这件事提供的一个可复用框架。它做了四件事:

1. 基于 networking channel 之上建链:底层通过 TransOpenNetWorkingChannel 打开一条底层直连通道,session 名固定为 ohos.dsoftbus.inner.p2pchannel(),收发用 TransSendNetworkingMessage。networking channel 就是传输层最原始的"裸通道"(open/send/recv/close 四个事件,见 softbus_transmission_interface.h),不区分任何业务。

2. 异步请求-回调模型:TransProxyPipelineOpenChannel(requestId, networkId, option, callback) 发起打开,内部把请求和自增 requestId 绑定存入 PipelineChannelItem 链表,成功后通过 onChannelOpened/onChannelOpenFailed 回调返回。所有操作都投递到 looper 上串行处理(LOOPER_MSG_TYPE_OPEN_CHANNEL / DELEY_CLOSE / ON_CHANNEL_OPENED / ON_CHANNEL_OPEN_FAILED),避免并发问题。

3. 按类型多路复用:发送时在数据前加 4 字节类型头(MSG_TYPE_P2P_NEGO、MSG_TYPE_IP_PORT_EXCHANGE),收到数据时按类型派发给对应 listener()。

4. 通道生命周期管理:按 requestId / channelId / uuid 三种维度查找通道,带引用计数(TransProxyReuseByChannelId 加引用,ref 归零才真正关闭),支持 3 秒延迟关闭,便于复用同一条通道。

它和 proxychannel 的关系

一句话:它俩是"同一个目录下的两个东西",但不是同一条通道。

• proxychannel(softbus_proxychannel_*.c 那一组文件)是端到端的中继代理通道:本端和远端之间隔着中转设备,靠 control message 协商出转发路径,传输层走 ohos.dsoftbus.inner.proxychannel session,承载的是用户的业务数据。
• pipeline 用的是另一个 session(ohos.dsoftbus.inner.p2pchannel),是直连的、专门给控制面握手用的通道。

pipeline 的真实使用方不在 proxy 模块里,而在建链协商的地方:

而 proxy 模块自身只做了 pipeline 的初始化(softbus_proxychannel_transceiver.c:925),业务上并不依赖它——所以更准确地说,pipeline 是 proxychannel 的"邻居"而非"部件":两者共用同一套 networking channel 基础设施,proxychannel 负责多设备中继转发,pipeline 则专门服务"直连场景下的建链前控制面协商"(P2P 协商、TCP 直连的 IP/端口交换)。