摘要：本文分享鴻蒙分散式軟匯流排，並對相關原始碼進行解析，為在鴻蒙系統平臺上工作的相關人員的資訊參考和指導。
匯流排是一種內部結構，在計算機系統中，主機的各個部件通過匯流排相連，外部裝置通過相應的介面電路再與匯流排相連線，是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)函式，收包、檢驗包頭，根據資料包的型別確定不同的處理方式。資料包的型別主要包括以下三種：
- 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/
本文分享自華為雲社群《【鴻蒙作業系統專題二】分散式軟匯流排-解析x1》，原文作者：張X峰。