DSoftBus Application Based on Containers

Background

Migrating user software to containers is an inevitable trend. This document describes how to deploy DSoftBus based on containers, simplifying the installation and deployment of DSoftBus clients and facilitating compatibility with service software.

Environment Setup

Hardware devices

Code Repository

https://gitee.com/openeuler/distributed-codelabs.git

Description

Installing the Services

Perform the following steps on both devices.

1. To install openEuler 22.03 LTS SP2 or later on a physical machine, the Binder driver must be installed in the environment.

2. Build softbus_client.

   bash distributed-codelabs/build-repo/demo/dsoftbus/build.sh
   

3. Install softbus_server.

   dnf install dsoftbus -y
   

4. Start softbus_server.

   /system/bin/start_services.sh all
   

Testing the Multi-Client Container Scenario

1. Run the script to build and load the container image on device A.

   bash distributed-codelabs/build-repo/demo/dsoftbus/docker_img_build.sh
   

2. Start the softbus_client container image on device A and map the SDKs and binder driver to the container.

   docker run  -it  --privileged --net=host --name=softbus  -v /dev/binderfs/binder:/dev/binder  -v  /system:/system  -v /usr/lib64:/usr/lib64  -p 5684:5684/udp softbus_client_image  bash
   

3. Write to the /etc/SI file in the image as the flag of the DSoftBus client in the container. Note that the flag must be different from those of other clients on the network to avoid conflicts.

   echo 123 > /etc/SI
   

4. Start softbus_client in the container.

   ./home/softbus_client
   

5. You can repeat steps 2 and 3 to start different client containers on this node.

6. Start DSoftBus on device B.

   ./build-repo/demo/dsoftbus/softbus_client
   

7. Run the following command on each client of device A to enable all connections:

   openA
   

8. View all opened sessions on the client of device B.

   conDevices
   

   The command output indicates that two sessions whose IDs are 4 and 3 have been opened. The session IDs are allocated by softbus_server of the local host and will be used for subsequent message sending.

   conDevices
   12-11 20:18:58.350 2780335 2780335 I A0fffe/SOFTBUS_DEMO: [SOFTBUS_DEMO]::PrintConnectedDevicesInfo: sessionId:4, networkId: 3c95f61941b81c48ecd73fef881262b82fcbc58e9b1f545e2097b0dc6fecea37
   12-11 20:18:58.350 2780335 2780335 I A0fffe/SOFTBUS_DEMO: [SOFTBUS_DEMO]::PrintConnectedDevicesInfo: sessionId:3, networkId: 3c95f61941b81c48ecd73fef881262b82fcbc58e9b1f545e2097b0dc6fecea37
   

9. Use device B to send a message to the client of device A through session 4.

   send 4 "hello4"
   12-11 20:19:14.975 2780335 2780335 I C015c0/dsoftbus: [TRAN]SendBytes: sessionId=4
   

   If output is displayed in a client of device A, the client communicates with device B through session 4. Similarly, you can send messages to another client through session 3.

10. Use the client in the container of device A to send a message to the client of device B and check the opened session ID.

    conDevices
    12-11 20:25:48.995 344047 344047 I A0fffe/SOFTBUS_DEMO: [SOFTBUS_DEMO]::PrintConnectedDevicesInfo: sessionId:1, networkId: e69eab4e2d657264dfbb2006fdfa15524f4a27edeff0baa26d5d2a2b9502f300
    

    The output indicates that session 1 is used for communication.

11. Send a message. If device B receives the string, the message is received successfully.

    send 1 "hello1"
    

12. Use the client of device A to send a message to the client of device B and check the opened session ID.

    conDevices
    12-11 20:37:24.823 3512580 3512580 I A0fffe/SOFTBUS_DEMO: [SOFTBUS_DEMO]::PrintConnectedDevicesInfo: sessionId:1, networkId: e69eab4e2d657264dfbb2006fdfa15524f4a27edeff0baa26d5d2a2b9502f300
    

    The output indicates that session 1 is used for communication.

13. Send a message. If device B receives the string, the message is received successfully.

    send 1 "hello1"
    

Session ID Description

In the test in the previous section, it is found that the session IDs used for communication between the two clients are different. The reason is that the session IDs are allocated by the server on the local host and are unique only on the local host. Similarly, the session names and group names of the container are isolated from those of the VM. Therefore, the session IDs of the local container are the same as those of the client on the VM.