分布式软总线传输模块

六bring个六

383人浏览 · 2026-07-21 20:53:30

六bring个六 · 2026-07-21 20:53:30 发布

一、总体架构概览

1.1 整体分层架构图

1.2 各层职责与层间交互方式

层级	职责	向下依赖
Session API 层	对上层业务提供统一的会话接口：创建服务端、打开会话、收发字节/消息/流/文件	通过 Channel 管理层打开通道
Session 管理层	会话服务器注册/注销，权限校验（UID/PID/tokenId），场景管理	通过 Channel 管理层获取通道
Channel 管理层	统一通道管理入口，通道 ID 分配，Lane 分配调度，回调路由，认证协商	分派到 4 种具体通道实现
Proxy/TCP Dir/UDP/Auth 通道层	各通道类型的具体实现，消息编解码，握手/保活，收发控制	依赖 Connection 层和 Lane 层
QoS 层	服务质量策略执行，流控，优先级管理	与通道层和 Lane 层交互
公共组件层	限流控制、Lane 待处理队列、QoS 信息维护	被通道层调用
IPC 层	SDK 进程与 Core 服务进程间通信	底层 Binder/Kernel
Connection 层	多介质连接管理（BLE/BR/WiFi/P2P）	底层网络硬件
Lane 层	物理链路抽象，实际数据收发	底层网络驱动

1.3 核心抽象概念

Session（会话）

定义在 session.h 中的 SessionParam 结构体。
是上层业务与传输层之间的逻辑连接抽象。一个 Session 代表一次"业务通信意图"，包含：sessionName（会话名）、peerSessionName（对端会话名）、peerDeviceId（对端设备 ID）、SessionAttribute（会话属性）、QoS 参数等。
Session 的生命周期独立于底层通道，一个 Session 可能对应多个底层 Channel（通道）。

Channel（通道）

共有 4 种类型：CHANNEL_TYPE_PROXY（代理通道）、CHANNEL_TYPE_TCP_DIRECT（TCP 直连通道）、CHANNEL_TYPE_UDP（UDP 通道）、CHANNEL_TYPE_AUTH（认证通道）。
Channel 是承载数据传输的管道，每个 Channel 有唯一的 channelId（通道 ID），通过 GenerateChannelId() 在 trans_channel_manager.c 中生成。
Channel ID 分配策略：Proxy 通道 ID 范围 [1025, 2048]，采用位图管理；TDC（TCP Direct Channel）/UDP/Auth 通道 ID 范围 (0x800, 0x7FFFFFFF]，采用递增分配。

Lane（传输通道）

Lane 是底层网络链路的抽象，定义在 LaneLinkType 枚举中：LANE_BR、LANE_BLE、LANE_P2P、LANE_WLAN_2P4G、LANE_WLAN_5G、LANE_ETH。
每个 Channel 都绑定到一个 Lane（通过 TransLaneMgrAddLane 在 trans_lane_manager.c 中注册），Lane 用 laneHandle（Lane 句柄）标识。
Lane 分为 QoS Lane 和普通 Lane：isQosLane 标志区分，QoS Lane 通过 TransFreeLaneByLaneHandle 释放，普通 Lane 通过 LnnFreeLane 释放。

四种通道的本质区别与选型考量

维度	Proxy Channel（代理通道）	TCP Direct Channel（TCP 直连通道）	UDP Channel（UDP 通道）	Auth Channel（认证通道）
传输协议	基于 Conn（连接）层的消息转发	直接 TCP Socket 连接	UDP + VTP（Fillp 可靠 UDP 协议）	基于 Conn 层或 Lane 层
主要用途	通用消息/字节传输、跨设备信息同步	大数据量传输、文件传输	实时音视频流传输	设备认证、密钥协商
NAT 穿透	需要 Proxy 代理转发（天然支持穿透）	需要 P2P/WiFi Direct 建立直连	通过 UDP 协商打洞	不涉及
性能特征	中等（经代理转发，有额外开销）	高（直连 TCP，无代理开销）	低延迟（UDP 实时性）	轻量，仅认证阶段使用
消息格式	ProxyMessageHead + JSON 载荷	TdcPacketHead（24 字节定长头）	VTP 协议帧 + 流数据包	cJSON 格式消息
握手过程	多步握手：物理连接 → 握手消息 → 握手 ACK	单步握手（TCP 三次握手）	UDP 协商交换	认证握手
适用场景	设备发现同步、小消息传递	文件传输、大数据同步	投屏、分布式音频、视频通话	首次建立信任关系

1.4 关键设计模式与架构思想

1. 会话与通道分离（Session-Channel Separation）

Session 是业务层概念，Channel 是传输层概念。一个 Session 可能对应多个 Channel（如 QoS 场景下可能同时存在数据通道和信令通道）。
这种分离使得上层业务不必关心底层传输细节，通道可以在不中断会话的情况下切换（如从 WiFi 切换到 BLE）。

2. 多通道并行协商（Multi-Channel Parallel Negotiation）

TransOpenChannel 在 trans_channel_manager.c 中根据 SessionParam 决定通道类型，核心逻辑在 TransCommonGetAppInfo 中根据 Session 属性确定通道策略。
支持异步通道打开（TransAsyncChannelOpenTaskManager），通过 Looper 消息循环实现超时重试和结果回调。

3. QoS 分级（QoS Classification）

QoS 通过 QosParam / QosTV 结构体传递，支持 QOS_TYPE_MIN_BW（最小带宽）、QOS_TYPE_MAX_LATENCY（最大延迟）、QOS_TYPE_MIN_LATENCY（最小延迟）等参数。
TransRequestQos 在通道层触发 QoS 请求，NotifyQosChannelOpened / NotifyQosChannelClosed 通知 QoS 层通道状态变化。

4. Pipeline 模式（管道模式）

Proxy 通道的 softbus_proxychannel_pipeline.c 实现了 Pipeline 架构：消息按类型（MSG_TYPE_P2P_NEGO、MSG_TYPE_IP_PORT_EXCHANGE）注册不同的 Listener（监听器），数据在 Pipeline 中按阶段流转。

5. 回调注册机制（Callback Registration）

IServerChannelCallBack 在 Core 端定义了统一的回调接口：OnChannelOpened、OnChannelClosed、OnChannelOpenFailed、OnDataReceived、OnQosEvent、OnChannelBind。
每个通道实现（Proxy/TCP/UDP/Auth）在初始化时注册相同的回调接口，确保事件通知的一致性。

6. 绑定请求防护（Bind Request Denial of Service Protection）

trans_bind_request_manager.c 实现了 DDoS 防护：在 60 秒检测周期内，同一 (mySocketName, peerSocketName, peerNetworkId) 三元组绑定失败超过 10 次，则触发 600 秒的拒绝服务保护期。

7. 场景驱动策略（Scenario-Driven Strategy）

softbus_scenario_manager.c 定义了 6 种业务场景类型：SM_MESSAGE_TYPE（消息）、SM_BYTE_TYPE（字节）、SM_FILE_TYPE（文件）、SM_VIDEO_TYPE（视频）、SM_AUDIO_TYPE（音频）、SM_RAW_TYPE（原始流）。
场景管理影响底层 WiFi/Lane 驱动策略的决策，如 NotifyWifiByAddScenario / NotifyWifiByDelScenario。

二、完整数据流（以可靠数据传输为例）

序号   步骤                         关键函数 / 模块                   状态变化
───────────────────────────────────────────────────────────────────────────────────

①  SDK 端发起建链请求
    Client: OpenSession() ────► IPC ────► Server: TransOpenSession()
    构建 SessionParam（含 sessionName, peerSessionName, peerDeviceId, attr, QoS）

②  Core 端校验与准备
    TransOpenSession() → TransSessionServerIsExist() 校验会话服务器存在
                      → TransOpenChannel(param, transInfo)
                      → TransCommonGetAppInfo() 填充 AppInfo
                      → TransAddSocketChannelInfo() 创建 Socket-Channel 绑定

③  Lane 分配
    TransOpenChannel() → TransGetLaneInfo() / TransAsyncGetLaneInfo()
    根据优先链路列表、设备可达性选择最优 Lane（LANE_P2P / LANE_WLAN / LANE_BLE / LANE_BR）
    获取 laneHandle 和 LaneConnInfo

④  通道创建（以 Proxy 为例）
    TransOpenChannel() → TransProxyOpenProxyChannel(appInfo, connInfo, &channelId)
    创建 ProxyChannelInfo，设置 channelId, status=CONNECTING
    进入握手流程：TransProxyHandshake() → TransProxyPackHandshakeMsg()

⑤  握手与认证协商
    TransProxyOpenConnChannel() → 底层 Conn 层建立连接
    握手消息交换：PROXYCHANNEL_MSG_TYPE_HANDSHAKE → PROXYCHANNEL_MSG_TYPE_HANDSHAKE_ACK
    认证协商：TransNegotiateSessionKey() → TransAuthNegoTaskManager()
    如果认证超时(10s)，通过 TransReqAuthPendingList 管理待处理认证请求

⑥  通道就绪
    TransProxyOpenProxyChannelSuccess(channelId)
    状态 → PROXY_CHANNEL_STATUS_COMPLETED
    通过 IServerChannelCallBack.OnChannelOpened() 回调通知 SDK

⑦  数据传输（可靠字节传输）
    SDK: SendBytes() → ClientTransChannelSendBytes()
    根据 channelType 路由到：
    - CHANNEL_TYPE_PROXY: TransProxyChannelSendBytes()
      → TransProxyPostSessionData() → 分包切片 → TransProxyTransDataSendMsg()
      → TransProxyTransSendMsg() → Conn 层发送
    - CHANNEL_TYPE_TCP_DIRECT: TransTdcSendBytes()
      → TransTdcPostBytes() → TdcPacketHead 封装 → TCP Socket 发送

⑧  接收端处理
    Proxy: TransProxyOnMessageReceived() → TransProxyParseMessage()
      → TransProxyUnpackFastData() → TransOnNormalMsgReceived()
      → TransProxyOnMsgReceived() → IServerChannelCallBack.OnDataReceived()

⑨  QoS 动态调整
    TransRequestQos(channelId, chanType, appType, quality)
    → QosReportExecute() → SetDefaultQdisc()
    根据流控统计（StreamSendStats）动态调整发送策略

⑩  拆链
    SDK: CloseSession() → ClientTransCloseChannel()
    → CHANNEL_TYPE_PROXY: TransProxyCloseProxyChannel() → TransProxyPostDisConnectMsgToLoop()
    → CHANNEL_TYPE_TCP_DIRECT: TransTdcCloseChannel() → CloseTcpDirectFd()
    释放 Lane: TransFreeLaneByLaneHandle() / LnnFreeLane()
    通知上层: IServerChannelCallBack.OnChannelClosed()

三、分模块详解

任务1：会话管理（Session Layer）

核心文件：

trans_session_service.c — 会话服务入口
trans_session_manager.c — 会话服务器注册管理
softbus_scenario_manager.c — 场景管理

会话生命周期

会话与通道的映射关系

SessionServer 结构体（在 trans_session_manager.h 中定义）维护了 sessionName → pkgName + uid + pid 的映射。SocketWithChannelInfo 结构体（在 trans_lane_manager.c 中定义）维护了 sessionName + sessionId → channelId + channelType + laneHandle + CoreSessionState 的映射。

核心状态机 CoreSessionState：

场景管理如何影响通道策略

ScenarioManager 定义了 6 种业务类型（消息/字节/文件/视频/音频/原始流），通过 AddScenario(localMac, peerMac, pid, businessType) 向底层 WiFi 驱动注册场景。底层驱动根据场景类型优化 WiFi 参数（如调整 Beacon 间隔、DTIM 周期等），从而影响通道的时延和吞吐特性。

任务2：通道管理框架（Channel Management Framework）

核心文件：

trans_channel_manager.c — 通道管理总入口
trans_channel_callback.c — 回调注册与分发
trans_lane_manager.c — Lane 分配与绑定
trans_link_listener.c — 链路事件监听
trans_auth_negotiation.c — 认证协商
trans_bind_request_manager.c — 绑定请求管理

统一管理接口

TransChannelInit() 是初始化入口，按顺序初始化所有子系统：

TransLaneMgrInit() → TransSocketLaneMgrInit() → TransAuthInit() → TransProxyManagerInit()
→ TransTcpDirectInit() → TransUdpChannelInit() → TransBindRequestManagerInit()
→ TransReqLanePendingInit() → TransAsyncReqLanePendingInit() → TransReqAuthPendingInit()
→ TransAuthWithParaReqLanePendingInit() → TransFreeLanePendingInit() → TransChannelResultLoopInit()
→ ReqLinkListener()

核心接口：

TransOpenChannel(SessionParam, TransInfo) — 统一通道打开入口
TransCloseChannel(sessionName, channelId, channelType) — 统一通道关闭
TransSendMsg(channelId, channelType, data, len, msgType) — 统一消息发送
TransRequestQos(channelId, chanType, appType, quality) — QoS 请求

通道 ID 分配逻辑

Proxy 通道 ID: [1025, 2048]，使用位图（bitmap）管理，支持回收复用
TDC/UDP/Auth 通道 ID: (0x800, 0x7FFFFFFF]，使用递增计数器

GenerateChannelId(isTdcChannel):
  isTdcChannel == true  → GenerateTdcChannelId()  (递增，g_allocTdcChannelId++)
  isTdcChannel == false → GenerateProxyChannelId() (位图查找空闲位)

Lane 分配逻辑

TransLaneManager 维护两个核心列表：

g_channelLaneList — Channel ↔ Lane 的映射关系
g_socketChannelList — Session ↔ Channel 的映射关系

Lane 分配通过 TransGetLaneInfo() / TransAsyncGetLaneInfo() 调用底层 LNN 的 Lane 接口，根据 LanePreferredLinkList（优先链路列表）选择最优链路。TransLanePendingCtl 管理待处理的 Lane 请求队列。

认证协商流程和状态机

TransAuthNegotiation 管理认证协商过程：

1. TransNegotiateSessionKey(authConnInfo, channelId, peerNetworkId)
   → 发起 AuthRequest，获取 authRequestId
2. TransAddAuthReqToPendingList(authRequestId)
   → 加入待处理列表，设置超时 10 秒，每 100ms 检查一次状态
3. 认证成功 → TransDelAuthReqFromPendingList()
   → TransProxyNegoSessionKeySucc(channelId)
4. 认证失败/超时 → TransDelAuthReqFromPendingList()
   → TransProxyNegoSessionKeyFail(channelId, errCode)

任务3：Proxy 通道（Proxy Channel）

核心文件：

softbus_proxychannel_manager.c — Proxy 通道管理器
softbus_proxychannel_network.c — 网络层通知
softbus_proxychannel_message.c — 消息编解码
softbus_proxychannel_callback.c — 回调处理
softbus_proxychannel_control.c — 握手/保活控制
softbus_proxychannel_pipeline.c — Pipeline 管道
softbus_proxychannel_session.c — 会话数据收发
softbus_proxychannel_transceiver.c — 收发器

为何需要 Proxy 模式

Proxy 通道的核心价值在于跨设备通信代理，这是 OpenHarmony 分布式软总线的核心能力：

NAT 穿透：当两台设备不在同一局域网时，通过软总线服务进程作为代理转发数据
多介质透明切换：Proxy 通道基于 Conn 层，可以在 BLE/BR/WiFi/P2P 之间透明切换，上层业务无感知
连接复用：同一个物理连接（connId）可以承载多个 Proxy 通道（通过 myId/peerId 区分）

Pipeline 设计

TransProxyPipeline 在 softbus_proxychannel_pipeline.c 中实现了 P2P 通道的 Pipeline 模式：

Pipeline 消息类型：

MSG_TYPE_P2P_NEGO (0xABADBEEF) — P2P 协商消息
MSG_TYPE_IP_PORT_EXCHANGE — IP 端口交换消息

消息编解码

Proxy 通道消息格式：

消息类型（MsgType 枚举）：

PROXYCHANNEL_MSG_TYPE_HANDSHAKE — 握手请求
PROXYCHANNEL_MSG_TYPE_HANDSHAKE_ACK — 握手应答
PROXYCHANNEL_MSG_TYPE_HANDSHAKE_AUTH — 认证握手
PROXYCHANNEL_MSG_TYPE_RESET — 重置
PROXYCHANNEL_MSG_TYPE_KEEPALIVE — 保活
PROXYCHANNEL_MSG_TYPE_KEEPALIVE_ACK — 保活应答

会话绑定与收发控制

TransProxyPostSessionData() 在 softbus_proxychannel_session.c 中处理数据发送：

SessionPktType → ProxyPacketType 映射:
  TRANS_SESSION_BYTES      → PROXY_FLAG_BYTES
  TRANS_SESSION_MESSAGE    → PROXY_FLAG_MESSAGE
  TRANS_SESSION_FILE_*     → PROXY_FILE_*_FRAME
  TRANS_SESSION_ASYNC_MSG  → PROXY_FLAG_ASYNC_MESSAGE

数据分包采用 PacketFastHead + SliceFastHead + SessionHead 的三级头部结构，支持大数据的切片传输。

任务4：TCP Direct 通道（TCP Direct Channel）

核心文件：

trans_tcp_direct_manager.c — TCP 直连管理器
trans_tcp_direct_listener.c — TCP 监听器
trans_tcp_direct_message.c — 消息处理
trans_tcp_direct_p2p.c — P2P 介质
trans_tcp_direct_wifi.c — WiFi 介质
trans_tcp_direct_auth.c — 认证

TCP 直连建立流程

认证过程

TCP 直连的认证依赖 TransTcpDirectAuth 模块，通过 AuthHandle 获取加密标志和密钥。TdcPacketHead 中的 flags 字段携带认证元数据 FLAG_AUTH_META，标识是否需要认证，以及 AUTH_CONN_SERVER_SIDE 标识服务端角色。

消息格式

┌──────────────┬────────┬──────────┬────────┬──────────┐
│  magicNumber │ module │   seq    │ flags  │ dataLen  │
│  (4 bytes)   │(4 bytes)│(8 bytes) │(4 bytes)│(4 bytes) │
├──────────────┴────────┴──────────┴────────┴──────────┤
│                    Payload Data                        │
└───────────────────────────────────────────────────────┘
总头部: DC_MSG_PACKET_HEAD_SIZE = 24 bytes

与 Proxy 通道的性能与适用场景差异

维度	Proxy Channel	TCP Direct Channel
延迟	较高（经代理转发）	较低（直连）
吞吐	受代理进程限制	接近线速
NAT 穿透	天然支持	需要 P2P 打洞
连接建立速度	较快（复用现有连接）	较慢（需要 TCP 握手+认证）
适用场景	小消息、设备发现、信令	大文件传输、批量数据同步
超时管理	19s 握手超时	19s 握手超时（HANDSHAKE_TIMEOUT）

任务5：UDP 通道与协商（UDP Negotiation）

核心文件：

trans_udp_negotiation.c — UDP 协商
trans_udp_channel_manager.c — UDP 通道管理

UDP 协商机制

UDP 通道的建立需要经过协商交换过程：

发起协商：TransOpenUdpChannel(appInfo, connOpt, &channelId) — 创建 UDP 通道，发起协商请求
协商交换：trans_udp_negotiation_exchange.c — 通过 Auth 通道交换 UDP 连接参数（IP、端口、密钥等）
通道就绪：协商成功后，建立 VTP（Fillp）连接，通知上层 OnChannelOpened
失败处理：NotifyUdpChannelOpenFailed() / SendReplyErrInfo() 发送错误信息

通道管理方式

UDP 通道 ID 使用 64 位位图（g_channelIdFlagBitsMap）管理，支持最多 64 个并发 UDP 通道。ReleaseUdpChannelId() 负责回收。

UDP 通道在实时音视频场景下的定位

UDP 通道是实时音视频流的首选传输通道：

基于 VTP（Fillp 可靠 UDP 协议栈），在 UDP 之上提供可靠性保证
支持 STREAM_TYPE 区分：RAW_STREAM（原始流）、COMMON_VIDEO_STREAM（视频流）、COMMON_AUDIO_STREAM（音频流）、VIDEO_SLICE_STREAM（视频切片流）
与 ScenarioManager 联动，通过 NotifyWifiByAddScenario(SM_VIDEO_TYPE/SM_AUDIO_TYPE, pid) 优化 WiFi 参数

任务6：认证通道（Auth Channel）

核心文件：

trans_auth_manager.c — 认证管理器
trans_auth_message.c — 认证消息编解码

认证通道在传输安全中的角色

Auth Channel 是传输安全的基础设施：

首次认证：设备间首次建立信任关系时，通过 Auth Channel 交换认证信息（cJSON 格式）
密钥协商：TransOpenAuthMsgChannel() 创建认证通道，TransSendAuthMsg() 发送认证消息
会话密钥分发：认证成功后，通过 TransNotifyAuthDataSuccess() 通知上层，后续数据传输使用协商的会话密钥

与其他通道的联动

Auth Channel → 认证成功 → 生成 SessionKey
                              ↓
              Proxy Channel: TransProxyGetSessionKeyByChanId()
              TCP Direct:    GetCipherFlagByAuthId()
              UDP Channel:   协商交换中携带 SessionKey

AuthChannelInfo 结构体维护了 authId → channelId → connOpt 的映射，支持通过 TransAuthGetConnOptionByChanId() 获取连接选项，通过 TransAuthGetConnIdByChanId() 获取连接 ID。

任务7：服务质量（QoS）

核心文件：

softbus_qos.c — QoS 核心
trans_channel_limit.c — 限流控制
trans_qos_info.c — QoS 信息维护

QoS 策略如何在通道层面生效

通道打开时注入 QoS：NotifyQosChannelOpened(ChannelInfo) — 将 QoS 参数传递给底层 Lane
运行时 QoS 请求：TransRequestQos(channelId, chanType, appType, quality) — 动态调整
QoS 事件通知：IServerChannelCallBack.OnQosEvent(pkgName, QosParam) — 将 QoS 事件上报给上层
流控统计：TransStreamStats(channelId, channelType, StreamSendStats) — 上报流统计信息（帧耗时分布、发送码率分布）
Ripple 统计：TransRippleStats(channelId, channelType, TrafficStats) — 上报流量统计

与 trans_channel_limit.c 的配合

trans_channel_limit.c 提供通道级别的访问控制，如 CheckSessionNameValidOnAuthChannel() 校验认证通道上的会话名有效性，防止未授权访问。

与 trans_qos_info.c 的配合

GetExtQosInfo() 从 SessionParam 中提取 QoS 扩展信息（QosInfo），用于 Lane 分配时的链路选择决策。

任务8：通道公共组件（Common）

限流控制（trans_channel_limit.c）

CheckSessionNameValidOnAuthChannel() 提供认证通道上的会话名校验，防止恶意会话名注册。

待处理 Lane 控制（trans_lane_pending_ctl.c）

管理 Lane 请求的异步处理队列：

TransGetLaneInfo() — 同步获取 Lane 信息
TransAsyncGetLaneInfo() — 异步获取 Lane 信息（带 callingTokenId 和 timeStart）
TransGetLaneInfoByOption() — 根据 LaneRequestOption 获取 Lane
TransCancelLaneItemCondByLaneHandle() — 取消 Lane 请求
TransFreeLaneByLaneHandle() — 释放 Lane

QoS 信息维护（trans_qos_info.c）

GetExtQosInfo() 从 SessionParam 的 qos[] 数组中提取 QoS 扩展信息，填充 QosInfo 和 AllocExtendInfo 结构，用于 Lane 层的链路质量评估。

任务9：SDK 端传输实现（Client-side Transmission）

核心文件：

client_trans_channel_manager.c — SDK 端通道管理
client_trans_session_service.c — SDK 端会话服务
client_trans_session_manager.c — SDK 端会话管理
vtp_stream_socket.h — VTP 流 Socket
vtp_instance.h — VTP 实例

SDK 侧与 Core 侧架构对比

维度	Core 端 (Server)	SDK 端 (Client)
进程模型	软总线服务进程（独立进程）	业务 App 进程内
Session 管理	`TransSessionManager` 管理全局 SessionServer 列表	`ClientTransSessionManager` 轻量化管理
通道管理	管理所有设备的通道	仅管理本进程相关的通道
Channel 初始化	初始化全部 4 种通道 + Lane + 待处理队列	初始化 TCP/Proxy/UDP/Auth + 统计
IPC 通信	通过 `TransClientProxy` 接收 SDK 请求	通过 `TransServerProxy` 发送请求到 Core
Stream/File 传输	不涉及	包含 VTP 实例、流打包/解包、文件传输
QoS	全局 QoS 策略执行	客户端 QoS 统计上报

轻量化策略

SDK 端的 Session 管理是轻量化的：

不维护全局 SessionServer 列表，只关心本进程的会话
通道管理通过 ClientTransChannelInit() 按需初始化
ClientTransCloseChannel() 根据 channelType 直接路由到对应关闭函数

Stream/File 传输中的 VTP 实例

VTP（Fillp 可靠 UDP 协议栈）是 SDK 端 Stream 传输的核心：

VtpInstance (单例, per pkgName)
  ├── InitVtp(pkgName) — 初始化 Fillp 协议栈
  ├── DestroyVtp(pkgName) — 销毁 Fillp 协议栈
  ├── PreSetFillpCoreParams() — 预设核心参数
  │   (SEND_CACHE=500, RECV_CACHE=500, KEEP_ALIVE_TIME=300000ms)
  └── UpdateSocketStreamCount() — 更新 Socket 流计数

VtpStreamSocket
  ├── CreateClient() / CreateServer()
  ├── Connect() — 建立 VTP 连接
  ├── Send(unique_ptr<IStream>) — 发送流数据
  ├── SetOption() / GetOption() — 配置 Fillp 参数
  │   (SEND_CACHE, RECV_CACHE, PACKET_SIZE, REDUNANCY_SWITCH, REDUNANCY_LEVEL...)
  ├── Encrypt() / Decrypt() — 加密/解密
  └── SetStreamListener() — 设置流监听器

流打包解包原理

发送端:                             接收端:
StreamData → StreamPacketizer       RawStreamData → StreamDepacketizer
  │ 打包为 IStream                     │ 解析包头
  ▼                                   ▼
VtpStreamSocket::Send()            VtpStreamSocket 回调
  │ 加密                             │ 解密
  ▼                                   ▼
Fillp 发送                          Fillp 接收

StreamPacketizer 负责将应用层数据打包为 IStream 对象，添加 StreamPacketHeader 包头；StreamDepacketizer 负责解析包头并还原为原始数据。StreamMsgManager 管理消息队列和可靠性保证。

四、总结

设计优势

分层解耦：Session（会话）与 Channel（通道）分离，上层业务不感知底层传输介质切换，实现了良好的关注点分离。
多通道并行：4 种通道类型（Proxy/TCP Direct/UDP/Auth）各司其职，覆盖了从轻量消息到大数据流再到实时音视频的全场景需求。
Pipeline 架构：Proxy 通道的 Pipeline 设计使得消息处理阶段可插拔、可扩展。
统一回调机制：IServerChannelCallBack 统一了所有通道类型的事件通知，简化了上层集成。
Lane 抽象：将底层网络链路（BLE/BR/P2P/WiFi/ETH）抽象为 Lane，使得通道层可以透明地在不同介质间切换。
QoS 分级：从 Session 创建阶段就注入 QoS 参数，贯穿整个数据传输生命周期。
DDoS 防护：绑定请求管理器内置了频率限制，防止恶意请求洪泛。
异步超时管理：通过 Looper 消息循环实现通道打开超时检测和重试，避免阻塞。

复杂点

多通道类型协调：4 种通道类型各有独立的状态机和生命周期管理，协调复杂度高。
认证协商的异步性：认证过程涉及多轮消息交换，超时和重试逻辑增加了状态管理的复杂性。
Lane 分配策略：Lane 的选择需要综合考虑设备可达性、链路质量、QoS 需求、场景类型等多个维度。
SDK/Core 双端一致性：SDK 端和 Core 端的通道管理需要保持接口一致性和状态同步，IPC 通信增加了延迟和复杂度。
Proxy 通道的握手状态机：ProxyChannelStatus 包含 8 种状态（PYH_CONNECTED → CONNECTING → HANDSHAKEING → KEEPLIVEING → COMPLETED 及各超时状态），状态转换条件复杂。

演进方向

通道类型统一化：当前 Proxy 和 TCP Direct 通道在消息格式和握手流程上差异较大，未来可考虑统一消息框架，减少代码重复。
智能 Lane 选择：引入基于机器学习的链路质量预测，根据历史统计数据动态选择最优 Lane。
QUIC 协议引入：在 UDP 通道中引入 QUIC 协议替代当前的自研 VTP/Fillp 协议，获得更好的拥塞控制和多路复用能力。
零拷贝优化：在大数据传输路径上引入零拷贝技术，减少内存拷贝开销。
通道池化：对频繁创建/销毁的 Proxy 通道实现连接池化，降低连接建立延迟。
更细粒度的 QoS：当前 QoS 参数相对粗粒度，可引入 per-flow（每流）级别的 QoS 控制，支持更精细的带宽分配和优先级调度。
安全增强：Auth Channel 可引入基于 TEE（可信执行环境）的密钥管理，提升密钥存储和协商的安全性。

开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

鸿蒙三方库 | harmony-utils之WantUtil应用跳转详解

开源鸿蒙跨平台开发者社区

OpenHarmony API23 四层HAR+HSP分层架构实战

很多鸿蒙初学者、在校毕设项目、小型Demo 全部采用单 Entry 单体开发，看似写得快，实则隐患极大：所有工具、页面、业务逻辑全部堆在 entry，代码极度混乱无分层、无规范，复用性为 0，换项目必须重写页面不做资源回收，极易出现内存泄漏、页面卡顿全部页面打包入主包，安装包体积臃肿、冷启动慢多人开发冲突严重，完全不具备工程化能力为此本文基于搭建一套四层单向依赖架构，结合 HAR 静态复用 + H

开源鸿蒙跨平台开发者社区

鸿蒙三方库 | harmony-utils之KvUtil键值型数据库操作详解

开源鸿蒙跨平台开发者社区

所有评论(0)

查看更多评论

六bring个六

@Excalibur6

已为社区贡献14条内容

分布式软总线传输模块

六bring个六

一、总体架构概览

1.1 整体分层架构图

1.2 各层职责与层间交互方式

1.3 核心抽象概念

Session（会话）

Channel（通道）

Lane（传输通道）

四种通道的本质区别与选型考量

1.4 关键设计模式与架构思想

1. 会话与通道分离（Session-Channel Separation）

2. 多通道并行协商（Multi-Channel Parallel Negotiation）

3. QoS 分级（QoS Classification）

4. Pipeline 模式（管道模式）

5. 回调注册机制（Callback Registration）

6. 绑定请求防护（Bind Request Denial of Service Protection）

7. 场景驱动策略（Scenario-Driven Strategy）

二、完整数据流（以可靠数据传输为例）

三、分模块详解

任务1：会话管理（Session Layer）

会话生命周期

会话与通道的映射关系

场景管理如何影响通道策略

任务2：通道管理框架（Channel Management Framework）

统一管理接口

通道 ID 分配逻辑

Lane 分配逻辑

认证协商流程和状态机

任务3：Proxy 通道（Proxy Channel）

为何需要 Proxy 模式

Pipeline 设计

消息编解码

会话绑定与收发控制

任务4：TCP Direct 通道（TCP Direct Channel）

TCP 直连建立流程

认证过程

消息格式

与 Proxy 通道的性能与适用场景差异

任务5：UDP 通道与协商（UDP Negotiation）

UDP 协商机制

通道管理方式

UDP 通道在实时音视频场景下的定位

任务6：认证通道（Auth Channel）

认证通道在传输安全中的角色

与其他通道的联动

任务7：服务质量（QoS）

QoS 策略如何在通道层面生效

与 trans_channel_limit.c 的配合

与 trans_qos_info.c 的配合

任务8：通道公共组件（Common）

限流控制（trans_channel_limit.c）

待处理 Lane 控制（trans_lane_pending_ctl.c）

QoS 信息维护（trans_qos_info.c）

任务9：SDK 端传输实现（Client-side Transmission）

SDK 侧与 Core 侧架构对比

轻量化策略

Stream/File 传输中的 VTP 实例

流打包解包原理

四、总结

设计优势

复杂点

演进方向

所有评论(0)

温馨提示：您尚未绑定手机号

六bring个六