深度解读设备的“万能语言”鸿蒙系统的分布式软总线能力
摘要:本文分享鸿蒙分布式软总线,并对相关源代码进行解析,为在鸿蒙系统平台上工作的相关人员的信息参考和指导。
总线是一种内部结构,在计算机系统中,主机的各个部件通过总线相连,外部设备通过相应的接口电路再与总线相连接,是 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/
点击关注,第一时间了解华为云新鲜技术~
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/f613e631f1682c04c34c2641c】。文章转载请联系作者。
评论