深度解读设备的“万能语言”鸿蒙的分布式软总线能力

总线是一种内部结构，在计算机系统中，主机的各个部件通过总线相连，外部设备通过相应的接口电路再与总线相连接，是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设备发现与连接

各个设备以服务的形态推送、发布，发布后周边的设备可以发现、连接并与之通讯交互,源代码位于discovery\discovery_service\source目录中。

轻量设备作为被发现端设备，调用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)函数，收包、检验包头，根据数据包的类型确定不同的处理方式。数据包的类型主要包括以下三种：

l  MODULE_AUTH_SDK     加密数据类型

l  MODULE_TRUST_ENGINE 可信类型，直接进行数据传输

l  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/

TCP/IP 分布式

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。