Introduction and Application of APIS-basic concepts (Views on c api-level use)

Indicate the source for reprinting. Author: Tang Feng

The previous article describes the C Programming Interface of idea. Now I want to explain the basic concepts of sequence. The sequence is reversed, but it is consistent with my understanding. After seeing the programming interface of C, at least some perceptual knowledge will be given to it.

Worker is used for inter-process communication. The following figure shows most of the features of a sequence, but it is too complicated:

The scheme itself is built on the socket mechanism. The real communication is done by socket. Token is based on the above. It develops some communication protocols and provides interfaces at a higher level to facilitate data interaction between applications.

In the zookeeper system, there is a resident process daemon, which distributes and manages interactions between all processes. All processes that want to use the token for communication must first connect to daemon and register their names to daemon, daemon sends messages and data to the corresponding process as needed.

Use

1. Conn = dbus_bus_get (dbus_bus_session, & ERR );

Connect the application to the consumer. Then, use the Function

1. Ret = dbus_bus_request_name (Conn, "test. method. Server ",
2. Dbus_name_flag_replace_existing
3. , & ERR );

Register your process name on the daemon. (Refer to [Common Code] in the previous article). In this way, communication has a foundation.

Signal is the simplest communication method provided by signal. An application can send a signal to the daemon, daemon sends the corresponding data to each desired process based on the signal type and who wants the signal. That is, signal has the broadcast function. A signal has two basic attributes: one is a name used to identify different signals, the other is data, and the signal can carry certain data. The following figure shows the communication process of signal:

If a process (such as B) wants to receive an interface named test. signal. type signal, then you can use the following function to add a matching signal to daemon, so that daemon knows that you are interested in this signal.

1. // Add a rule for which messages we want to see
2. Dbus_bus_add_match (Conn,
3. "Type = 'signal ', interface = 'test. Signal. type '",
4. & ERR); // see signals from the given interface

Then, process B can use the following function to wait:

1. Dbus_connection_read_write (Conn, 0 );
2. MSG = dbus_connection_pop_message (conn );

Once a message is sent, process B can obtain the corresponding data through MSG. (Refer to the previous code segment [receive messages 1 and 2])

Now there is a process,

1. Dbus_uint32_t serial = 0; // unique number to associate replies with requests
2. Dbusmessage * MSG;
3.  
4. // Create a signal and check for errors
5. MSG = dbus_message_new_signal ("/test/signal/object", // Object Name of the signal
6. "Test. Signal. Type", // Interface Name of the signal
7. "Test"); // name of the signal
8.  
9. // Append arguments onto signal
10. Dbus_message_iter_init_append (MSG, & ARGs );
11. If (! Dbus_message_iter_append_basic (& ARGs, dbus_type_string, & sigvalue )){
12. Fprintf (stderr, "out of memory! \ N ");
13. Exit (1 );
14. }
15.  
16. // Send the message and flush the connection
17. If (! Dbus_connection_send (Conn, MSG, & serial )){
18. Fprintf (stderr, "out of memory! \ N ");
19. Exit (1 );
20. }

So far, several basic and core concepts have been involved. After figuring out these concepts, we almost know how to use the idea.

Dbusmessage is the core data structure in the queue. It can be understood that when the message data is transmitted in the queue, it is passed through it. For users, dbusmessage stores two kinds of important information: one is the name of the communication mechanism, and the other is the data of communication.

Various names)

In many of the interfaces used earlier, there are also name/path strings as parameters.

CommonName:The most important name in the topology is "Bus name", which is used by each application (or communication object) to identify your own use. It can be understood as an "ip" address. There are two types of bus names: one is "unique connection name", which starts with a colon and is globally unique but "unfriendly, one is "well-know name", which is friendly to humans. The naming rules for bus name are as follows:

1. Like a website address, the bus name consists of multiple sub-strings separated by ".". Each sub-string must contain at least one character.
2. Each substring can only consist of ASCII characters "[A-Z] [A-Z] [0-9] _-", and only a substring of the unique name can start with a number.
3. Each bus name must have at least one "." And two substrings. It cannot start ".".
4. Bus name cannot exceed 255 characters

Examples: Unique name: 392-2.33 org. freedesktop. Examples, etc.

The consumer name is used to identify the application, so every time the program is connected to the consumer daemon, it will be assigned to a unique name, at the same time, the application can also require that it allocate another well-know name (through the dbus_bus_request_name function ).

Interface Name:The role also has the interface concept, which is mainly used to set the framework usage at a higher layer. On the c api layer, you can almost ignore this concept. You only need to know this "string" and use it in message matching, as the message is transmitted before different processes, when a message or data is sent from process a to process B, a part of the message must contain this string, you can use process B (or ignore it. Its naming rules are almost the same as the naming rules. Note that the interface name cannot contain the "-" character.

Object Path:Similar to interfaces, Object Path in objective is only useful in the QT framework of a higher level. In the c api layer, this concept can be almost ignored, it is treated as a common string and is used for identification and differentiation based on communication needs. The naming rules for Object Path are:/COM/example/musicplayer1

1. The object path can be of any length.
2. It consists of several substrings starting with '/' and separated '/'.
3. Each substring must contain characters in [A-Z] [A-Z] [0-9] _
4. There cannot be an empty substring (that is, two consecutive '/' characters)
5. Except for "root path" ('/'), the object path cannot end.

Example of an object path:/COM/example/musicplayer1

Member Name:Member contains two types: Signal and method. In most aspects, they are almost the same, except for two points: 1. Signal is broadcast in the bus, and method is designated to be sent to a process. 2. signal will not return, but method will certainly return (synchronous or asynchronous ). The naming rules for member name are as follows:

1. It can only contain "[A-Z] [A-Z] [0-9] _" and cannot start with a number. It cannot contain ".".
2. Cannot exceed 255 characters

At the level of c api, member name shares the message type information between two processes ". The producer can only use signal/method for message communication. Both methods allow append various types of data in the message before the message is sent. When the communication recipient receives the message, it can know how to parse various data through the signal/method name.

So far, we have introduced three most important names. If we compare them with those familiar with Windows message mechanisms, we probably think that worker name is the process ID, with this, you can send messages to the specified process. The concepts of Object Path and interface make sense in the "(QT, etc.) high-level framework, you can ignore this concept and use it as the information for message screening. Member name is equivalent to message type. With this, you know how to parse the sent data.

Next, we will record another major component of dbusmessage: communication data.