Binder Mechanism 1 --- binder principles

1. Binder communication mechanism Introduction

In this article, we will first compare the difference between the Binder Mechanism and the Linux communication mechanism, to understand why Android is getting better, and then refer to binder. Next, we will understand what service manager is and what role it plays in the C/S model based on the Binder Mechanism. Finally, we will understand the binder communication process from a complete communication activity.

1.1 comparison between Android and Linux communication mechanisms

Although Android inherits the Linux kernel, the communication mechanism between Linux and Android is different.

The IPC communication mechanism used in Linux is as follows:

1. Traditional IPC: Unknown pipe, signal, Trace, famous Pipeline
2. At&t UNIX System V: Shared Memory, signal lights, message queues
3. Bsd unix: Socket
   

In Android, these are not used. Instead, the binder mechanism is used. The binder mechanism evolved from the use of openbinder by the handler. The reasons for using it in Android are as follows:

1. Uses the C/S communication mode. In the Linux communication mechanism, only socket supports the C/S communication mode, but socket has its disadvantages. For details, refer to article 2.
2. It provides better transmission performance. Compared with the Linux communication mechanism,
   • Socket: a common interface, resulting in low transmission efficiency and high overhead;
   • MPs queue and Message Queue: because the producer uses the storage and forwarding method, at least two data copies are required, which is inefficient;
   • Shared Memory: although data is not copied during transmission, its control mechanism is complex (for example, cross-process communication requires obtaining the PID of the other process, and multiple mechanisms are required for collaborative operations ).
3. Higher security. Linux's IPC Mechanism has no security measures in its own implementation, so it must rely on upper-layer protocols for security control. The UID/PID of the binder mechanism is identified by the Binder Mechanism itself in the kernel space, which is highly secure. Moreover, the binder can establish private channels, this is not implemented by the communication mechanism of Linux (the Access Point of the Linux kernel is open ).
   

To sum up, the Binder Mechanism for Android users makes sense. Since the Binder Mechanism has so many advantages, let's take a look at how it is implemented through the C/S model.

1.2 roles of binder in Service

In Android, many services communicate through the binder. For example, mediaserver includes many services:

• Audioflinger core Audio Service
• Audiopolicyservice: an important service related to audio policies
• Mediaplayerservice: an important service in Multimedia Systems
• Cameraservice: an important service related to camera/photography

The binder process in C/S is as follows:

1. Server injection queue service. Server is the owner of many services. To provide services to the client, you must first add your own services to Service Manager (hereinafter referred to as Sm. The server can inject one or more services to the SM.
2. The client applies for the service. As a service user, a client must apply to SM for the services it needs to use. The client can apply for one or more services.
3. After the client successfully applies for the service, the client can use the service.
   

On the one hand, SM manages the services provided by the server, responds to client requests at the same time, and allocates corresponding services to them. The role assumed is equivalent to the old man of the month. The advantages of this communication method are: on the one hand, service and client requests are easy to manage, and on the other hand, when developing an application, you only need to establish a connection to the server for the client, it takes a lot of time and effort to implement the corresponding functions of the server. So what is the relationship between the binder and the communication mode ?! In fact, the communication mode of the three users is the Binder Mechanism (for example, the server injects the queue service to the SM and uses the binder communication; the client requests the request using the binder communication)
1.3 binder Communication Mechanism process (overall framework)

This is the communication model of the binder. We can find that:

1. The client and server exist in the user space.
2. The implementation of client-server communication is implemented by the binder driver in the kernel space
3. As a daemon, SM processes client requests and manages all service items.
   

To facilitate understanding, we can understand sm as dnsserver; then the binder driver is equivalent to the routing function. This involves how the client and server communicate. The three procedures mentioned in section 1.2 are described below.

1.3.1 The server injects services into SM

1. First, xxxserver (xxx stands for a specific) applies to the binder driver in its own process to create a binder entity for xxxservice,
2. The binder driver creates a binder entity node in the kernel for this xxxservice and a reference to the binder. Note that the binder entity is packaged and passed to SM (the entity is not passed to SM ), notify Sm to add a service named XXX.
3. After receiving the data packet, SM extracts the xxxservice name and reference and fills in a search table.
4. In this case, if a client sends a request to apply for the service xxxservice to SM, Sm can find the binder reference of the Service in the search table and return the binder reference (xxxbpbinder) to the client.

Before learning more about the binder communication mechanism, let's clarify several concepts.

1. References and entities. Here, for an object used for communication (object that can be understood as a real space), there can be multiple references to the object (there is no real space, and it can be understood as a link to the object, the object on the corresponding link is operated ). Assume that a process holds an entity and other processes want to operate the entity. The most efficient way is to obtain the reference of the entity and then operate the reference.
2. Some materials refer to objects as local objects and reference them as remote objects. It can be understood that a reference is sent from a local process to another process to operate the entity, so there is a local and remote object name.

1.3.2 one question-how to obtain the remote interface of Sm

If you are careful enough, you will find a problem:

SM and server are both processes. The server needs to communicate with other binder to SM. Currently, inter-process communication is implemented, but inter-process communication is used. This is like a chicken or an egg, but at least one of them must exist first.

Clever binder solution:

For the communication mechanism of the binder, the server has the entity of the binder; the client has the reference of the binder.
Assume that SM is regarded as the server, so that it has its own binder entity when the binder driver is executed (the handle value of servicemanager's binder is set to 0 in the Code ). This binder entity has no name and does not need to be noted. All clients think that the binder reference with the handle value 0 is used to communicate with Sm (this is implemented in the Code ), then the problem is solved. So, the client and server have reached this agreement (the reference with a handle value of 0 is used for communication with Sm, we also need to make SM an entity with a handle value of 0 to achieve success. How can this problem be achieved ?! When a process calls the binder driver and uses the binder_set_context_mgr command (in the binder_ioctl driver) to inject itself into SM, the binder driver automatically creates the binder entity for it. The reference value of this binder is 0 for all clients.

1.3.3 client obtains the remote interface of service from Sm

After the server injects the binder object and its name to SM, the client can obtain the reference of this binder (bpbinder) in the sm lookup table through the service name ). The client also uses a reserved reference with a handle value of 0 to request a service from the SM: I applied for a reference from the xxxservice. SM will get the xxxservice name from the request packet, find the corresponding entry with this name in the search table, and fetch the reference of the binder and package it back to the client. Then, the client can use the reference of xxxservice to use the service of xxxservice.
If many other clients request the service, many other clients in the system will obtain the reference.

1.3.4 after the C/S path is established

First, we need to clarify a concept: the client has its own binder entity, and the server's binder reference; the server has its own binder entity, and the client's binder reference. We can also understand the methods of the recipient and the sender:

• Send data from the client to the server: the client is the sender and has the entity of the binder; the server is the receiver and has reference of the binder.
• Send data from the server to the client: the server is the sender and has the entity of the binder; the client is the receiver and has reference of the binder.

That is to say, after establishing the C/S path, we don't need to consider who is the client and who is the server. We just need to clarify who is the sender and who is the receiver, then you can know the entity and reference of the binder.

The process after the CS path is established: (when the receiver obtains the binder entity, the sender obtains the reference of the binder)

1. The sender sends an object request through the binder.
2. The binder driver will process this operation request, put the data of the sender into the write cache (binder_write_read.write_buffer) (For the recipient, the read buffer), and read the read_size (the recipient reads the data) set it to the data size (detailed implementation will be introduced later );
3. The recipient has been in the blocking status. When there is data in the write cache, it will read the data and run the command
4. After the receiver finishes running, it will encapsulate the returned results with the binder_transaction_data struct and write them into the write buffer (for the sender, It is the read buffer)

1.3.5 anonymous Binder

Previously, I introduced the advantages of using the Binder Mechanism in Android, and mentioned that binder can establish point-to-point private channels. Anonymous binder is like this. In binder communication, not all binder entities used for communication must be noted to SM. The server can transmit the created binder entity to the client through the established entity binder connection. The binder does not add the queue name to SM. In this way, the communication between the server and the client is highly private and secure.

In this way, the entire binder communication process is described, but for detailed code implementation (for example, what is binder_transaction_data? What is binder_write_read.write_buffer? What is the detailed driver and logic implementation ?), The following sections describe them one by one.

Several questions:
1. Who is it and how to become the SM daemon. When will the binder entity with a handle of 0 be created?
2. How are binder references and entities created? How to implement communication in the driver?
3. In SM, how is the binder object converted into a reference?
4. How does the server note the ghost service and how does the client obtain the service?

After reading some articles, you will know the answer!