總線是一種內(nèi)部結(jié)構(gòu)，在計(jì)算機(jī)系統(tǒng)中，主機(jī)的各個部件通過總線相連，外部設(shè)備通過相應(yīng)的接口電路再與總線相連接，是CPU、內(nèi)存、輸入、輸出設(shè)備傳遞信息的公用通道。按所傳輸?shù)男畔⒎N類，可劃分為數(shù)據(jù)、地址和控制總線，分別用來傳輸數(shù)據(jù)、數(shù)據(jù)地址和控制信號。

HarmonyOS系統(tǒng)的使命和目標(biāo)是將不同的設(shè)備串聯(lián)，成為設(shè)備的“萬能語言”，讓一個系統(tǒng)連接起所有上網(wǎng)的智能設(shè)備，實(shí)現(xiàn)萬物互聯(lián)的終極目標(biāo)。其核心能力之一，【分布式軟總線】讓多設(shè)備融合為“一個設(shè)備”，帶來設(shè)備內(nèi)和設(shè)備間高吞吐、低時延、高可靠的流暢連接體驗(yàn)。

本文分享鴻蒙分布式軟總線，并對相關(guān)源代碼進(jìn)行解析，作為在此平臺上工作的相關(guān)人員的信息參考和指導(dǎo)。具體開發(fā)請參考鴻蒙官網(wǎng)。

1. 介 紹

設(shè)備的通信方式多種多樣，譬如USB、WIFI、BT，通信方式差異大且繁瑣，鏈路的融合、共享、沖突、安全等問題也難以保證。

鴻蒙分布式軟總線致力于實(shí)現(xiàn)近場設(shè)備間統(tǒng)一的分布式通信能力，提供不區(qū)分鏈路的設(shè)備發(fā)現(xiàn)和傳輸接口，具備快速發(fā)現(xiàn)并連接設(shè)備，高效分發(fā)任務(wù)和傳輸數(shù)據(jù)。作為多終端設(shè)備的統(tǒng)一基座，是鴻蒙架構(gòu)中的底層技術(shù)，是鴻蒙的大動脈，其總的目標(biāo)是實(shí)現(xiàn)設(shè)備間無感發(fā)現(xiàn)，零等待傳輸。對開發(fā)者而言，無需關(guān)注組網(wǎng)方式與底層協(xié)議。

2. 分布式軟總線特性

鴻蒙分布式軟總線的設(shè)計(jì)目標(biāo)在于推進(jìn)極簡通信協(xié)議技術(shù)，在設(shè)備安全場景下，即連即用。關(guān)鍵技術(shù)特性覆蓋設(shè)備的自動發(fā)現(xiàn)&連接、組網(wǎng)（多跳自組網(wǎng)、多協(xié)議混合組網(wǎng)）、傳輸（多元化協(xié)議與算法、智能感知與決策）。

2.1 設(shè)備間自發(fā)現(xiàn)&連接

分布式軟總線提出自動發(fā)現(xiàn)設(shè)備，實(shí)現(xiàn)用戶零等待的自發(fā)現(xiàn)體驗(yàn)，附近同賬號的設(shè)備自動發(fā)現(xiàn)無需等待，自動安全連接。

IoT設(shè)備分為發(fā)現(xiàn)端和被發(fā)現(xiàn)端。發(fā)現(xiàn)端一般為請求使用服務(wù)的設(shè)備或稱為主控設(shè)備，常指智慧屏設(shè)備（如手機(jī)、平板等）。被發(fā)現(xiàn)端為發(fā)布服務(wù)的設(shè)備，指輕量設(shè)備（如AI音箱、智能家居、智能穿戴等設(shè)備）。目前軟總線的設(shè)備互聯(lián)，需保證發(fā)現(xiàn)端和被發(fā)現(xiàn)端處于同一個局域網(wǎng)內(nèi)。

2.2 多設(shè)備互聯(lián)、組網(wǎng)

基于網(wǎng)絡(luò)互聯(lián)、交互的系統(tǒng)，開發(fā)者往往需要適配不同網(wǎng)絡(luò)協(xié)議和標(biāo)準(zhǔn)規(guī)范。而在鴻蒙系統(tǒng)設(shè)定的分布式開發(fā)模式中，無需關(guān)心網(wǎng)絡(luò)協(xié)議的差異及組網(wǎng)方式，業(yè)務(wù)開發(fā)與設(shè)備組網(wǎng)解耦，僅需監(jiān)聽設(shè)備上下線，開發(fā)成本大大降低。

分布式軟總線提出了異構(gòu)網(wǎng)絡(luò)組網(wǎng)，自動構(gòu)建一個邏輯全連接網(wǎng)絡(luò)，以解決設(shè)備間不同協(xié)議交互的問題。設(shè)備上線后會向網(wǎng)絡(luò)層注冊，同時網(wǎng)絡(luò)層會與設(shè)備建立通道連接，實(shí)時檢測設(shè)備的變換。網(wǎng)絡(luò)層負(fù)責(zé)管理設(shè)備的上線、下線變換，設(shè)備間可以監(jiān)聽自己感興趣的設(shè)備，設(shè)備上線后可以立即與其建立連接，實(shí)現(xiàn)零等待體驗(yàn)。

2.3 多設(shè)備間數(shù)據(jù)傳輸

提供統(tǒng)一的基于Session的認(rèn)證、傳輸功能，上層業(yè)務(wù)系統(tǒng)可以通過sessionId收發(fā)數(shù)據(jù)或獲取其相關(guān)基本屬性，實(shí)現(xiàn)業(yè)務(wù)消息、流、控制指令等操作交互。

3. 軟總線協(xié)議COAP

互聯(lián)網(wǎng)的WEB應(yīng)用無處不在，很多依賴于REST協(xié)議架構(gòu)。為在大多的受限節(jié)點(diǎn)上（如RAM和ROM很有限的8位單片機(jī)）及受限網(wǎng)絡(luò)上（如6LoWPAN）也能支持REST，工程師們著手處理“受限制的restful環(huán)境”，即CoRE。如6LoWPAN的受限網(wǎng)絡(luò)支持將IPv6數(shù)據(jù)分成小包，但極大降低了傳輸效率。

CoAP（Constrained Application Protocol）的主要目標(biāo)之一是設(shè)計(jì)一個通用的Web協(xié)議，保持非常低的開銷，以滿足受限環(huán)境的特殊要求，如能源、樓宇自動化或其它M2M應(yīng)用。實(shí)現(xiàn)REST的一個通用HTTP子集，針對M2M應(yīng)用做了簡化，而非盲目壓縮HTTP。COAP協(xié)議可很容易轉(zhuǎn)換為HTTP，方便和現(xiàn)有WEB體系轉(zhuǎn)化，同時還能滿足諸如內(nèi)置發(fā)現(xiàn)、組播支持和異步消息傳輸?shù)取?/p>

3.1 COAP協(xié)議特征

屬于一種應(yīng)用層協(xié)議，運(yùn)行于UDP協(xié)議之上而不是像HTTP那樣運(yùn)行于TCP之上。

1） COAP協(xié)議網(wǎng)絡(luò)傳輸層由TCP改為UDP;

2） 基于REST，server的資源地址也類似URL格式，客戶端同樣有POST，GET，PUT，DELETE方法來訪問server，對HTTP做了簡化；

3） COAP是二進(jìn)制格式，HTTP是文本格式，COAP比HTTP更加緊湊；

4） 小巧、輕量化，最小長度僅僅4 Bytes，一個HTTP的head都要幾十Bytes;

5） 支持可靠傳輸，數(shù)據(jù)重傳，塊傳輸;

6） 支持IP多播， 可同時向多個設(shè)備發(fā)送請求，鴻蒙設(shè)備的發(fā)現(xiàn)功能就是用的這個特性；

7） 非長連接通信，適用于低功耗物聯(lián)網(wǎng)場景；

8） 支持觀察模式；

3.2 協(xié)議類型及結(jié)構(gòu)

COAP協(xié)議有4種消息類型。

CON： 需要確認(rèn)，如果CON請求被發(fā)送，那對方必須做出響應(yīng)，確認(rèn)收到消息，用以可靠消息傳輸；

NON： 不需要被確認(rèn)的請求，如果NON請求被發(fā)送，那對方不必作出回應(yīng)。適用于消息會重復(fù)頻繁的發(fā)送，丟包不影響正常操作。和UDP很像，用于不可靠消息傳輸；

ACK： 應(yīng)答消息，對應(yīng)的是CON消息的應(yīng)答；

RST： 復(fù)位消息，可靠傳輸時候接收的消息不認(rèn)識或錯誤時，必須回RST消息；

協(xié)議結(jié)構(gòu)定義

在源碼discovery/coap/include/coap_def.h中對COAP協(xié)議的結(jié)構(gòu)體進(jìn)行了定義。

3.3 COAP包的傳輸

傳輸方式為客戶端和服務(wù)器端模式，服務(wù)器端啟動COAP包的監(jiān)聽服務(wù)。

源碼discovery/coap/include/coap_socket.h中提供了COAP包的發(fā)送和接收函數(shù)定義。

3.4 COAP設(shè)備發(fā)現(xiàn)

源碼discovery/coap/source/coap_discover.c實(shí)現(xiàn)了基于COAP的設(shè)備發(fā)現(xiàn)功能。

3.5 COAP的安全性

TLS不能用來保證UDP上傳輸?shù)臄?shù)據(jù)的安全，因此Datagram TLS試圖在現(xiàn)存的TLS架構(gòu)上提出擴(kuò)展，使之支持UDP。

COAP的安全性是用DTLS加密實(shí)現(xiàn)。DTLS的實(shí)現(xiàn)需要的資源和帶寬較多，如果是資源非常少的終端和極有限的帶寬下可能會跑不起來。DTLS僅僅在單播情況下適用。

4. 源代碼結(jié)構(gòu)與解析

分布式軟總線的源代碼在communication_services_softbus_lite目錄，結(jié)構(gòu)如下：

說明： 目錄下所有源碼文件將被編譯為一個動態(tài)庫，其它依賴模塊在編譯的時候加上這個動態(tài)庫的依賴即可。譬如：分布式調(diào)度子系統(tǒng)所在的foundation這個bin文件的編譯就依賴這個動態(tài)庫。

4.1軟總線的初始化

StartListener（）函存在對應(yīng)不同版本平臺的適配，體現(xiàn)了各部分解耦的模塊化設(shè)計(jì)思想，針對不同的硬件設(shè)備，組合成最適合該設(shè)備的OS。比如創(chuàng)建線程時采用了統(tǒng)一的static void WaitProcess（void）函數(shù)，而其內(nèi)部封裝了不同底層API的適配代碼。

4.2操作系統(tǒng)適配層

HarmonyOS的操作系統(tǒng)底層可以是：HarmonyOS micro kernel，Linux kernel，且Lite OS將成為一個完整的鴻蒙微內(nèi)核架構(gòu)。

鴻蒙系統(tǒng)內(nèi)部各個模塊內(nèi)部使用的函數(shù)需要支持針對不同版本平臺的適配，體現(xiàn)各部分解耦的模塊化設(shè)計(jì)思想，針對不同的硬件設(shè)備，組合成最適合該設(shè)備的OS。譬如，創(chuàng)建線程時采用了統(tǒng)一的static void WaitProcess（void）函數(shù)，而其內(nèi)部封裝了不同底層API的適配代碼。SemCreate在LiteOS中使用LOS_SemCreate創(chuàng)建信號量，在Linux上用sem_init（） Posix標(biāo)準(zhǔn)接口創(chuàng)建。

源碼目錄os_adapter下的代碼即實(shí)現(xiàn)了分布式軟總線對操作系統(tǒng)的適配。

LiteOS

是華為面向物聯(lián)網(wǎng)領(lǐng)域開發(fā)的一個基于實(shí)時內(nèi)核的輕量級操作系統(tǒng)，現(xiàn)有基礎(chǔ)內(nèi)核支持任務(wù)管理、內(nèi)存管理、時間管理、通信機(jī)制、中斷管理、隊(duì)列管理、事件管理、定時器等操作系統(tǒng)基礎(chǔ)組件，為更好地支持低功耗場景，支持tickless機(jī)制，支持定時器對齊。

LiteOS開源項(xiàng)目支持ARM Cortex-M0，Cortex-M3，Cortex-M4，Cortex-M7等芯片架構(gòu)。

4.3設(shè)備發(fā)現(xiàn)與連接

各個設(shè)備以服務(wù)的形態(tài)推送、發(fā)布，發(fā)布后周邊的設(shè)備可以發(fā)現(xiàn)、連接并與之通訊交互，源代碼位于discoverydiscovery_servicesource目錄中。

輕量設(shè)備作為被發(fā)現(xiàn)端設(shè)備，調(diào)用PublishService發(fā)布服務(wù)。入口代碼截圖：

以下是針對操作序列中的代碼解析截圖，供參考。

1） 權(quán)限檢查

os_adapter為適配OS系統(tǒng)，封裝的函數(shù)在不同的操作系統(tǒng)有不同的實(shí)現(xiàn)。如SemCreate在LiteOS上使用LOS_SemCreate創(chuàng)建信號量，而Linux上用sem_init（）Posix標(biāo)準(zhǔn)接口。

2） 參數(shù)檢查

4） 初始化服務(wù)

A） CoapInit

COAP初始化，注冊TCP/IP協(xié)議棧的處理，注冊session的底層socket的操作處理。

B） CoapWriteMsgQueue（）

寫入消息，觸發(fā)獲取Wifi 的IP地址，啟動總線。

5） 信息加入Module

說明：將g_localDeviceInfo.serverData賦值成“port:auth_port”，auth_port是基于TCP的認(rèn)證服務(wù)的socket綁定的端口號（在StartBus函數(shù)中賦值）。

7） 回調(diào)發(fā)布成功

調(diào)用PublishCallback（）執(zhí)行cb中的發(fā)布成功的回調(diào)函數(shù)。

4.4 設(shè)備的認(rèn)證管理

設(shè)備之間的互聯(lián)、互通需要建立點(diǎn)對點(diǎn)的信任關(guān)系，并在具備信任關(guān)系的設(shè)備間構(gòu)建安全的連接通道，實(shí)現(xiàn)用戶數(shù)據(jù)端到端的加密傳輸。建立點(diǎn)對點(diǎn)信任關(guān)系的過程即是相互交換設(shè)備的身份標(biāo)識的過程。信任關(guān)系的建立相當(dāng)于一次握手，譬如：A設(shè)備發(fā)送密文給B設(shè)備，B成功解密并把自己的信息封裝到報(bào)文中再次加密傳輸給A，A拿到報(bào)文再次解密確認(rèn)是B.

authmanager模塊是鴻蒙為設(shè)備提供認(rèn)證機(jī)制的模塊。模塊內(nèi)的主要處理過程包括報(bào)文的接收、解密、再次封裝、加密、發(fā)送的步驟。譬如，當(dāng)發(fā)現(xiàn)有請求時，調(diào)用ProcessDataEvent（wifi_auth_manager）函數(shù)，收包、檢驗(yàn)包頭，根據(jù)數(shù)據(jù)包的類型確定不同的處理方式。數(shù)據(jù)包的類型主要包括以下三種：

MODULE_AUTH_SDK 加密數(shù)據(jù)類型

MODULE_TRUST_ENGINE 可信類型，直接進(jìn)行數(shù)據(jù)傳輸

MODULE_CONNECTION 進(jìn)行IP及設(shè)備認(rèn)證

1） 模塊的內(nèi)部結(jié)構(gòu)關(guān)系

2） 加密發(fā)送步驟及算法

AES-GCM加密算法：AES是一種對稱加密算法，GCM是對該對稱加密采用Counter模式，并帶有GMAC消息認(rèn)證碼。AES-GCM算法是帶認(rèn)證和加密的算法，同時可以對給定的原文，生成加密數(shù)據(jù)和認(rèn)證碼。

3） 鴻蒙設(shè)備互聯(lián)安全

以下是鴻蒙官網(wǎng)文檔的設(shè)備互聯(lián)安全參考圖

實(shí)現(xiàn)用戶數(shù)據(jù)在設(shè)備互聯(lián)場景下，在各個設(shè)備之間的安全流轉(zhuǎn)，實(shí)現(xiàn)用戶數(shù)據(jù)的安全傳輸。

綁定的流程

設(shè)備分別生成Ed25519密鑰對；

利用PIN碼和PAKE（Password authenticated key exchange）進(jìn)行密鑰協(xié)商，生成會話密鑰；

通過會話密鑰加密彼此的公鑰（也可不用加密，算個MAC就行，只要能驗(yàn)證公鑰確實(shí)來自對方即可）

這里的身份標(biāo)識公鑰指的應(yīng)該是（設(shè)備標(biāo)識， 公鑰）的二元組

通信的流程

通過公鑰協(xié)商會話密鑰；會話密鑰應(yīng)怎么用，一般來說，會將初步協(xié)商的密鑰進(jìn)行密鑰分散，分為加密密鑰、MAC密鑰等；

使用會話密鑰加密通信數(shù)據(jù)。

當(dāng)建立信任關(guān)系的主控設(shè)備與設(shè)備間在進(jìn)行通信時，雙方首先完成信任關(guān)系綁定，然后基于存儲在本地的對端身份公鑰相互進(jìn)行認(rèn)證；在每次通信時完成雙向身份認(rèn)證以及會話密鑰協(xié)商，之后設(shè)備使用此會話密鑰來解密雙方設(shè)備間的傳輸通道。

4.5 認(rèn)證與會話傳輸

trans_service模塊依賴于系統(tǒng)OS提供的網(wǎng)絡(luò)socket服務(wù)，向認(rèn)證模塊提供認(rèn)證通道管理和認(rèn)證數(shù)據(jù)的收發(fā)；向業(yè)務(wù)模塊提供session管理和基于session的數(shù)據(jù)收發(fā)功能，并且通過GCM模塊的加密功能提供收發(fā)報(bào)文的加解密保護(hù)。

被發(fā)現(xiàn)端（輕量設(shè)備）注冊、發(fā)布服務(wù)，成功后回調(diào)處理，被發(fā)現(xiàn)端使用CreateSessionServer來創(chuàng)建會話服務(wù)器并等待發(fā)現(xiàn)端的連接、創(chuàng)建會話。發(fā)現(xiàn)端（如：智慧屏設(shè)備）根據(jù)服務(wù)的名稱和設(shè)備ID建立一個會話，就可以實(shí)現(xiàn)服務(wù)間的數(shù)據(jù)傳輸。

數(shù)據(jù)傳輸部分的源代碼位于trans_service/source/libdistbus目錄。

主要處理的步驟參考如下：

CreateSessionServer［會話］ à SelectSessionLoop［數(shù)據(jù)］ à OnBytesReceived［回調(diào)］

1） CreateSessionServer創(chuàng)建會話

2） SelectSessionLoop

啟動總線后即創(chuàng)建了基于TCP的會話管理服務(wù)，服務(wù)的任務(wù)線程為SelectSessionLoop，處理所有的會話數(shù)據(jù)的接收。

3） OnBytesReceived

會話數(shù)據(jù)到達(dá)的回調(diào)函數(shù)，調(diào)用上層應(yīng)用注冊的onBytesReceived。接收會話報(bào)文并進(jìn)行格式解析，執(zhí)行相應(yīng)動作。如在分布式調(diào)度模塊中，可能是START_FA命令。

最 后

分布式軟總線是鴻蒙操作系統(tǒng)的基座模塊，也是分布式數(shù)據(jù)管理和分布式任務(wù)調(diào)度的基石，透徹理解分布式軟總線是深入了解整個鴻蒙OS的基礎(chǔ)。

本文是基于開放的源代碼對分布式軟總線模塊的切入分析、解析，文中會有部分源碼分析、場景分析未完全覆蓋到，后續(xù)會視情況進(jìn)行相關(guān)補(bǔ)充。

編輯：hfy