摘要：本文分享鸿蒙分布式软总线，并对相干源代码进行解析，为在鸿蒙零碎平台上工作的相干人员的信息参考和领导。
总线是一种内部结构，在计算机系统中，主机的各个部件通过总线相连，外部设备通过相应的接口电路再与总线相连接，是 CPU、内存、输出、输出设备传递信息的专用通道。按所传输的信息品种，可划分为数据、地址和管制总线，别离用来传输数据、数据地址和管制信号。
HarmonyOS 零碎的使命和指标是将不同的设施串联，成为设施的“万能语言”, 让一个零碎连贯起所有上网的智能设施，实现万物互联的终极目标。其外围能力之一，【分布式软总线】让多设施交融为“一个设施”, 带来设施内和设施间高吞吐、低时延、高牢靠的晦涩连贯体验。
本文分享鸿蒙分布式软总线，并对相干源代码进行解析，作为在此平台上工作的相干人员的信息参考和领导。具体开发请参考鸿蒙官网。
1. 介 绍
设施的通信形式多种多样，譬如 USB、WIFI、BT，通信形式差别大且繁琐，链路的交融、共享、抵触、平安等问题也难以保障。
鸿蒙分布式软总线致力于实现近场设施间对立的分布式通信能力，提供不辨别链路的设施发现和传输接口，具备疾速发现并连贯设施，高效散发工作和传输数据。作为多终端设备的对立基座，是鸿蒙架构中的底层技术，是鸿蒙的大动脉，其总的指标是实现设施间无感发现，零期待传输。对开发者而言，无需关注组网形式与底层协定。
2. 分布式软总线个性
鸿蒙分布式软总线的设计指标在于推动极简通信协议技术，在设施平安场景下，即连即用。关键技术个性笼罩设施的主动发现 & 连贯、组网(多跳自组网、多协定混合组网）、传输(多元化协定与算法、智能感知与决策）。
2.1 设施间自发现 & 连贯
分布式软总线提出主动发现设施，实现用户零期待的自发现体验，左近同账号的设施主动发现无需期待，主动平安连贯。
IoT 设施分为发现端和被发现端。发现端个别为申请应用服务的设施或称为主控设施，常指智慧屏设施（如手机、平板等）。被发现端为公布服务的设施，指轻量设施（如 AI 音箱、智能家居、智能穿戴等设施）。目前软总线的设施互联，需保障发现端和被发现端处于同一个局域网内。
2.2 多设施互联、组网
基于网络互联、交互的零碎，开发者往往须要适配不同网络协议和标准规范。而在鸿蒙零碎设定的分布式开发模式中，无需关怀网络协议的差别及组网形式，业务开发与设施组网解耦，仅需监听设施高低线，开发成本大大降低。
分布式软总线提出了异构网络组网，主动构建一个逻辑全连贯网络，以解决设施间不同协定交互的问题。设施上线后会向网络层注册，同时网络层会与设施建设通道连贯，实时检测设施的变换。网络层负责管理设施的上线、下线变换，设施间能够监听本人感兴趣的设施，设施上线后能够立刻与其建设连贯，实现零期待体验。
2.3 多设施间数据传输
提供对立的基于 Session 的认证、传输性能，下层业务零碎能够通过 sessionId 收发数据或获取其相干根本属性，实现业务音讯、流、控制指令等操作交互。
3. 软总线协定 COAP
互联网的 WEB 利用无处不在，很多依赖于 REST 协定架构。为在大多的受限节点上 (如 RAM 和 ROM 很无限的 8 位单片机) 及受限网络上 (如 6LoWPAN) 也能反对 REST，工程师们着手解决“受限制的 restful 环境”，即 CoRE。如 6LoWPAN 的受限网络反对将 IPv6 数据分成小包，但极大升高了传输效率。
CoAP(Constrained Application Protocol)的次要指标之一是设计一个通用的 Web 协定, 放弃非常低的开销, 以满足受限环境的特殊要求，如能源、楼宇自动化或其它 M2M 利用。实现 REST 的一个通用 HTTP 子集，针对 M2M 利用做了简化，而非自觉压缩 HTTP。COAP 协定可很容易转换为 HTTP，不便和现有 WEB 体系转化，同时还能满足诸如内置发现、组播反对和异步音讯传输等。
3.1 COAP 协定特色
属于一种应用层协定，运行于 UDP 协定之上而不是像 HTTP 那样运行于 TCP 之上。
1) COAP 协定网络传输层由 TCP 改为 UDP;
2) 基于 REST，server 的资源地址也相似 URL 格局，客户端同样有 POST，GET,PUT,DELETE 办法来拜访 server，对 HTTP 做了简化；
3) COAP 是二进制格局，HTTP 是文本格式，COAP 比 HTTP 更加紧凑；
4) 玲珑、轻量化，最小长度仅仅 4 Bytes，一个 HTTP 的 head 都要几十 Bytes;
5) 反对牢靠传输，数据重传，块传输;
6) 反对 IP 多播, 可同时向多个设施发送申请, 鸿蒙设施的发现性能就是用的这个个性；
7) 非长连贯通信，实用于低功耗物联网场景；
8) 反对察看模式；
3.2 协定类型及构造
COAP 协定有 4 种音讯类型。
- CON: 须要确认，如果 CON 申请被发送，那对方必须做出响应，确认收到音讯，用以可靠消息传输；
- NON: 不须要被确认的申请，如果 NON 申请被发送，那对方不用作出回应。实用于音讯会反复频繁的发送，丢包不影响失常操作。和 UDP 很像，用于不可靠消息传输；
- ACK: 应答音讯，对应的是 CON 音讯的应答；
- RST: 复位音讯，牢靠传输时候接管的音讯不意识或谬误时，必须回 RST 音讯；
协定构造定义
在源码 discovery/coap/include/coap_def.h 中对 COAP 协定的构造体进行了定义。
3.3 COAP 包的传输
传输方式为客户端和服务器端模式，服务器端启动 COAP 包的监听服务。
源码 discovery/coap/include/coap_socket.h 中提供了 COAP 包的发送和接管函数定义。
3.4 COAP 设施发现
源码 discovery/coap/source/coap_discover.c 实现了基于 COAP 的设施发现性能。
3.5 COAP 的安全性
TLS 不能用来保障 UDP 上传输的数据的平安，因而 Datagram TLS 试图在现存的 TLS 架构上提出扩大，使之反对 UDP。
COAP 的安全性是用 DTLS 加密实现。DTLS 的实现须要的资源和带宽较多，如果是资源非常少的终端和极无限的带宽下可能会跑不起来。DTLS 仅仅在单播状况下实用。
4. 源代码构造与解析
分布式软总线的源代码在 communication_services_softbus_lite 目录，构造如下:
阐明：目录下所有源码文件将被编译为一个动静库，其它依赖模块在编译的时候加上这个动静库的依赖即可。譬如：散布式调度子系统所在的 foundation 这个 bin 文件的编译就依赖这个动静库。
4.1 软总线的初始化
StartListener()函存在对应不同版本平台的适配，体现了各部合成耦的模块化设计思维，针对不同的硬件设施，组合成最适宜该设施的 OS。比方创立线程时采纳了对立的 static void WaitProcess(void)函数，而其外部封装了不同底层 API 的适配代码。
4.2 操作系统适配层
HarmonyOS 的操作系统底层能够是：HarmonyOS micro kernel，Linux kernel，且 [Lite OS] 将成为一个残缺的鸿蒙微内核架构。
鸿蒙零碎外部各个模块外部应用的函数须要反对针对不同版本平台的适配，体现各部合成耦的模块化设计思维，针对不同的硬件设施，组合成最适宜该设施的 OS。譬如，创立线程时采纳了对立的 static void WaitProcess(void)函数，而其外部封装了不同底层 API 的适配代码。SemCreate 在 LiteOS 中应用 LOS_SemCreate 创立信号量，在 Linux 上用 sem_init() Posix 标准接口创立。
源码目录 os_adapter 下的代码即实现了分布式软总线对操作系统的适配。
LiteOS
是华为面向物联网畛域开发的一个基于实时内核的轻量级操作系统，现有根底内核反对工作治理、内存治理、工夫治理、通信机制、中断治理、队列治理、事件治理、定时器等操作系统根底组件，为更好地反对低功耗场景，反对 tickless 机制，反对定时器对齐。
LiteOS 开源我的项目反对 ARM Cortex-M0，Cortex-M3，Cortex-M4，Cortex-M7 等芯片架构。
4.3 设施发现与连贯
各个设施以服务的状态推送、公布，公布后周边的设施能够发现、连贯并与之通信交互, 源代码位于 discoverydiscovery_servicesource 目录中。
轻量设施作为被发现端设施，调用 PublishService 公布服务。入口代码截图:
以下是针对操作序列中的代码解析截图，供参考.
1) 权限查看
os_adapter 为适配 OS 零碎，封装的函数在不同的操作系统有不同的实现。如 SemCreate 在 LiteOS 上应用 LOS_SemCreate 创立信号量，而 Linux 上用 sem_init()Posix 标准接口。
2) 参数查看
3) 创立信号量
4) 初始化服务
A) CoapInit
COAP 初始化，注册 TCP/IP 协定栈的解决，注册 session 的底层 socket 的操作解决.
B) CoapWriteMsgQueue()
写入音讯，触发获取 Wifi 的 IP 地址，启动总线。
5) 信息退出Module
6) 注册 COAP 服务
阐明：将 g_localDeviceInfo.serverData 赋值成“port:auth_port”,auth_port 是基于 TCP 的认证服务的 socket 绑定的端口号(在 StartBus 函数中赋值).
7) 回调公布胜利
调用 PublishCallback()执行 cb 中的公布胜利的回调函数。
4.4 设施的认证治理
设施之间的互联、互通须要建设点对点的信赖关系，并在具备信赖关系的设施间构建平安的连贯通道，实现用户数据端到端的加密传输。建设点对点信赖关系的过程即是相互交换设施的身份标识的过程。信赖关系的建设相当于一次握手，譬如：A 设施发送密文给 B 设施，B 胜利解密并把本人的信息封装到报文中再次加密传输给 A，A 拿到报文再次解密确认是 B.
authmanager 模块是鸿蒙为设施提供认证机制的模块。模块内的次要处理过程包含报文的接管、解密、再次封装、加密、发送的步骤。譬如，当发现有申请时，调用 ProcessDataEvent(wifi_auth_manager)函数，收包、测验包头，依据数据包的类型确定不同的解决形式。数据包的类型次要包含以下三种：
- MODULE_AUTH_SDK 加密数据类型
- MODULE_TRUST_ENGINE 可信类型，间接进行数据传输
- MODULE_CONNECTION 进行 IP 及设施认证
1) 模块的内部结构关系
2) 加密发送步骤及算法
AES-GCM 加密算法：AES 是一种对称加密算法，GCM 是对该对称加密采纳 Counter 模式，并带有 GMAC 音讯认证码。AES-GCM 算法是带认证和加密的算法，同时能够对给定的原文，生成加密数据和认证码。
3) 鸿蒙设施互联平安
以下是鸿蒙官网文档的设施互联平安参考图
实现用户数据在设施互联场景下，在各个设施之间的平安流转，实现用户数据的平安传输。
绑定的流程
- 设施别离生成 Ed25519 密钥对；
- 利用 PIN 码和 PAKE(Password authenticated key exchange)进行密钥协商，生成会话密钥；
- 通过会话密钥加密彼此的公钥(也可不必加密，算个 MAC 就行，只有能验证公钥的确来自对方即可)
- 这里的身份标识公钥指的应该是 (设施标识, 公钥) 的二元组
通信的流程
- 通过公钥协商会话密钥；会话密钥应怎么用，一般来说，会将初步协商的密钥进行密钥扩散，分为加密密钥、MAC 密钥等；
- 应用会话密钥加密通信数据。
当建设信赖关系的主控设施与设施间在进行通信时，单方首先实现信赖关系绑定，而后基于存储在本地的对端身份公钥互相进行认证；在每次通信时实现双向身份认证以及会话密钥协商，之后设施应用此会话密钥来解密单方设施间的传输通道。
4.5 认证与会话传输
trans_service 模块依赖于零碎 OS 提供的网络 socket 服务，向认证模块提供认证通道治理和认证数据的收发；向业务模块提供 session 治理和基于 session 的数据收发性能，并且通过 GCM 模块的加密性能提供收发报文的加解密爱护。
被发现端（轻量设施）注册、公布服务，胜利后回调解决，被发现端应用 CreateSessionServer 来创立会话服务器并期待发现端的连贯、创立会话。发现端 (如：智慧屏设施) 依据服务的名称和设施 ID 建设一个会话，就能够实现服务间的数据传输。
数据传输局部的源代码位于 trans_service/source/libdistbus 目录。
次要解决的步骤参考如下：
CreateSessionServer[会话] à SelectSessionLoop[数据] à OnBytesReceived[回调]
1) CreateSessionServer创立会话
2) SelectSessionLoop
启动总线后即创立了基于 TCP 的会话治理服务，服务的工作线程为 SelectSessionLoop，解决所有的会话数据的接管。
3) OnBytesReceived
会话数据达到的回调函数，调用下层利用注册的 onBytesReceived。接管会话报文并进行格局解析，执行相应动作。如在散布式调度模块中，可能是 START_FA 命令。
最 后
分布式软总线是鸿蒙操作系统的基座模块，也是分布式数据管理和分布式任务调度的基石，透彻了解分布式软总线是深刻理解整个鸿蒙 OS 的根底。
本文是基于凋谢的源代码对分布式软总线模块的切入剖析、解析，文中会有局部源码剖析、场景剖析未齐全笼罩到，后续会视状况进行相干补充。
具体开发，请参考鸿蒙官网相干文档：https://developer.harmonyos.com/
点击关注，第一工夫理解华为云陈腐技术~