Abstract: This article shares the hongmeng distributed soft bus, and carries on the analysis to the relevant source code, for the information reference and guidance of the relevant personnel working on the Hongmeng system platform.
Bus is an internal structure, in the computer system, the host of each component connected through the bus, external devices through the corresponding interface circuit and then connected with the bus, is the CPU, memory, input, output devices to transmit information public channel. According to the type of information transmitted, it can be divided into data, address and control bus, which are used to transmit data, data address and control signal respectively.
The mission and goal of HarmonyOS is to connect devices together to become the “universal language” of devices. HarmonyOS is a system that connects all connected smart devices to achieve the ultimate goal of connecting everything. One of its core capabilities, [Distributed Soft Bus], integrates multiple devices into “one device”, bringing smooth connection experience with high throughput, low latency and high reliability within and between devices.
This article shares hongmeng distributed soft bus, and carries on the analysis to the relevant source code, serves as the information reference and the guidance to the relevant personnel who works on this platform. Please refer to hongmeng official website for specific development.
1. The salt interface
Devices have various communication modes, such as USB, WIFI and BT. The communication modes are greatly different and cumbersome, and it is difficult to guarantee the integration, sharing, conflict and security of links.
Hongmeng Distributed soft bus is committed to realizing unified distributed communication capability among near-field devices, providing equipment discovery and transmission interface with no distinction between links, enabling fast discovery and connection of devices, efficient task distribution and data transmission. As a unified base for multi-terminal devices, it is the underlying technology and the main artery of Hongmeng architecture. Its overall goal is to realize non-inductive detection and zero-wait transmission between devices. For developers, there is no need to pay attention to networking and underlying protocols.
2. Distributed soft bus features
The design goal of Hongmeng distributed soft bus is to promote the minimalist communication protocol technology, which can be connected and used in device security scenarios. Key technical features cover automatic device discovery and connection, networking (multi-hop AD hoc networking, multi-protocol hybrid networking), transmission (diversified protocols and algorithms, intelligent awareness and decision).
2.1 Self-discovery & Connection between Devices
Distributed soft bus proposes automatic device discovery to realize users’ zero-wait self-discovery experience. Nearby devices with the same account are automatically discovered without waiting and automatically connect securely.
IoT devices are classified into the discovery end and the discovered end. The discovery end is usually the device that requests service or the master device, usually a smart screen device (such as a mobile phone or tablet). The device to be discovered refers to the release service device, which refers to the lightweight device (such as AI speaker, smart home, smart wear, etc.). At present, the devices of the soft bus are interconnected. Ensure that the discoverer and discoverer are on the same LAN.
2.2 Multi-device Interconnection and Networking
Based on the network interconnection, interactive system, developers often need to adapt to different network protocols and standards. However, in the distributed development mode set by Hongmeng system, there is no need to care about the difference of network protocol and networking mode, business development and equipment networking are decoupled, and only need to monitor the equipment up and down, which greatly reduces the development cost.
Distributed soft bus proposes heterogeneous network, which automatically constructs a logical fully connected network to solve the problem of different protocol interaction between devices. After the device goes online, it registers with the network layer. At the same time, the network layer establishes a channel connection with the device to detect the device transformation in real time. The network layer is responsible for managing the online and offline transformation of devices. Devices can monitor the devices they are interested in, and establish a connection with the devices immediately after they go online, realizing zero-wait experience.
2.3 Data transmission between multiple devices
The sessionId provides unified session-based authentication and transmission functions. Upper-layer service systems can use the sessionId to send and receive data or obtain related basic properties, and realize operation interactions such as service messages, flows, and control instructions.
3. Soft bus protocol COAP
WEB applications of the Internet are ubiquitous, and many rely on the REST protocol architecture. To support REST on most constrained nodes (such as 8-bit microcontrollers with limited RAM and ROM) and on constrained networks (such as 6LoWPAN), engineers tackled “constrained restful environments,” or CoRE. Limited networks such as 6LoWPAN support the splitting of IPv6 data into small packets, but greatly reduce transmission efficiency.
One of the main goals of CoAP(Constrained Application Protocol) is to design a common Web Protocol that keeps the overhead very low to meet the special requirements of Constrained environments, such as energy, building automation, or other M2M applications. Implements a generic HTTP subset of REST that simplifies M2M applications rather than blindly compressing HTTP. The COAP protocol can be easily converted to HTTP, facilitating conversion with existing WEB architectures, as well as providing built-in discovery, multicast support, and asynchronous messaging.
3.1 COAP Features
An application-layer protocol that runs on TOP of UDP rather than TCP like HTTP.
- COAP network transport layer is changed from TCP to UDP.
-
Based on REST, the resource address of the server is similar to the URL format. The client also has POST, GET,PUT, and DELETE methods to access the server, simplifying HTTP.
-
COAP is binary format, HTTP is text format, COAP is more compact than HTTP;
-
Small and lightweight, the minimum length is only 4 Bytes, an HTTP head is dozens of Bytes;
-
Support reliable transmission, data retransmission, block transmission;
-
Support IP multicast, can send requests to multiple devices at the same time, hongmeng device discovery function is to use this feature;
-
Non-long-connection communication, suitable for low-power Internet of Things scenarios;
-
Support observation mode;
3.2 Protocol Type and structure
The COAP protocol has four message types.
- CON: confirmation is required. If a CON request is sent, the other party must respond to acknowledge receipt of the message for reliable message transmission.
- NON: A request that does not need to be acknowledged. If a NON request is sent, the other party does not need to respond. This mode is used when messages are frequently sent. Packet loss does not affect normal operations. Much like UDP, it is used for unreliable message transmission;
- ACK: indicates the reply message corresponding to the CON message.
- RST: reset message. The RST message must be returned if the received message is not recognized or incorrect during reliable transmission.
Protocol Structure Definition
In the source discovery/coap/include/coap_def. H of coap protocol structure are defined.
3.3 Transmission of COAP packets
The transmission mode is client – side and server – side. The server – side starts the listening service of COAP package.
Source discovery/coap/include/coap_socket. H provides the coap package send and receive function definition.
3.4 DISCOVERING COAP Devices
Source discovery/coap/source/coap_discover. C realized based on coap device discovery function.
3.5 COAP security
TLS cannot be used to secure data transmitted over UDP, so Datagram TLS attempts to extend the existing TLS architecture to support UDP.
COAP security is implemented using DTLS encryption. The implementation of DTLS requires a lot of resources and bandwidth. If it is a terminal with very few resources and a very limited bandwidth, it may not run. DTLS is only applicable in unicast cases.
4. Source code structure and analysis
The source code of distributed softbus is in communication_services_softbus_lite. The structure is as follows:
All source files under the directory will be compiled into a dynamic library, other dependency modules at the time of compilation with the dynamic library can be dependent. For example, the compilation of the bin file foundation, where the distributed scheduling subsystem is located, relies on this dynamic library.
4.1 Initialization of the soft bus
StartListener() is suitable for different versions of platforms, reflecting the modular design idea of decoupling each part, and combining the OS most suitable for different hardware devices. For example, threads are created using a uniform static void WaitProcess(void) function that encapsulates adaptation code for different underlying apis.
4.2 OS Adaptation Layer
The underlying operating system of HarmonyOS can be HarmonyOS Micro Kernel, Linux Kernel, and Lite OS will be a complete microkernel architecture.
The functions used in the internal modules of hongmeng system need to support the adaptation of different versions of platforms, reflect the modular design idea of decoupling of each part, and combine the OS most suitable for different hardware devices. For example, threads are created using a uniform static void WaitProcess(void) function that encapsulates adaptation code for different underlying apis. SemCreate creates semaphores using LOS_SemCreate in LiteOS and sem_init() on Linux using the Posix standard interface.
Source directory OS_Adapter code is to achieve distributed soft bus adaptation to the operating system.
LiteOS
Huawei is facing the field of Internet of things development of a lightweight operating system based on real-time kernel, the existing basic kernel support task management, memory management, time management, communication mechanism, interrupt management, queue management, event management, timer based components, such as the operating system to better support the scene, low power consumption support tickless mechanism, support the timer alignment.
The LiteOS open source project supports ARM Cortex-M0, Cortex-M3, Cortex-M4, cortex-M7 and other chip architectures.
4.3 Discovering and Connecting devices
Each device is pushed and published in the form of service, after which peripheral devices can discover, connect and communicate with it. The source code is located in the discovery\ Discovery_service \ Source directory.
The lightweight device acts as the discovered end device and invokes the PublishService to publish the service. Entry code screenshot:
The following is a screenshot of code parsing in the operation sequence for your reference.
1) Permission check
The OS_Adapter is suitable for operating systems (oss). The encapsulated functions have different implementations in different oss. For example, SemCreate creates semaphores using LOS_SemCreate on LiteOS, while Linux uses sem_init() on Posix.
2) Parameter check
3) Create a semaphore
4) Initialize the service
A) CoapInit
COAP initialization, registration of TCP/IP protocol stack processing, registration of the underlying session socket operation processing.
B) CoapWriteMsgQueue()
Write message, trigger to obtain Wifi IP address, start the bus.
5) Add information to ****Module
6) Register COAP service
. Note: will g_localDeviceInfo serverData assignment as “port: auth_port”, auth_port is based on the TCP socket binding certification service port (in StartBus function assignment).
7) The callback was published successfully
Call PublishCallback() to execute the successful publishing callback in cb.
4.4 Device Authentication Management
For interconnection and communication between devices, point-to-point trust relationships must be established, and secure connection channels must be established between trusted devices to implement end-to-end encrypted transmission of user data. The process of establishing a peer-to-peer trust relationship is the process of exchanging device identifiers. The establishment of A trust relationship is equivalent to A handshake. For example, device A sends ciphertext to device B. Device B decrypts the ciphertext successfully, encapsulates its own information in A packet, and sends the packet to device A. Device A decrypts the packet again to confirm that it is DEVICE B.
Authmanager module is the module that Hongmeng provides authentication mechanism for devices. The main processing process in the module includes the steps of receiving, decrypting, re-encapsulating, encrypting and sending messages. For example, when a request is found, the ProcessDataEvent(wifi_AUTH_manager) function is called to collect the packet, examine the packet header, and determine different processing methods based on the packet type. There are three types of data packets:
- MODULE_AUTH_SDK Encrypted data type
- MODULE_TRUST_ENGINE Indicates the trusted type, which directly transfers data
- MODULE_CONNECTION IP and device authentication
1) The internal structure of the module
2) Encryption sending steps and algorithms
Aes-gcm encryption algorithm: AES is a symmetric encryption algorithm. GCM adopts Counter mode for symmetric encryption and carries GMAC message authentication code. Aes-gcm algorithm is an algorithm with authentication and encryption, and can generate encrypted data and authentication codes for a given text.
3) Interconnection security of Hongmeng equipment
The following is the device interconnection security reference chart of hongmeng official website document
In the scenario of device interconnection, user data can be securely transferred between devices to ensure the secure transmission of user data.
Bound process
- The device generates Ed25519 key pair respectively.
- The key negotiation between PIN code and Password Authenticated Key Exchange (PAKE) is used to generate session keys.
- Encrypt each other’s public keys with the session key (you don’t need encryption, just calculate a MAC, as long as you can verify that the public key is from the other party)
- The identity id public key here should refer to the binary (device ID, public key)
Flow of communication
- Negotiation of session keys through public keys; How to use the session key? Generally, the session key that is initially negotiated is divided into encryption key and MAC key.
- Use session keys to encrypt communication data.
When communicating with a master device that establishes a trust relationship, the two sides bind the trust relationship first and then authenticate each other based on the local peer public key. Bidirectional identity authentication and session key negotiation are completed during each communication. The device then uses the session key to decrypt the transmission channel between the two devices.
4.5 Authentication and Session Transmission
The trans_service module relies on the network socket service provided by the OS, and provides authentication channel management and authentication data sending and receiving for the authentication module. It provides session management and session-based data sending and receiving functions for business modules, and provides encryption and decryption protection for incoming and outgoing packets through the encryption function of GCM module.
The discovered end (lightweight device) registers and publishes the service. After the service succeeds, the discovered end uses the CreateSessionServer to create a session server and waits for the connection and session creation on the discovered end. The discovery end (for example, an intelligent screen device) establishes a session based on the service name and device ID to transfer data between services.
Data transmission part of the source code in trans_service/source/libdistbus directory.
The main processing steps are as follows:
**CreateSessionServer[** session] a SelectSessionLoop[data] a OnBytesReceived[callback]
1) CreateSessionServer**** Creates a session
2) SelectSessionLoop
After starting the bus, a TCP-based session management service is created. The task thread of the service is SelectSessionLoop, which handles all session data receiving.
3) OnBytesReceived
The callback function for the arrival of session data, which calls onBytesReceived registered by the upper-layer application. Receives session packets, parses the format, and performs corresponding actions. In a distributed scheduling module, this might be the START_FA command.
After the most
Distributed soft bus is the base module of Hongmeng operating system, and also the cornerstone of distributed data management and distributed task scheduling. A thorough understanding of distributed soft bus is the foundation of the whole Hongmeng OS.
This paper is based on the open source code of the distributed soft bus module into the analysis, analysis, the article will have part of the source code analysis, scene analysis is not fully covered, the follow-up will be based on the situation of the relevant supplement.
For details, please refer to developer.harmonyos.com/
Click to follow, the first time to learn about Huawei cloud fresh technology ~