摘要：本文分享鴻蒙分佈式軟總線，並對相關源代碼進行解析，爲在鴻蒙系統平臺上工做的相關人員的信息參考和指導。
總線是一種內部結構，在計算機系統中，主機的各個部件經過總線相連，外部設備經過相應的接口電路再與總線相鏈接，是CPU、內存、輸入、輸出設備傳遞信息的公用通道。按所傳輸的信息種類，可劃分爲數據、地址和控制總線，分別用來傳輸數據、數據地址和控制信號。git
HarmonyOS系統的使命和目標是將不一樣的設備串聯，成爲設備的「萬能語言」,讓一個系統鏈接起全部上網的智能設備，實現萬物互聯的終極目標。其核心能力之一，【分佈式軟總線】讓多設備融合爲「一個設備」,帶來設備內和設備間高吞吐、低時延、高可靠的流暢鏈接體驗。github
本文分享鴻蒙分佈式軟總線，並對相關源代碼進行解析，做爲在此平臺上工做的相關人員的信息參考和指導。具體開發請參考鴻蒙官網。算法
1. 介紹
設備的通訊方式多種多樣，譬如USB、WIFI、BT，通訊方式差別大且繁瑣，鏈路的融合、共享、衝突、安全等問題也難以保證。安全
鴻蒙分佈式軟總線致力於實現近場設備間統一的分佈式通訊能力，提供不區分鏈路的設備發現和傳輸接口，具有快速發現並鏈接設備，高效分發任務和傳輸數據。做爲多終端設備的統一基座，是鴻蒙架構中的底層技術，是鴻蒙的大動脈，其總的目標是實現設備間無感發現，零等待傳輸。對開發者而言，無需關注組網方式與底層協議。服務器
2. 分佈式軟總線特性
鴻蒙分佈式軟總線的設計目標在於推動極簡通訊協議技術，在設備安全場景下，即連即用。關鍵技術特性覆蓋設備的自動發現&鏈接、組網(多跳自組網、多協議混合組網）、傳輸(多元化協議與算法、智能感知與決策）。restful
2.1 設備間自發現&鏈接
分佈式軟總線提出自動發現設備，實現用戶零等待的自發現體驗，附近同帳號的設備自動發現無需等待，自動安全鏈接。網絡
IoT設備分爲發現端和被發現端。發現端通常爲請求使用服務的設備或稱爲主控設備，常指智慧屏設備（如手機、平板等）。被發現端爲發佈服務的設備，指輕量設備（如AI音箱、智能家居、智能穿戴等設備）。目前軟總線的設備互聯，需保證發現端和被發現端處於同一個局域網內。session
2.2 多設備互聯、組網
基於網絡互聯、交互的系統，開發者每每須要適配不一樣網絡協議和標準規範。而在鴻蒙系統設定的分佈式開發模式中，無需關心網絡協議的差別及組網方式，業務開發與設備組網解耦，僅需監聽設備上下線，開發成本大大下降。架構
分佈式軟總線提出了異構網絡組網，自動構建一個邏輯全鏈接網絡，以解決設備間不一樣協議交互的問題。設備上線後會向網絡層註冊，同時網絡層會與設備創建通道鏈接，實時檢測設備的變換。網絡層負責管理設備的上線、下線變換，設備間能夠監聽本身感興趣的設備，設備上線後能夠當即與其創建鏈接，實現零等待體驗。less
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峯。