Trans in soft bus module_ Service directory analysis summary

This paper mainly summarizes trans under soft bus module_ The functions and functions of a file in the service directory are macroscopically grasped_ The role of service in Hongmeng system.
trans_ The service module relies on the network socket service provided by the system OS to provide authentication channel management and authentication data sending and receiving to the authentication module; Provide session management and session based data sending and receiving functions to the business module, and provide encryption and decryption protection of sending and receiving messages through the encryption function of GCM module.

Related articles

Here I share my teammates' summary and analysis of authmanager module. Some flow charts in this paper are drawn by my teammates.
Summary of distributed soft bus / authmanager module

1, Introduction to distributed soft bus

1.1 bus

Bus (bus) is a very broad concept, which is widely used in the traditional computer hardware system. It is an internal structure and a common channel for cpu, memory, input and output devices to transmit information. Each component of the host is connected through the bus, and the external devices are connected with the bus through the corresponding interface circuit, so as to form the computer hardware system In the computer system, the common path for transmitting information between various components is called bus. Microcomputer connects various functional components with bus structure. According to the types of information transmitted by the computer, the computer bus can be divided into data bus, address bus and control bus, which are used to transmit data, data address and control signal respectively.

2.2 definition of distributed soft bus

Distributed soft bus technology is based on Huawei's years of accumulation of communication technology and referring to the computer hardware bus to build an "invisible" bus between 1+8+N (1-mobile phone, 8-car / speaker / headset / watch /) devices, which has the characteristics of self discovery, ad hoc network, high bandwidth and low delay.

Distributed services such as device virtualization, cross device service invocation, multi screen collaboration and file sharing can be completed between devices in the whole scene based on soft bus.
Typical characteristics of distributed soft bus:

• Autodiscover / connect
• High bandwidth
• Low delay
• High reliability
• Open / standard

2.3 function and principle of distributed soft bus

2.3. 1 architecture of distributed soft bus

The protocol differences of various devices are shielded through the protocol shelf and the software and hardware cooperation layer. The bus hub module is responsible for parsing commands, completing the discovery and connection between devices, and realizing the functions of file transmission and message transmission between devices through the two buses of task and data.

The overall goal of distributed bus is to realize senseless discovery and zero waiting transmission between devices. To achieve this goal, three problems need to be solved:

(1) Discovery and connection between devices: from manual discovery to self discovery
For example, there are many photos on the mobile phone that need to be transmitted to the personal PC. we can use Bluetooth transmission. First, turn on the Bluetooth discovery function of the mobile phone and PC. the mobile phone or PC can click the search device, then pair and authorize each other to connect. After successful connection, we can send photos.

In the scene of sharing photos, there are many artificial actions: turning on the Bluetooth discovery function, searching devices and pairing authorization. This is really a little troublesome and takes a lot of time, which may reduce the willingness to share.

The soft bus puts forward the concept of automatic discovery to realize the user's self discovery experience of zero waiting. Devices with the same account nearby can be found automatically without waiting.

(2) Networking technology after multi device interconnection: soft bus networking heterogeneous networking
In the above example, the mobile phone transmits photos through Bluetooth. If the PC has no Bluetooth function and only WIFI, sharing transmission may not be realized in traditional scenarios. Because different networking methods are isolated, we need to solve many networking problems between heterogeneous networks

The heterogeneous network networking proposed by the soft bus can well solve the interaction problem of different protocols between devices, which solves the problem that the mobile phone transmits through Bluetooth and the PC receives photos through WIFI. The solution is shown in the figure below.

After the equipment goes online, it will register with the network layer, and the network layer will establish a channel connection with the equipment to detect the transformation of the equipment in real time. The network layer is responsible for managing the on-line and off-line transformation of devices. Devices can monitor the devices they are interested in. After the devices are online, they can establish a connection with them immediately to realize a zero waiting experience. The soft bus can automatically build a logical fully connected network, and users or business developers do not need to care about the networking mode and physical protocol. For software developers, soft bus heterogeneous networking can greatly reduce their development cost.

Traditional development mode: in the traditional development mode, developers need to adapt to different network protocols and standards.

Distributed development mode: in the HarmonyOS distributed development mode, the development no longer needs to care about the differences of network protocols. The business development is decoupled from the equipment networking. The business only needs to monitor the equipment up and down, and the development cost is greatly reduced.
(3) Transmission technology between multiple devices and multiple protocols
The transmission rate of traditional protocols is very different, and the delay is difficult to be guaranteed. Therefore, the objectives of soft bus transmission include: High Speed, Low Latency and High Reliability

The sharp weapon of these three goals to be achieved by soft bus is: minimalist protocol.

The minimalist protocol reduces the middle four layer protocol stack to one layer, improves the payload, improves the effective transmission bandwidth by 20%, and enhances it on the basis of traditional network protocols:

• Streaming transmission: realize sequence preserving and reliable data transmission based on UDP;
• Two wheel drive: subvert the traditional TCP per packet acknowledgement mechanism;
• Not afraid of network loss: abandon the traditional sliding window mechanism, quickly recover packet loss and avoid blocking;
• No fear of jitter: intelligent sensing of network changes, adaptive flow control and congestion control;

2, Code analysis

In the source code directory, we can see through ls that it is mainly divided into four directories: authmanager, discovery and trans_service, and OS for compatible system differences_ adapter.

• discover: provide device discovery mechanism based on COAP protocol;
• authmanager: provides equipment authentication mechanism and knowledge base management function;
• trans_service: provides authentication and data transmission channels;
• os_adapter: check the performance of running equipment and determine whether some functions are executed.

This paper mainly analyzes trans_service directory
trans_service rough analysis

trans_ The code in the service directory provides authentication and transport channels. It mainly encapsulates socket, cJSON and thread lock interfaces, realizes user creation, monitoring, session management, and acquisition of equipment, instructions, data and other information, and finally provides encryption and decryption transmission channels. trans_ The service module relies on the network socket service provided by the system OS to provide authentication channel management and authentication data sending and receiving to the authentication module; Provide session management and session based data sending and receiving functions to the business module, and provide encryption and decryption protection of sending and receiving messages through the encryption function of GCM module.

Overview of code files of each part

• auth_conn_manager.c
  User creation, monitoring, connection and other service management;
• tcp_session_manager.c
  Session management;
• trans_lock.c
  Mutex initialization and mutex resource acquisition and release;
• aes_gcm.c
  Provide encrypted transmission and decryption transmission interfaces;
• messages.c
  It is used to obtain information such as device (including device name, device type, device ID, etc.), instruction, data, session (including user port, session port, etc.) managed in cJSON format;
• tcp_socket.c
  Port number management and data transmission management.

trans_service details
1. Initialization
In the design of distributed soft bus, trans_ The service module is initialized in the authmanager module, and the authmanager module is initialized by the discovery module. Therefore, the device completes the initialization of these three interrelated modules in the process of publishing its own device information.
There is a StartBus() function in the authmanager module. The StartListener() function is responsible for providing channels for the authentication module to complete initialization, and the StartSession() function is responsible for initializing the session management of the service:

//Start bus communication
int StartBus(void)
{
    if (g_busStartFlag == 1) {
        return 0;
    }
    //Get device information
    DeviceInfo *info = GetCommonDeviceInfo();
    if (info == NULL) {
        return ERROR_FAIL;//-1
    }

    g_baseLister.onConnectEvent = OnConnectEvent;
    g_baseLister.onDataEvent = OnDataEvent;
    //Get the port through the function GetSockPort(g_listenFd) in the listening function
    int authPort = StartListener(&g_baseLister, info->deviceIp);
    if (authPort < 0) {
        SOFTBUS_PRINT("[AUTH] StartBus StartListener fail\n");
        return ERROR_FAIL;
    }
    //Device port assigned to info
    info->devicePort = authPort;
    //Start a session and get the session port through IP
    int sessionPort = StartSession(info->deviceIp);
    if (sessionPort < 0) {
        SOFTBUS_PRINT("[AUTH] StartBus StartSession fail\n");
        StopListener();//Stop listening
        return ERROR_FAIL;
    }
    //g in front of the variable name indicates the global variable under the file
    AuthMngInit(authPort, sessionPort);
    g_busStartFlag = 1;

    SOFTBUS_PRINT("[AUTH] StartBus ok\n");
    return 0;
}

The implementation principle of authentication communication is similar to that of business session. In this paper, we take a simple authentication communication code as an example to illustrate the typical processing flow.

The initialization entry is in the StartListener. There are adaptation functions corresponding to different versions of platforms at the bottom of the StartListener() function, which confirms the modular design idea of decoupling all parts of Hongmeng OS and combines them into the OS most suitable for different hardware devices. For example, a unified static void WaitProcess(void) function is used when creating threads, and the adaptive code of different underlying API s is encapsulated inside.

int StartListener(BaseListener *callback, const char *ip)
{
    if (callback == NULL || ip == NULL) {
        return -DBE_BAD_PARAM;
    }
    //If one of the callback variable and ip is null, - DBE is returned_ BAD_ PARAM
    g_callback = callback;

    int rc = InitListenFd(ip, SESSIONPORT);//Call the function to initialize listen ing
    if (rc != DBE_SUCCESS) {//This if is used to determine whether the initialization function is executed successfully
        return -DBE_BAD_PARAM;//If initialization fails, - DBE is returned_ BAD_ PARAM = -300+0
    }

    signal(SIGPIPE, SIG_IGN);//Installs a new signal processing function for the specified signal.
    ThreadAttr attr = {"auth", 0x800, 20, 0, 0};
    register ThreadId threadId = (ThreadId)AuthCreate((Runnable)WaitProcess, &attr);
    if (threadId == NULL) {//If the return value is NULL, the creation fails
        SOFTBUS_PRINT("[TRANS] StartListener AuthCreate fail\n");
        return -1;
        //The return value is - 1, and relevant information is output
    }
    return GetSockPort(g_listenFd); 
    //GetSockPort will get an address related to the socket. The server can get the relevant client address through it, and the client can also get the ip and port of the socket that has been successfully connected.
    //Finally, a 16 bit number is returned, which is converted from network byte order to host byte order
 
}

StartListener() calls InitListenFd() function to create and listen to TCP socket s. The IP address and port number are specified by the upper layer caller.

static int InitListenFd(const char *ip, int port)//Initialize listen device
{
    if (ip == NULL || g_listenFd != -1) {
        return -DBE_BAD_PARAM;//Check parameters
    }

    if (strncmp(ip, "0.0.0.0", strlen(ip)) == 0) {//Compare ip and 0.0 0.0, roughly whether the ip is valid
        return -DBE_BAD_PARAM;
    }

    int rc = OpenTcpServer(ip, port);//Open the Tcp server based on ip and port
    if (rc < 0) {
        SOFTBUS_PRINT("[TRANS] InitListenFd OpenTcpServer fail\n");
        return rc;
    }
    g_listenFd = rc;
    RefreshMaxFd(g_listenFd);

    rc = listen(rc, DEFAULT_BACKLOG);//Monitoring rc equipment
    if (rc != 0) {//Check whether the monitoring is successful
        SOFTBUS_PRINT("[TRANS] InitListenFd listen fail\n");
        StopListener();
        return -DBE_LISTEN_FAIL;
    }

    return DBE_SUCCESS;
}

As mentioned above, AuthCreate() can be implemented differently on different platforms, such as liteos_ On a and Linux platforms, AuthCreate() will call POSIX compatible pthread_create() completes the creation of the thread. The entry function of the thread is static void WaitProcess(void).

ThreadId AuthCreate(Runnable run, const ThreadAttr *attr)/*Creating auth permissions is thread based*/
{
    pthread_attr_t threadAttr;//Thread variable
    pthread_attr_init(&threadAttr);//Initialize thread
    pthread_attr_setstacksize(&threadAttr, (attr->stackSize | MIN_STACK_SIZE));//Setting thread variables
    struct sched_param sched = {attr->priority};
    pthread_attr_setschedparam(&threadAttr, &sched);
    pthread_key_create(&g_localKey, NULL);
    pthread_t threadId = 0;
    int errCode = pthread_create(&threadId, &threadAttr, run, NULL);//Create to spoof threads
    if (errCode != 0) {
        return NULL;
    }
    return (ThreadId)threadId;
    //Returns a structure variable threadId
}

2. Monitoring

static void WaitProcess(void)/*Static function to wait for the process*/
{
    SOFTBUS_PRINT("[TRANS] WaitProcess begin\n");
    //Start creating process output
    fd_set readSet;
    fd_set exceptfds;
    //A variable that defines the set type of two file descriptors (fd)
    while (1) {
        FD_ZERO(&readSet);
        FD_ZERO(&exceptfds);
        FD_SET(g_listenFd, &readSet);
        if (g_dataFd >= 0) {
            FD_SET(g_dataFd, &readSet);
            FD_SET(g_dataFd, &exceptfds);
        }
        int ret = select(g_maxFd + 1, &readSet, NULL, &exceptfds, NULL);//The select function is used to monitor changes in file descriptors
        //Return value: > 0: positive number of ready descriptors - 1: error 0: timeout
        if (ret > 0) {//RET > 0 indicates that the select monitoring is successful
            if (!ProcessAuthData(g_listenFd, &readSet)) {/*This function is used to obtain the information of the current process owner*/
            //If the acquisition fails, friendly output information and stop the listener
                SOFTBUS_PRINT("[TRANS] WaitProcess ProcessAuthData fail\n");
                StopListener();
                break;
            }
        } else if (ret < 0) {//RET < 0 indicates that select monitoring failed
            if (errno == EINTR || (g_dataFd > 0 && FD_ISSET(g_dataFd, &exceptfds))) {
                SOFTBUS_PRINT("[TRANS] errno == EINTR or g_dataFd is in exceptfds set.\n");
                CloseAuthSessionFd(g_dataFd);
                //Close AuthSession. See the function definition below for the function description
                continue;
            }
            SOFTBUS_PRINT("[TRANS] WaitProcess select fail, stop listener\n");
            StopListener();
            //Stop the listener and turn off g_listenFd and g_maxFd corresponding file
            break;
        }
    }
}

WaitProcess() uses busy mode and calls select() to listen for listenFd and data g_dataFd information. If it is heard that there is data readable, enter ProcessAuthData for processing. If G is found_ If datafd has exception information, close it. Where g_dataFd is the socket created when listenFd listens to the connection.
3. Processing new connections and data

static bool ProcessAuthData(int listenFd, const fd_set *readSet)
{
    if (readSet == NULL || g_callback == NULL || g_callback->onConnectEvent == NULL ||
        g_callback->onDataEvent == NULL) {
        return false;
        //Callback G_ If the event associated with the callback and the linked list is empty and the connected data file is empty, or the file descriptor set readset is empty, False is returned
    }
    if (FD_ISSET(listenFd, readSet)) {//Socket binding macro 
        struct sockaddr_in addrClient = {0};
        socklen_t addrLen = sizeof(addrClient);
        g_dataFd = accept(listenFd, (struct sockaddr *)(&addrClient), &addrLen);//The accept function specifies the server to accept the connection of the client. After receiving, it returns the identification of the client socket and obtains the "place" of the client socket
        //The first parameter of the accept function is used to identify the server socket (that is, the socket set to listen in the listen function)
        //The second parameter is used to save the "place" corresponding to the client socket (including client IP and port information)
        //The third parameter is the floor area of the "place". The return value corresponds to the client socket ID.

        //The accept function returns a non negative integer if the execution is successful, and a negative value if the execution fails
        if (g_dataFd < 0) {
            CloseAuthSessionFd(listenFd);
            return false;
        }
        //If the accept function fails, close the file corresponding to the listenFd descriptor
        RefreshMaxFd(g_dataFd);
        //Incoming g_dataFd refresh g_maxFd value, keep g_maxFd is the maximum

        if (g_callback->onConnectEvent(g_dataFd, inet_ntoa(addrClient.sin_addr)) != 0) {
            CloseAuthSessionFd(g_dataFd);
            //If G_ Corresponding descriptor in callback - > onconnectevent G_ If datafd and ip are not zero, turn off g_dataFd corresponding file
        }
    }

    if (g_dataFd > 0 && FD_ISSET(g_dataFd, readSet)) {
        g_callback->onDataEvent(g_dataFd);
    //If g_dataFd is positive and FD_ISSET check G_ If datafd is in the descriptor set readSet, g_dataFd write G_ callback->onDataEvent
    }

    return true;
}

Whether it is a new connection request or there is data in an existing connection, it will enter this function.

Function through FD_ISSET() determines whether there is a message on listenFd. If yes, it indicates that there is a new connection. At this time, accept() is called to complete the link creation, and the fd of the newly created socket is stored in G_ In datafd, G is called at the same time_ Callback - > onconnectevent notifies the authentication module of a new connection event, and notifies the authentication module of the newly created fd and client IP addresses.

At the same time, create G_ The datafd needs to be refreshed g_maxFd to ensure that G will be heard during the next select() operation in WaitProcess()_ Events on datafd.

If FD_ISSET() determines G_ If there is a message on datafd, it indicates that the handshake connection has completed and sent data to this node. At this time, the function callback G_ Callback - > ondataevent() returns control to the caller to process the received data.
4. Callback
trans_ The callback function set by the user of the service module will be called when there is a new connection and new data. For example, the authentication module completes the authentication action through the following functions: the new connection is processed in the OnConnectEvent() function, and the new data is processed in the OnDataEvent() function.

//Chaining events by fd identifier and IP
//Call the function PorcessConnectEvent()
//AddAuthConnToList(AuthConn *aconn) is called to insert conn into the tail of the linked list
int OnConnectEvent(int fd, const char *ip)
{
    ProcessConnectEvent(fd, ip);
    return 0;
}

//Find the corresponding link conn through the identifier
//If it is not empty, extract and package the information and add the information header
//IP authentication or id authentication according to the mode
//Judge whether the verification is successful according to the output text
int OnDataEvent(int fd)
{
    ProcessDataEvent(fd);
    return 0;
}

5. session processing
This part of the code is responsible for the data communication of the service. The node communicates through the name and hides the port information. The implementation principle of the code is similar to the authentication communication above. For the service requirements, the implementation of aspects such as multi-channel communication is added, which will not be analyzed in detail here.

Overall process

The discovered end (lightweight device) registers and publishes the service. After successful callback processing, the discovered end uses CreateSessionServer to create a session server and waits for the discovery end to connect and create a session. The discovery end (such as smart screen device) can establish a session according to the service name and device ID to realize data transmission between services.