摘要:本文分享鸿蒙分布式软总线,并对相干源代码进行解析,为在鸿蒙零碎平台上工作的相干人员的信息参考和领导。
总线是一种内部结构,在计算机系统中,主机的各个部件通过总线相连,外部设备通过相应的接口电路再与总线相连接,是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/
点击关注,第一工夫理解华为云陈腐技术~