《鴻蒙操作系統分布式軟總線技術》
調研報告
朱浩
SA20225646
目 錄
1 HarmonyOS概述 -----------------------------------------------------------------3
1.1 系統定義---------------------------------------------------------------------3
1.2 系統架構---------------------------------------------------------------------3
1.3 分布式技術特性------------------------------------------------------------3
2 分布式軟總線模塊解析---------------------------------------------------------4
2.1分布式軟總線的功能-------------------------------------------------------4
2.2分布式軟總線的原理-------------------------------------------------------4
2.3分布式軟總線源碼分析----------------------------------------------------6
2.3.1 discover部分------------------------------------------------------------7
2.3.2 authmanager部分 ------------------------------------------------------8
2.3.3 trans_service部分------------------------------------------------------9
2.3.4 軟總線代碼執行流程------------------------------------------------11
3 編譯、運行軟總線模塊--------------------------------------------------------12
4 參考資料--------------------------------------------------------------------------18
1 HarmonyOS概述
1.1 系統定義
HarmonyOS是一款“面向未來”、面向全場景（移動辦公、運動健康、社交通信、媒體娛樂等）的分布式操作系統。在傳統的單設備系統能力的基礎上，HarmonyOS提出了基於同一套系統能力、適配多種終端形態的分布式理念，能夠支持手機、平板、智能穿戴、智慧屏、車機等多種終端設備。
1.2 系統架構
HarmonyOS整體遵從分層設計，從下向上依次為：內核層、系統服務層、框架層和應用層。系統功能按照“系統 > 子系統 > 功能/模塊”逐級展開，在多設備部署場景下，支持根據實際需求裁剪某些非必要的子系統或功能/模塊。HarmonyOS技術架構如下所示。
圖1：鴻蒙系統的架構層次
1.3分布式技術特性
HarmonyOS中，多種設備之間能夠實現硬件互助、資源共享，依賴的關鍵技術包括分布式軟總線、分布式設備虛擬化、分布式數據管理、分布式任務調度等。
圖2：鴻蒙系統所依賴的分布式技術
2 分布式軟總線模塊解析
2.1分布式軟總線的功能
在鴻蒙系統中，分布式軟總線是手機、平板、智能穿戴、智慧屏、車機等分布式設備的通信基座，為設備之間的互聯互通提供了統一的分布式通信能力，為設備之間的無感發現和零等待傳輸創造了條件。依托軟總線技術，可以輕松實現多台設備共同協作完成一項任務，任務也可以由一台設備傳遞至另一台設備繼續執行。對於用戶而言，無需關注多台設備的組網，軟總線可以實現自發現、自組網。對於開發者而言，也無需針對不同設備開發不同版本的軟件、適配不同的網絡協議和標准規范。
2.2分布式軟總線的原理
相較於傳統計算機中的硬總線，鴻蒙系統中的分布式軟總線是一條虛擬的、“無形”的總線。可以連接同處於一個局域網內部的所有鴻蒙設備（1+8+N，如下圖所示），並且具有自發現、自組網、高帶寬和低時延等特點。
圖3：軟總線連接1+8+N設備
除了連接處於同樣網絡協議中的硬件設備，軟總線技術還支持對不同協議的異構網絡進行組網。傳統場景下，需要藍牙傳輸的兩台設備必須都具有藍牙，需要WiFi傳輸的設備必須都具有WiFi。而藍牙/WiFi之間是無法進行數據通信的。軟總線提出藍牙/WiFi融合網絡組網技術（架構如下圖所示），解決了不同協議設備進行數據通信的問題。使得多個鴻蒙設備能夠自動構建一個邏輯全連接網絡，用戶或者業務開發者無需關心組網方式與物理協議。
圖4：軟總線中異構網絡組網方案
傳統協議的傳輸速率差異較大，多設備交互式時延和可靠性也難以保證。軟總線傳輸提出三個目標：高帶寬、低時延、高可靠。相較於傳統網絡的7層模型，軟總線提出了4層的“極簡協議”（如下圖所示），將中間的4層協議精簡為一層以提升有效載荷，有效帶寬提升20%。設備間基於UDP協議進行數據傳輸，摒棄傳統滑動窗口機制，實現丟包快速回復，且具有智能網絡變化感知功能，可以自適應流量控制和擁塞控制。
圖5：軟總線提出“極簡協議”
2.3分布式軟總線源碼分析
注意：筆者所分析源碼為軟總線模塊部分，如需獲取軟總線源碼，請訪問網址：https://gitee.com/openharmony/communication_services_softbus_lite。瀏覽整個軟總線組件的源碼，可知其分為以下4個單元（代碼結構如下圖所示）：
1，discover：提供基於COAP協議的設備發現機制；
2，authmanager：提供設備認證機制和知識庫管理功能；
3，trans_service：提供身份驗證和數據傳輸通道，
4，os_adapter：檢測運行設備性能，決定部分功能是否執行。
圖6：分布式軟總線組件源碼整體架構
由於整個軟總線組件代碼量較多（筆者粗略估算在5000行上下），為表述清晰，部分細節可能會作適當忽略（如忽略各頭文件）。因os_adapter部分並非軟總線模塊的功能重點，此處將不做討論（簡要說明，os_adapter的功能是判斷當前運行設備的性能，以決定部分功能是否啟用，如多線程機制）。本報告采用圖文結合的形式，先對3個核心部分（discovery、authmanager、trans_service）的功能進行簡要概述，最后將各單元聚合進行整體代碼執行流程的分析。
2.3.1 discover部分
作為鴻蒙OS分布式軟總線重要組成單元，discovery單元提供了基於coap（Constrained Application Protocol，受限應用協議，RFC7252）協議的設備發現機制。為什么使用coap協議？是因為考慮到運行harmonyOS的設備除了硬件性能較好的手機、電腦等設備外，還有資源受限的物聯網設備，這些設備的ram、rom相對較小。coap協議支持輕量的可靠傳輸，采用coap協議，可以擴大組網的范圍。
discovery的實現前提是確保發現端設備與接收端設備在同一個局域網內且能互相收到對方的報文。流程為以下三步：
1，發現端設備，使用coap協議在局域網內發送廣播；
2，接收端設備使用PublishService接口發布服務，接收端收到廣播后，發送coap協議單播給發現端；
3，發現端設備收到回復單播報文,更新設備信息。
discovery部分代碼由兩部分組成（目錄如下圖所示）。其中coap部分是coap協議的封裝實現，discovery_service是基於coap協議的設備間發現流程的實現。
圖7：discovery部分源碼目錄結構
coap目錄中：
（1）coap_def.h：定義coap協議包的格式、報文結構，且使用UDP協議傳輸；
（2）coap_adapter.c：實現coap協議通訊雙方使用的編碼、解碼函數；
（3）coap_socket.c：實現coap包的發現、接收服務；
（4） Coap_discovery.c：實現基於coap協議的設備發現功能。本文件定義了socket通訊過程，有興趣的讀者可以深入閱讀。后文也會對本文件關鍵函數流程做分析。
discovery_service目錄中：
（5）comman_info_manager.h：定義了鴻蒙系統當前支持的設備類型與級別；
（6）Discovery_service.c：實現了設備暴露、發現和連接流程。這里需要注意的是，考慮到同一局域網下，主設備發出連接請求廣播后，多個物聯網設備都會回復單播應答報文從而造成信道沖突。為避免此情況發生，每個物聯網設備均維護一套信號量機制，實現多設備的有序等待。
2.3.2 authmanager部分
作為軟總線代碼執行流程中的第二部分：authmanager單元提供了設備認證機制。設備通過加密和解密的方式，互相建立信任關系，確保在互聯場景下，用戶數據在對的設備之間進行流轉，實現用戶數據的加密傳輸。軟總線中定義加密和解密算法的內容在trans_service/utils/aes_gcm.h中，authmanager中的處理流程如下圖所示：
圖8：加密傳輸建立設備間信任關系
authmanager單元代碼目錄結構如下圖所示：
圖9：authmanager代碼結構
authmanager目錄中：
（1）auth_conn.c：提供發送、接收、認證和獲取密鑰的功能；
（2）auth_interface.c：管理會話、鏈接、密鑰節點，提供增刪改查功能；
（3）msg_get_deviceid.c：以cJSON格式獲取各個設備的信息，包括設備id、鏈接信息、設備名、設備類型等；
（4）bus_manager.c：創建不同的listen，用以監聽系統上有哪些device並創建新的device節點，以及節點數據的處理。bus_manager.c主要由discovery單元調用，通過判斷本文件中flag標志位決定是否啟動總線（start_bus()函數）或關閉當前總線（stop_bus()函數）。discovery調用后，bus_manager執行流程如圖10：
（5）wifi_auth_manager.c：實現了鏈接管理和數據接收功能。
圖10：bus_manager.c中函數執行流程圖
2.3.3 trans_service部分
經過第一階段協議確定、設備發現過程，以及第二階段設備鏈接過程，軟總線模塊執行到了第三階段：數據傳輸階段，即目錄中trans_service單元。trans_service模塊依賴於harmonyOS提供的網絡socket服務，向認證模塊提供認證通道管理和認證數據的收發；向業務模塊提供session管理和基於session的數據收發功能，並且通過GCM模塊的加密功能提供收發報文的加密/解密保護。如下圖所示為trans_service模塊在系統架構中的位置：
圖11：trans_service模塊在OS結構中的位置
閱讀本單元部分源碼，可知數據傳輸單元的源碼目錄如下：
圖12：trans_service模塊源碼目錄
在libdistbus目錄中，各源碼文件的實現功能均已給出（如上圖12），其中需要注意的是，軟總線啟動后，設備在發現階段基於coap協議使用udp數據報進行通訊。當設備認證通過，確認連接后，將會使用TCP協議進行更加安全可靠的通訊。同發現階段避免多設備同時向主機回復單播報文產生信道沖突一樣，這里也維護了一套信號量機制避免多設備互連時產生資源沖突。對這部分感興趣的讀者可以繼續閱讀trans_lock.c文件，這里不再贅述。
2.3.4 軟總線代碼執行流程
通過對3個核心組成部分的源碼進行簡單的分析，相信讀者已經對軟總線的具體結構和各部分功能有了一定了解。下面，我們將融合這3個單元，對軟總線啟動后的源碼執行流程做進一步分介紹。
在分布式軟總線的設計中，trans_service模塊是在authmanager模塊中被初始化的，而authmanager模塊又被discovery模塊初始化，因此設備在向外發布本設備信息的過程中，這三個相互關聯的模塊會以“發現→認證→傳輸”的順序完成初始化（如下圖13）。
圖13：3個模塊的激活順序
為了便於理解軟總線執行流程，屏蔽具體函數細節，筆者將這一過程中的函數調用關系繪制成圖（篇幅所限，圖片置於文末），並標注了執行順序，讀者可以按照流程圖進行閱讀。源碼文件數目較多，且文件之間的調用關系錯綜復雜，若有疏漏錯誤之處，望讀者見諒。
3 編譯、運行軟總線模塊
3.1編譯分布式軟總線模塊
軟總線模塊的運行需要較多鴻蒙OS頭文件參與，這里采用將軟總線組件綁定至鴻蒙OS全量代碼的基礎上共同編譯。編譯過程如下。
圖14： 編譯所用的虛擬機環境
便攜配置文件Makefile如下：
執行Makefile編譯操作，得到生成的軟總線鏡像文件so，如下圖所示。
3.2測試軟總線模塊
這里使用官方的測試demo來測試我們編譯完成的軟總線組件模塊。Demo程序如下所示：
編譯demo，如下圖所示：
使用sudo權限來執行生成的可執行文件PublishService，執行結果如下圖所示，測試成功：
4 參考資料
1，潤小雲解讀鴻蒙OS系列https://my.oschina.net/u/4786275,
2，華為官方開發者文檔https://device.harmonyos.com/cn/docs/develop/kernel/oem_ke
rnal_user_process-0000001050032733
3，鴻蒙分布式軟總線技術研究-阮旭東