Ubus provides a common framework for interprocess communication in the development of OPENWRT platforms. It makes the implementation of interprocess communication very simple, and ubus is highly portable and can be easily ported to other Linux platforms. This paper describes the implementation principle and the whole framework of Ubus.
Ubus source code can be obtained through Git library git://nbd.name/luci2/ubus.git, its dependent Ubox library's git library: git://nbd.name/luci2/ubox.git.
First.The Ubus Implementation Framework
The Ubus implementation is based on the UNIX socket, the local socket, which is more efficient and reliable relative to the INET socket for network communications. UNIX socket clients and servers are implemented in a similar way to network sockets, and readers are less familiar with the information available.
We know that implementing a simple UNIX socket server and client needs to do the following:
Create a socket server side, bind to a local socket file, and listen for clients connections. Establish one or more socket client ends to connect to the server. The client and server send messages to each other. After the client or server receives the other message, it handles the specific message accordingly.
Ubus also implements the above components and encapsulates socket connections as well as message transfer and processing:
1. Ubus provides a socket server:UBUSD. So developers don't have to implement the server side themselves.
2. Ubus provides an interface to create socket client side and provides three out-of-the-box clients for direct use by users:\
The client side provided for the shell script.
The Client interface provided for LUA scripts.
The Client interface provided for the C language.Visible Ubus adds support for Shell and Lua, followed by the use of these clients.
3. the message format for communication between client and server is defined by Ubus: Both client and server must encapsulate the message in a JSON message format .
4. Ubus Abstracts the concepts of object and method for client-side message processing. There are multiple methods in an object that the client needs to register with the server when it receives a particular JSON message. Objects and methods have their own names, and the sending requester simply specifies the name of the object and method to invoke in the message.
You need to refer to some dynamic libraries when using Ubus, mainly including:
Libubus.so:ubus provides external programming interfaces, such as creating sockets, listening and connecting, sending messages, and other interface functions. Libubox.so:ubus programming interfaces that are provided externally, such as waiting and reading messages. Libblobmsg.so,libjson.
so: Provides an interface for encapsulating and parsing JSON data, which requires no direct use of libjson.so, but rather a more flexible interface function provided by libblobmsg.so.
interprocess communication using Ubus does not require writing a large amount of code, simply invoking the API provided by Ubus in a fixed pattern. In the Ubus source code in the examples directory there are some examples to refer to. In my other article, a code example illustrates the three types of interprocess communication that Ubus provides by clicking on the Open link.
Second. The principle of the implementation of Ubus
The following illustrates the working principle of ubus with an example
In the figure below, Client2 tries to modify the IP address by Ubus, and the function that modifies the IP address is defined in CLIENT1.
The whole process of client2 the request is:
1. CLIENT1 registered two objects with the UBUSD: "Interface" and "Dotalk", where two methods were registered in the "Interface" object: "Getlanip" and "Setlanip", and the corresponding processing functions were FUNC1 ( ) and Func2 (). Two methods are registered in the "Dotalk" object: "Sayhi" and "Saybye", and the corresponding processing functions are func3 () and Func4 () respectively.
2. Then create a client2 to communicate with CLIENT1, noting that the two client cannot communicate directly with each other and need to be transferred by UBUSD (server).
3. Client2 is the SHELL/LUA/C client referred to earlier. Assuming that the shell client is used here, enter the following command at the terminal:
Ubus Call interface setlanip ' {IP ': ' 10.0.0.1 ', ' mask ': ' ubus ' calls command takes three parameters: the requested object name, the method name to invoke, and the parameter to pass to the method.
4. After the message is sent to the server, the server finds that the request should be forwarded to CLIENT1 based on the object name, and then the message is sent to Client1,client1 to invoke Func2 () to accept the parameter and process it, and if the process is completed, it needs to be returned to Client2. A reply message is sent.
The next step is to introduce the internal processing mechanism of the ubus, although using Ubus for interprocess communication does not need to focus on these implementation details, but it helps to deepen understanding of the Ubus implementation principle.
In the figure below, the Client1 registration object and method can actually be considered as a service provider, but a socket client for UBUSD. Client2 to invoke the Client1 registration method.
Third. Application scenarios and limitations of Ubus
Ubus can be used for communication between two processes and data interaction in a JSON-like format. The common scenarios for Ubus are:
Interaction in the form of "client-server", in which process a registers a range of services, and process B invokes those services. Ubus supports process communication in a "subscription-notification" manner, that is, process a provides a subscription service, and other processes can choose to subscribe or unsubscribe from the service, and process A can send messages to all subscribers.
Due to the limitations of Ubus implementations, Ubus is not appropriate in some scenarios:
1. Ubus is used for a small amount of data transmission, if the amount of data is large or data interaction is very frequent, it is not appropriate to use Ubus. After testing, when the Ubus a transmission of data more than 60KB, it will not work properly.
2. Ubus is not good for multithreading support, such as requesting the same service in multiple threads, and unpredictable results can occur.
3. Recursive invocation of Ubus is not recommended, for example, process a invokes the service of process B, and B's service requires the service of process C to be invoked, after which C returns the result to B, and B returns the result to a. If you have to do this, you need to avoid the problem of reusing global variables during the call process.
Fourth. Ubus Source code Brief analysis of the following introduction UBUSD and Ubus client work, here in order to facilitate understanding, only to introduce the approximate flow, to understand the detailed implementation of the reader to read their own source.
4.1 UBUSD Work Flow UBUSD's initialization works as follows:
1. Epoll_create (32) creates a poll_fd.
2. Create a UDP UNIX socket and add it to the POLL_FD listening queue.
3. Epoll_wait () wait for the message. The handler function after receiving the message is defined as follows:
static struct ULOOP_FD server_fd = {
. cb = SERVER_CB,
};
The SERVER_CB () function is invoked.
4. The work in the SERVER_CB () function is:
(1) to accept (), accept the client connection, and generate a client_fd for the connection.
(2) Assign a client ID to the client for UBUSD to distinguish between different client.
(3) Send a Hello message to the client as a sign of the connection.
(4) The CLIENT_FD is added to the POLL_FD listening queue to listen for messages sent by the client, and the message handler function is CLIENT_CB ().
That is, UBUSD listens for two kinds of messages, one is the new client's connection request, the other is the existing data sent by each client.
when UBUSD receives a client's data, the process of calling the CLIENT_CB () function is called:
1. Check to see if there is any data that needs to be replied to this client (possibly the last request was not processed), and if so, send the legacy data first.
2. Read the data on the socket and call the appropriate handler function based on the message type (the message type is specified in the data), and the message type and handler function are defined as follows:
static const UBUS_CMD_CB Handlers[__ubus_msg_last] = {
[ubus_msg_ping] = Ubusd_send_pong,
[ubus_msg_add_ OBJECT] = Ubusd_handle_add_object,
[ubus_msg_remove_object] = Ubusd_handle_remove_object,
[ubus_msg_lookup ] = Ubusd_handle_lookup,
[Ubus_msg_invoke] = Ubusd_handle_invoke,
[ubus_msg_status] = Ubusd_handle_response,
[Ubus_msg_data] = Ubusd_handle_response,
[Ubus_msg_subscribe] = Ubusd_handle_add_watch,
[ubus_msg_unsubscribe] = Ubusd_handle_remove_watch,
[UBUS_ Msg_notify] = ubusd_handle_notify,
};
For example, if you receive an invoke message, the Ubusd_handle_invoke () function is invoked.
These processing functions may be that UBUSD needs to be sent back to the client data after processing, or forwards the message to another client (if the requesting client communicates with another client).
3. After processing completes, sends the processing result to the client, for example UBUS_STATUS_OK. (Note that the client sends the data to the Ubus_msg_data type)
Workflow of 4.2 client
Ubus Call obj method Workflow:
1. Create a UNIX socket (UDP) connection UBUSD and receive the Hello message from the server.
2. The Ubus call command is processed by the Ubus_cli_call () function, which sends the lookup message to the UBUSD to request the ID of obj. The invoke message is then sent to UBUSD to invoke the methods method of obj.
3. Create the EPOLL_FD and add the client's FD to the listening list to wait for the message.
4. When the client receives the message, the handler function is Ubus_handle_data (), where the Ubus_msg_data type's data Receive_call_result_data () function assists in parsing.
The workflow of the called Client:
The process is similar to that of the Ubus client, and only becomes the acceptance request and invokes the handler function.
