Interprocess communication (IPC) in Linux

As an embedded software developer, it is common to deal with communication between processes. From the point of view of communication purpose, we can divide communication between processes into three types:

  1. In order to process scheduling: can be achieved through signals;
  2. To share resources: mutex, semaphore, read/write lock, file lock, etc.
  3. To pass data: shared memory, named pipes, message queues, sockets.

About the above mentioned, the operating system for us to provide communication primitives, the network of all kinds of information, articles flying, here is not wordy. How do you choose among these methods? According to my personal experience, expensive fine not expensive much, carefully choose three or four things can fully meet the needs of daily work.

The problem we want to discuss today is mainly the third: transfer data, in the above several methods to transfer data, I like the most, the most commonly used is Socket communication.

Some partners may say: Socket communication is TCP/IP that set of things, but also need to manage their own connection, the data group packet, subcontract, is also very troublesome.

Yes, Socket communication itself does require manual handling of the underlying stuff, but we can put a layer on the Socket: using the MQTT message bus to communicate data between processes on the system, as we’ll see below.

Second, the advantages of Socket based communication

Here I will not play by myself, directly quote the views of Teacher Chen Shuo’s book “Linux Multi-threaded Server Programming” (page 65, section 3.4) :

1. Scalability across hosts

Anyway, it’s multi-process, so if one machine doesn’t have enough processing power, it can be handled by multiple hosts. By spreading the process across multiple machines on the same LAN, the program can continue to use the Host:Port configuration. In contrast, none of the processes listed at the beginning of this article can communicate across machines, which limits scalability.

2. The OPERATING system automatically reclaims resources

The TCP port is exclusively used by a process. When a program exits unexpectedly, the operating system automatically reclaims resources without leaving garbage to the system. After the program restarts, it can be easily recovered.

3. Recordable and reproducible

Two processes communicate over TCP. If one crashes, the operating system shuts down the connection, and the other process senses it almost immediately, allowing for a quick failover. Of course the heartbeat of the application layer is essential. (Note: The operating system itself has a keepalive time for TCP connections, which is 2 hours by default and is global.)

4. Across languages

The server and client do not have to use the same programming language.

  1. What Chen shuo describes is universal Socket communication, so the client and server are usually located on different physical machines.
  2. In embedded development, it is common to use the same programming language, so cross-language is a bit negligible.

MQTT message bus

1. MQTT is a communication mechanism

Those who are familiar with the Internet of Things must be very familiar with MQTT message bus. At present, several major Internet of Things cloud platforms (Amazon, Ali Cloud, Huawei Cloud) all provide the access mode of MQTT protocol.

At present, the study MQTT best document is IBM’s online manual: developer.ibm.com/zh/technolo…

Here, I’ll go straight to the highlights:

  1. MQTT protocol is lightweight, simple, open and easy to implement;
  2. MQTT is a message protocol based on Publish/Subscribe paradigm.
  3. MQTT works on TCP/IP protocol family.
  4. There are three qualities of messaging service;
  5. Small transfer, low overhead (fixed length header is 2 bytes), minimal protocol switching to reduce network traffic;

MQTT message transmission requires a piece of middleware called the Broker, which is essentially a Server. The communication model is as follows:

  1. The MQTT Broker needs to be started first;
  2. ClientA and ClientB need to connect to the Broker;
  3. ClientA subscribes to topIC_1, ClientB subscribes to topIC_2;
  4. ClientA sends a message to the topic topic_2, which is received by ClientB;
  5. ClientB sends a message to the topic topIC_1, which is received by ClientA;

One of the great benefits of topic-based communication is decoupling: a client can subscribe to multiple topics, and any other client connected to the bus can send messages to these topics (it is also possible for a client to send messages to itself).

2. Implementation of MQTT

MQTT is just one protocol, and as you can see from IBM’s online documentation, there are many languages that implement the MQTT protocol, including C/C++, Java, Python, C#, JavaScript, Go, Objective-C, and many more. For embedded development, these implementations are commonly used:

Mosquitto; Paho MQTT; wolfMQTT; MQTTRoute.

Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto: Mosquitto:

3. Design our own communication protocol based on MQTT

As you can see from the above description, the MQTT message bus is nothing more than a communication mechanism that provides a channel for communication principals to pass data.

On this channel, we can send data in any format, encoded according to the needs of the actual project. In the project, we most commonly use plain text in JSON format, which is also recommended by various Internet of Things cloud platforms. If you need to include binary data in your text data, transfer it to BASE64 encoding before sending it.

How to use MQTT message bus in embedded system

As you can see from the above description, each client connected to the bus can flexibly send and receive data to each other as long as there is an MQTT Broker service running on the server side.

We can apply this mechanism to the design of embedded applications: an MQTT Broker runs locally on an embedded system as an independent service, and other processes that need to interact can send data to each other by connecting to the Broker locally. The operating model is as follows:

Each process only needs to subscribe to a fixed topic (e.g., its own client Id), and other processes can send data directly to this topic if they want to.

1. A communication framework for embedded systems

I have developed an environmental monitoring system before, which collects pollutant parameters such as PM2.5 and PM10 in the atmosphere and is developed on the Contex A8 platform. It needs to realize data recording (database) and UI monitoring interface.

The pollutant data sampling hardware module is provided by a third-party company. We only need to control the sampling equipment and receive the sampling data through the serial port protocol provided by the module. The final communication model is as follows:

  1. UI process sends control instructions to the sampling control process through the message bus, and the sampling control process sends control instructions to the sampling module through the serial port after receiving them.
  2. After receiving PM2.5 data from the serial port module, the sampling control process sends all data to the topic specified on the message bus.
  3. The UI process subscribes to the Topic, receives the data, and displays it on the screen.
  4. The database process also subscribes to the Topic, receives the data, and stores it in the SQLite database.

In this product, the core process is the sampling control process, which is responsible for interacting with the sampling module. The complexity of the system is reduced by designing UI processing and database processing as separate processes. Even if the two processes crash, the core sampling control process will not be affected.

For example, if the UI process crashes due to errors, it will restart immediately. After the startup, it knows that sampling is being performed through the cache information, so the UI process immediately connects to the message bus, enters the sampling data display interface, and continues to receive and display PM2.5 and other data sent by the sampling control process.

This communication model has another advantage: extensibility.

In the later stage of project development, Party A said that it needed to integrate a third party gas module to collect NO, SO2 and other parameters in the atmosphere, and the communication mode was RS485.

It is now extremely easy to extend this function module by writing a separate gas parameter process that plugs into the message bus. When this process receives NO, SO2 and other gas parameters from the third party gas module through RS485, it is directly thrown to a topic on the message bus. UI process and database process subscribe to this topic, and they can immediately receive gas-related data.

In addition, this design model has several other advantages:

  1. Parallel development: Each process can be developed in parallel by different people, as long as the communication protocol between them is defined.
  2. Easy to debug: Since the data sent is manual readable, during the development phase, a monitor can be written on the PC and connected to the MQTT Broker in the embedded system, so that it can receive messages from all processes.
  3. Communication security: After product release, to prevent others from eavesdropping on the data (such as the debugger in 2), you can specify a configuration file for the MQTT Broker that only allows local processes (127.0.0.1) to connect to the message bus.

2. A slightly more complex communication model

In the embedded framework design just described, every process is run locally and all messages are sent and received within the system. So what if you need to transfer data to the cloud, or receive control commands from the cloud?

Add an MQTT Bridge module! That is, to add another process that connects to both the cloud MQTT Broker and the local MQTT Broker, the communication model is as follows:

  1. When the MQTT Bridge receives an order from the cloud, it forwards it to the local message bus.
  2. When the MQTT Bridge receives the local message, it forwards it to the message bus in the cloud.

Mosquitos: A simple test code

Mosquitto This article focuses on Mosquitto design ideas, but when it comes to code, I’ve generally been using Mosquitto to implement the open source project.

It is very easy to install and test on a Linux system. Here is a brief explanation.

1. Install and test directly through APT

Refer to the documentation (www.vultr.com/docs/how-to…

(1) the installation

sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update
sudo apt-get install mosquitto
sudo apt-get install mosquitto-clients
Copy the code

(2) test

Mosquitbroker will start automatically after installation, and you can check with Netstat to see if port 1883 is working.

Receiver: After connecting to the broker, subscribe to the topic “test”.

mosquitto_sub -t "test"
Copy the code

Sender: After connecting to the broker, send the string “hello” to the topic “test”.

mosquitto_pub -m "hello" -t "test"
Copy the code

Mosquitto_pub when the sender executes mosquitto_pub, the string “Hello” will be received in the mosquitto_pub terminal window at the receiving end.

2. Manually compile and test the source code

Setting up with APT is mainly for simple learning and testing, but if Mosquitto is to be used in project development, you’ll have to compile it manually, get the header and library files, and copy them into your application for use.

Mosquitos: (1) Manually build, install mosquitos

My development environment is:

  1. Compiler: GCC (Ubuntu 5.4.0-6Ubuntu1-16.04.12) 5.4.0 20160609
  2. Mosquito-1.4.9 Mosquito-version

Mosquito-1.4.9 can be downloaded from the mosquito-1.4.9 website, or mosquito-1.4.9 can be downloaded from the mosquito-1.4.9 web disk at the end of this article, or you can try out the mosquito-1.4.9 version.

Compile and install instructions:

make
make install prefix=$PWD/install
Copy the code

After a successful installation, you can see the output file under the install folder in the current directory:

  1. Bin: MQTT client program;
  2. Include: a header file that your application needs to include;
  3. Lib: library file to which the application needs to link;
  4. Sbin: MQTT Broker service program.

H, uuid. H, etc., cannot be found during compilation. You only need to install the responsive development package through apt command.

(2) Simplest mosquito-client code

Mosquitto provides a wealth of Sample samples in the Mosquitto source code. If you don’t want to explore, you can download the Demo program from the web disk at the end of this article, which is connected to the message bus and subscribes to the topic “topic_01”. Of course, you could also modify the code to send the message (call mosquitto_publish).

After entering the c_mqtt sample code directory, you can see that the bin, include, and lib directories are already included, copied from the install directory in (1) above.

After executing the make command, you compile successfully and get the executable: mqTT_client.

The test process is as follows:

Step1: start the MQTT Broker

In the first terminal window, start the sbin/mosquitto Broker program. If you have started a broker in the above test, you need to kill the previous broker first because they all use port 1883 by default and cannot coexist.

Step2: start the receiving program mqtt_client

In the second terminal window, launch mqTT_client, the executable compiled by our sample code, which subscribles to topic “topic_01.”

. / mqtt_client 127.0.0.1 1883Copy the code

Parameter 1: the IP address of the Broker service, which is 127.0.0.1 because it is on the local system; Parameter 2: port number. The default value is 1883.

Step3: Start the sender program bin/mosquitto_pub

In the third terminal window, start bin/mosquitto_pub with the following command:

/mosquitto_pub -h 127.0.0.1 -p 1883 -m "hello123" -t "topic_01"Copy the code

The -h parameter is the IP address of the Broker service, which is 127.0.0.1 because it is on the local system. Parameter -p: port number 1883; Parameter -m: indicates the content of the sent message. Parameter -t: topic to be sent.

At this point, the received message can be printed out in the second terminal window (MQTT_client).

Six, summarized

This article focuses on mosquitos, a design pattern for embedded systems that uses a message bus to communicate between processes, and introduces mosquitos, an open source implementation.

In real projects, more stringent permissions are required, such as providing user names, passwords, device certificates when accessing the message bus, client names having to conform to a specified format, subscribing to a topic having to conform to a certain format, and so on.

In the next article, we’ll continue this discussion with a more concrete and useful Demo routine.

7. Download resources

1. Mosquitto – 1.4.9. TGZ

Link: pan.baidu.com/s/1izQ3dAlG… Password: dozt

Mosquitosample code 2

Link: pan.baidu.com/s/1M-dU3xap… Password: aup3


The summary article concluded by Doug is written with great care, which is very helpful for my technical improvement. Good things, to share!


Author: Doggo (public id: IOT Town) Zhihu: Doggo B station: Doggo share Nuggets: Doggo share CSDN: Doggo share






C language pointer – from the underlying principles to tricks, with graphics and code to help you explain thorough step by step analysis – how to use C to achieve object-oriented programming to improve the code forced lattice sharp weapon: Macro definition – from the beginning to abandon the original GDB low-level debugging principle so simple use of C language setjMP and LongjMP, to achieve exception capture and coroutine about encryption, certificates of those things in-depth LUA scripting language, let you thoroughly understand the principle of debugging