标签：报告 融合 基础 设计 可靠传输 code 相对 裁剪 session
《鸿蒙操作系统分布式软总线技术》
调研报告
朱浩
SA20225646
目 录
1 HarmonyOS概述 -----------------------------------------------------------------3
1.1 系统定义---------------------------------------------------------------------3
1.2 系统架构---------------------------------------------------------------------3
1.3 分布式技术特性------------------------------------------------------------3
2 分布式软总线模块解析---------------------------------------------------------4
2.1分布式软总线的功能-------------------------------------------------------4
2.2分布式软总线的原理-------------------------------------------------------4
2.3分布式软总线源码分析----------------------------------------------------6
2.3.1 discover部分------------------------------------------------------------7
2.3.2 authmanager部分 ------------------------------------------------------8
2.3.3 trans_service部分------------------------------------------------------9
2.3.4 软总线代码执行流程------------------------------------------------11
3 编译、运行软总线模块--------------------------------------------------------12
4 参考资料--------------------------------------------------------------------------18
1 HarmonyOS概述
1.1 系统定义
HarmonyOS是一款“面向未来”、面向全场景（移动办公、运动健康、社交通信、媒体娱乐等）的分布式操作系统。在传统的单设备系统能力的基础上，HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备。
1.2 系统架构
HarmonyOS整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。HarmonyOS技术架构如下所示。
图1：鸿蒙系统的架构层次
1.3分布式技术特性
HarmonyOS中，多种设备之间能够实现硬件互助、资源共享，依赖的关键技术包括分布式软总线、分布式设备虚拟化、分布式数据管理、分布式任务调度等。
图2：鸿蒙系统所依赖的分布式技术
2 分布式软总线模块解析
2.1分布式软总线的功能
在鸿蒙系统中，分布式软总线是手机、平板、智能穿戴、智慧屏、车机等分布式设备的通信基座，为设备之间的互联互通提供了统一的分布式通信能力，为设备之间的无感发现和零等待传输创造了条件。依托软总线技术，可以轻松实现多台设备共同协作完成一项任务，任务也可以由一台设备传递至另一台设备继续执行。对于用户而言，无需关注多台设备的组网，软总线可以实现自发现、自组网。对于开发者而言，也无需针对不同设备开发不同版本的软件、适配不同的网络协议和标准规范。
2.2分布式软总线的原理
相较于传统计算机中的硬总线，鸿蒙系统中的分布式软总线是一条虚拟的、“无形”的总线。可以连接同处于一个局域网内部的所有鸿蒙设备（1+8+N，如下图所示），并且具有自发现、自组网、高带宽和低时延等特点。
图3：软总线连接1+8+N设备
除了连接处于同样网络协议中的硬件设备，软总线技术还支持对不同协议的异构网络进行组网。传统场景下，需要蓝牙传输的两台设备必须都具有蓝牙，需要WiFi传输的设备必须都具有WiFi。而蓝牙/WiFi之间是无法进行数据通信的。软总线提出蓝牙/WiFi融合网络组网技术（架构如下图所示），解决了不同协议设备进行数据通信的问题。使得多个鸿蒙设备能够自动构建一个逻辑全连接网络，用户或者业务开发者无需关心组网方式与物理协议。
图4：软总线中异构网络组网方案
传统协议的传输速率差异较大，多设备交互式时延和可靠性也难以保证。软总线传输提出三个目标：高带宽、低时延、高可靠。相较于传统网络的7层模型，软总线提出了4层的“极简协议”（如下图所示），将中间的4层协议精简为一层以提升有效载荷，有效带宽提升20%。设备间基于UDP协议进行数据传输，摒弃传统滑动窗口机制，实现丢包快速回复，且具有智能网络变化感知功能，可以自适应流量控制和拥塞控制。
图5：软总线提出“极简协议”
2.3分布式软总线源码分析
注意：笔者所分析源码为软总线模块部分，如需获取软总线源码，请访问网址：https://gitee.com/openharmony/communication_services_softbus_lite。浏览整个软总线组件的源码，可知其分为以下4个单元（代码结构如下图所示）：
1，discover：提供基于COAP协议的设备发现机制；
2，authmanager：提供设备认证机制和知识库管理功能；
3，trans_service：提供身份验证和数据传输通道，
4，os_adapter：检测运行设备性能，决定部分功能是否执行。
图6：分布式软总线组件源码整体架构
由于整个软总线组件代码量较多（笔者粗略估算在5000行上下），为表述清晰，部分细节可能会作适当忽略（如忽略各头文件）。因os_adapter部分并非软总线模块的功能重点，此处将不做讨论（简要说明，os_adapter的功能是判断当前运行设备的性能，以决定部分功能是否启用，如多线程机制）。本报告采用图文结合的形式，先对3个核心部分（discovery、authmanager、trans_service）的功能进行简要概述，最后将各单元聚合进行整体代码执行流程的分析。
2.3.1 discover部分
作为鸿蒙OS分布式软总线重要组成单元，discovery单元提供了基于coap（Constrained Application Protocol，受限应用协议，RFC7252）协议的设备发现机制。为什么使用coap协议？是因为考虑到运行harmonyOS的设备除了硬件性能较好的手机、电脑等设备外，还有资源受限的物联网设备，这些设备的ram、rom相对较小。coap协议支持轻量的可靠传输，采用coap协议，可以扩大组网的范围。
discovery的实现前提是确保发现端设备与接收端设备在同一个局域网内且能互相收到对方的报文。流程为以下三步：
1，发现端设备，使用coap协议在局域网内发送广播；
2，接收端设备使用PublishService接口发布服务，接收端收到广播后，发送coap协议单播给发现端；
3，发现端设备收到回复单播报文,更新设备信息。
discovery部分代码由两部分组成（目录如下图所示）。其中coap部分是coap协议的封装实现，discovery_service是基于coap协议的设备间发现流程的实现。
图7：discovery部分源码目录结构
coap目录中：
（1）coap_def.h：定义coap协议包的格式、报文结构，且使用UDP协议传输；
（2）coap_adapter.c：实现coap协议通讯双方使用的编码、解码函数；
（3）coap_socket.c：实现coap包的发现、接收服务；
（4） Coap_discovery.c：实现基于coap协议的设备发现功能。本文件定义了socket通讯过程，有兴趣的读者可以深入阅读。后文也会对本文件关键函数流程做分析。
discovery_service目录中：
（5）comman_info_manager.h：定义了鸿蒙系统当前支持的设备类型与级别；
（6）Discovery_service.c：实现了设备暴露、发现和连接流程。这里需要注意的是，考虑到同一局域网下，主设备发出连接请求广播后，多个物联网设备都会回复单播应答报文从而造成信道冲突。为避免此情况发生，每个物联网设备均维护一套信号量机制，实现多设备的有序等待。
2.3.2 authmanager部分
作为软总线代码执行流程中的第二部分：authmanager单元提供了设备认证机制。设备通过加密和解密的方式，互相建立信任关系，确保在互联场景下，用户数据在对的设备之间进行流转，实现用户数据的加密传输。软总线中定义加密和解密算法的内容在trans_service/utils/aes_gcm.h中，authmanager中的处理流程如下图所示：
图8：加密传输建立设备间信任关系
authmanager单元代码目录结构如下图所示：
图9：authmanager代码结构
authmanager目录中：
（1）auth_conn.c：提供发送、接收、认证和获取密钥的功能；
（2）auth_interface.c：管理会话、链接、密钥节点，提供增删改查功能；
（3）msg_get_deviceid.c：以cJSON格式获取各个设备的信息，包括设备id、链接信息、设备名、设备类型等；
（4）bus_manager.c：创建不同的listen，用以监听系统上有哪些device并创建新的device节点，以及节点数据的处理。bus_manager.c主要由discovery单元调用，通过判断本文件中flag标志位决定是否启动总线（start_bus()函数）或关闭当前总线（stop_bus()函数）。discovery调用后，bus_manager执行流程如图10：
（5）wifi_auth_manager.c：实现了链接管理和数据接收功能。
图10：bus_manager.c中函数执行流程图
2.3.3 trans_service部分
经过第一阶段协议确定、设备发现过程，以及第二阶段设备链接过程，软总线模块执行到了第三阶段：数据传输阶段，即目录中trans_service单元。trans_service模块依赖于harmonyOS提供的网络socket服务，向认证模块提供认证通道管理和认证数据的收发；向业务模块提供session管理和基于session的数据收发功能，并且通过GCM模块的加密功能提供收发报文的加密/解密保护。如下图所示为trans_service模块在系统架构中的位置：
图11：trans_service模块在OS结构中的位置
阅读本单元部分源码，可知数据传输单元的源码目录如下：
图12：trans_service模块源码目录
在libdistbus目录中，各源码文件的实现功能均已给出（如上图12），其中需要注意的是，软总线启动后，设备在发现阶段基于coap协议使用udp数据报进行通讯。当设备认证通过，确认连接后，将会使用TCP协议进行更加安全可靠的通讯。同发现阶段避免多设备同时向主机回复单播报文产生信道冲突一样，这里也维护了一套信号量机制避免多设备互连时产生资源冲突。对这部分感兴趣的读者可以继续阅读trans_lock.c文件，这里不再赘述。
2.3.4 软总线代码执行流程
通过对3个核心组成部分的源码进行简单的分析，相信读者已经对软总线的具体结构和各部分功能有了一定了解。下面，我们将融合这3个单元，对软总线启动后的源码执行流程做进一步分介绍。
在分布式软总线的设计中，trans_service模块是在authmanager模块中被初始化的，而authmanager模块又被discovery模块初始化，因此设备在向外发布本设备信息的过程中，这三个相互关联的模块会以“发现→认证→传输”的顺序完成初始化（如下图13）。
图13：3个模块的激活顺序
为了便于理解软总线执行流程，屏蔽具体函数细节，笔者将这一过程中的函数调用关系绘制成图（篇幅所限，图片置于文末），并标注了执行顺序，读者可以按照流程图进行阅读。源码文件数目较多，且文件之间的调用关系错综复杂，若有疏漏错误之处，望读者见谅。
3 编译、运行软总线模块
3.1编译分布式软总线模块
软总线模块的运行需要较多鸿蒙OS头文件参与，这里采用将软总线组件绑定至鸿蒙OS全量代码的基础上共同编译。编译过程如下。
图14： 编译所用的虚拟机环境
便携配置文件Makefile如下：
执行Makefile编译操作，得到生成的软总线镜像文件so，如下图所示。
3.2测试软总线模块
这里使用官方的测试demo来测试我们编译完成的软总线组件模块。Demo程序如下所示：
编译demo，如下图所示：
使用sudo权限来执行生成的可执行文件PublishService，执行结果如下图所示，测试成功：
4 参考资料
1，润小云解读鸿蒙OS系列https://my.oschina.net/u/4786275,
2，华为官方开发者文档https://device.harmonyos.com/cn/docs/develop/kernel/oem_ke
rnal_user_process-0000001050032733
3，鸿蒙分布式软总线技术研究-阮旭东
标签：报告 融合 基础 设计 可靠传输 code 相对 裁剪 session
原文地址：https://www.cnblogs.com/hhxk/p/14350927.html
