JP7580284B2 - Inter-process communication device, inter-process communication method, and inter-process communication program - Google Patents

Description

This invention relates to an inter-process communication device, an inter-process communication method, and an inter-process communication program for communicating between processes.

In recent years, a communication technology called Pub-Sub communication (publish-subscribe type communication) is used in inter-process communication, as shown in FIG. 4. This Pub-Sub communication is a communication in which a sending process (publisher) 101b sends a message without specifying a specific receiving process (subscriber) 101a. In other words, Pub-Sub communication is a technology that enables the configuration of a dynamic network (many-to-many communication) in which the receiving process 101a and the sending process 101b are not directly connected (the communication partner is not directly specified) by linking the receiving process 101a and the sending process 101b via an intermediary called a topic 102. FIG. 4 shows a case in which communication is performed between three receiving processes 101a-1 to 101a-3 and two sending processes 101b-1 and 101b-2. The topic 102 can be a class of messages to be sent and received, for example, a character string called a topic name.

Known methods for implementing this pub-sub communication include a method that uses an intermediary program (communication control process) called a broker (see, for example, Patent Document 1), and a method that does not use a broker, called a distributed type (see, for example, Patent Document 2).

First, a method of using a broker will be described with reference to FIG.
The broker 103 is a program that operates independently of the programs that perform communication, and the communication utilizing process 101 (the receiving process 101 a and the sending process 101 b ) transmits and receives data via the broker 103 .
Specifically, first, the receiving process 101a registers the topic 102 to be received with the broker 103. Then, the sending process 101b sends data specifying the topic 102 to the broker 103. Then, when the broker 103 receives the data, it transfers the data to all receiving processes 101a that request subscription to the topic 102 according to the topic 102 to which the data belongs, thereby realizing pub-sub communication. In other words, the broker 103 performs pub-sub communication by relaying the data.

Next, the distributed type will be described with reference to FIG.
In this distributed system, all communication utilization processes 101 periodically notify each other of information related to the topics 102 that they send and receive, and update the information, thereby realizing the sending and receiving of messages required for each topic 102.
Specifically, first, communication using processes 101 exchange information about the topic 102 that they periodically send and receive using background communication called discovery communication or the like. Then, when the sending process 101b sends data, it sends the same data, collected in the background communication, to all receiving processes 101a that want to receive the topic 102 to be sent, thereby realizing pub-sub communication. The thick arrow in Figure 6 indicates background communication by the receiving process 101a-1.

JP 2020-017118 A JP 2015-043208 A

However, when using a broker, if the broker stops due to an abnormality, all communication will be impossible. Also, if there are a large number of sending and receiving processes, the load on the broker program will increase, and this may cause a bottleneck in communications.

In addition, in a distributed system, pub-sub communication is a dynamic network, so information needs to be exchanged frequently in case the programs that send and receive topics are started and stopped, and as the number of sending and receiving processes increases, a large amount of background communication occurs. Since this background communication is communication other than messages, there is a possibility that it may interfere with (put on hold) the communication of data that is actually to be sent and received.

This invention was made to solve the above problems, and aims to provide an inter-process communication device that can reduce background communication compared to conventional devices and does not require data relaying.

The inter-process communication device according to the present invention is characterized by comprising a receiving process that generates a destination file indicating its own destination in a topic directory corresponding to a topic to be received from among topic directories provided for each topic in a communication directory, and a sending process that identifies a destination from the destination file generated in the topic directory corresponding to a topic to be sent from among the topic directories, and sends data to the destination.

With the above-mentioned configuration, this invention makes it possible to reduce background communication compared to the conventional method and eliminates the need for data relaying.

1 is a diagram illustrating a configuration example and an operation example of an inter-process communication device according to a first embodiment; 11A and 11B are diagrams illustrating a configuration example and an operation example of an inter-process communication device according to a second embodiment. 13A and 13B are diagrams illustrating a configuration example and an operation example of an inter-process communication device according to a third embodiment. FIG. 1 is a diagram illustrating conventional pub-sub communication. FIG. 1 is a diagram illustrating a conventional pub-sub communication using a broker. FIG. 1 is a diagram illustrating conventional distributed pub-sub communication.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.
Embodiment 1.
FIG. 1 is a diagram showing an example of the configuration and operation of an inter-process communication device according to the first embodiment.
The inter-process communication device according to the first embodiment includes one or more receiving processes (receiving programs) 1a and one or more sending processes (sending programs) 1b, as shown in Fig. 1. Three receiving processes 1a-1 to 1a-3 and three sending processes 1b-1 to 1b-3 are shown in Fig. 1. In the following description, the receiving process 1a and the sending process 1b may be collectively referred to as the communication using process 1.

The inter-process communication device is a computer realized by a CPU (Central Processing Unit) that executes programs stored in a memory, etc.

The inter-process communication device provides a communication directory (communication working directory) 11. The communication directory 11 is a directory or folder used for communication.

In addition, a topic directory 12 is prepared for each topic within the communication directory 11. The topic directory 12 is a directory with names that distinguish topics, such as the topic names used.

In FIG. 1, two topic directories 12-1 and 12-2 are provided in the communication directory 11. Note that topic directory 12-1 is a topic directory corresponding to a first topic. Also, topic directory 12-2 is a topic directory corresponding to a second topic.

Note that topics may be given a prefix called a namespace, for example, and may be classified in a hierarchical manner. In such cases, it is possible to deal with this by creating a hierarchical directory structure.

The topic directory 12 may be configured so that the communication using process 1 (the receiving process 1a or the sending process 1b) generates the topic directory 12 as necessary.
The location where the topic directory 12 is generated needs only to be the same for the receiving process 1a and the sending process 1b. Therefore, for example, an existing directory that is automatically created by the operating system (Windows (registered trademark), Linux (registered trademark), etc.) may be specified in the program.

When the receiving process 1a starts its own program, it creates a destination file 13 in a specified format in the topic directory 12 that corresponds to the topic to be received, among the topic directories 12 provided in the communication directory 11. The destination file 13 is a file that indicates its own destination (communication path).

When the receiving process 1a uses socket communication for the destination, it may describe the IP address and port number in the destination file 13, or the name of the destination file 13 itself may represent the IP address and port number. Also, when the receiving process 1a uses named pipe communication or UNIX domain socket communication in a UNIX (registered trademark) system, it may directly generate the destination file 13 that serves as the communication path. In other words, the receiving process 1a may generate the destination file 13 in a form that suits the communication format to be used.

Note that multiple receiving processes 1a may receive from one topic. Therefore, the inter-process communication device must make an arrangement to prevent duplication of the names of the destination files 13.

Figure 1 shows a case where receiving processes 1a-1 and 1a-2 receive from a first topic, and receiving process 1a-3 receives from a second topic. That is, in Figure 1, a destination file 13-1 indicating the destination of receiving process 1a-1 and a destination file 13-2 indicating the destination of receiving process 1a-2 are created in topic directory 12-1. Also in Figure 1, a destination file 13-3 indicating the destination of receiving process 1a-3 is created in topic directory 12-2.

When the sending process 1b sends (distributes) a topic, it first identifies the destinations of all the receiving processes 1a from the destination file 13 (list) created in the topic directory 12 corresponding to the topic to be sent, among the topic directories 12 provided in the communication directory 11. Then, the sending process 1b sends a message (data) to all the identified destinations.

FIG. 1 shows a case where the sending process 1b-1 and the sending process 1b-2 are targets of transmission on a first topic, and the sending process 1b-3 is targets of transmission on a second topic.
In this case, the sending process 1b-1 identifies the destinations of the receiving processes 1a-1 and 1a-2 from the destination files 13-1 and 13-2 in the topic directory 12-1 corresponding to the first topic. The sending process 1b-1 then transmits a message (data) to the identified destination. This allows the receiving processes 1a-1 and 1a-2 to receive the message from the sending process 1b-1.
Similarly, the sending process 1b-2 identifies the destinations of the receiving processes 1a-1 and 1a-2 from the destination files 13-1 and 13-2 in the topic directory 12-1 corresponding to the first topic. The sending process 1b-2 then transmits a message (data) to the identified destination. This allows the receiving processes 1a-1 and 1a-2 to receive the message from the sending process 1b-2.
The sending process 1b-3 also identifies the destination of the receiving process 1a-3 from the destination file 13-3 in the topic directory 12-2 corresponding to the second topic. The sending process 1b-3 then transmits a message (data) to the identified destination. This allows the receiving process 1a-3 to receive the message from the sending process 1b-3.

When the receiving process 1a's program stops, it deletes the destination file 13 created in the topic directory 12. This means that the sending process 1b will no longer consider the inactive receiving process 1a as a communication destination. Therefore, the inter-process communication device can retain the advantage of pub-sub communication, that is, the ability to configure a dynamic network without specifying a communication partner.

According to the above, the inter-process communication device according to the first embodiment uses a destination file system to enable a sending process 1b to specify the destination of a receiving process 1a that wants to receive a topic. As a result, the inter-process communication device does not require background communication for communication between communication using processes 1 to communicate topics that they need.
Furthermore, in the inter-process communication device according to the first embodiment, the sending process 1b can identify the destination of the receiving process 1a to which the transmission data is sent, and communication is performed directly between the sending process 1b and the receiving process 1a. Therefore, in this inter-process communication device, pub-sub communication is possible without the need for an intermediary program such as a broker. In other words, in this inter-process communication device, communication failure due to the stop of the broker does not occur.

As described above, according to this embodiment 1, the inter-process communication device includes a receiving process 1a that generates a destination file 13 indicating its own destination in a topic directory 12 corresponding to a topic to be received among topic directories 12 provided for each topic in a communication directory 11, and a sending process 1b that identifies a destination from the destination file 13 generated in a topic directory 12 corresponding to a topic to be sent among topic directories 12, and sends data to the destination. As a result, the inter-process communication device according to embodiment 1 can reduce background communication compared to conventional devices and does not require data relaying.

That is, the inter-process communication device according to the first embodiment can realize a pub-sub communication system that does not require frequent background communication and does not require data relay. Also, this inter-process communication device can realize a pub-sub communication system that has a small CPU load even if the number of communication-using processes 1 increases and is capable of operation independent of specific program operations.
Furthermore, the inter-process communication device according to the first embodiment is applicable not only to pub-sub communication but also to communication systems that configure dynamic networks that do not specify a transmission partner, and the same effects as those described above can be obtained.

Embodiment 2.
Fig. 2 is a diagram showing an example of the configuration and operation of an inter-process communication device according to embodiment 2. The inter-process communication device according to embodiment 2 shown in Fig. 2 has a communication management process 2 added to the inter-process communication device according to embodiment 1 shown in Fig. 1. Other configurations of the inter-process communication device according to embodiment 2 shown in Fig. 2 are similar to those of the inter-process communication device according to embodiment 1 shown in Fig. 1, so the same reference numerals are used and only the different parts will be described. Note that the communication directory 11 is not shown in Fig. 2.

The communication management process 2 manages communication between processes. This communication management process 2 is started and runs as a program separate from the communication using process 1.

When this communication management process 2 is notified of a topic and a data structure corresponding to that topic from a communication using process 1, it determines whether that topic is already being used by another communication using process 1. If the communication management process 2 determines that the notified topic is already being used by another communication using process 1, it determines whether the data structure corresponding to the topic already being used by the other communication using process 1 matches the notified data structure. If the communication management process 2 determines that the data structures match, it notifies the communication using process 1, which is the source of the notification, of communication permission. On the other hand, if the communication management process 2 determines that the data structures do not match, it notifies the communication using process 1, which is the source of the notification, of communication refusal.

The notification method by the communication management process 2 may use communication, or may take the form of accessing a specific location such as shared memory or file sharing.

The communication directory 11 may be configured to be generated by the communication management process 2.

When the receiving process 1a in the second embodiment starts its own program, it notifies the communication management process 2 of the topic to be received and the data structure corresponding to that topic (topic usage notification).
The notification method by the receiving process 1a may use communication or may take the form of accessing a specific location such as a shared memory or a shared file.

When the receiving process 1a is notified of communication permission from the communication management process 2, the receiving process 1a generates a destination file 13 in a prescribed format in the topic directory 12 that corresponds to the topic to be received from among the topic directories 12.
On the other hand, the receiving process 1a does not perform communication if a communication refusal is notified from the communication management process 2. That is, in this case, the receiving process 1a does not generate a destination file 13 in the topic directory 12 that corresponds to the topic to be received among the topic directories 12.

Furthermore, when the sending process 1b in the second embodiment starts its own program, it notifies the communication management process 2 of the topic to be sent and the data structure corresponding to that topic (topic usage notification).
The method of notification by the sending process 1b may be communication, or may take the form of accessing a specific location such as a shared memory or a shared file.

Then, when the sending process 1b is notified of communication permission from the communication management process 2, when sending (distributing) a topic, it first identifies the destinations of all receiving processes 1a from (a list of) destination files 13 generated in the topic directory 12 corresponding to the topic to be sent among the topic directory 12. Then, the sending process 1b transmits a message (data) to all the identified destinations.
On the other hand, when the sending process 1b receives a communication refusal notice from the communication management process 2, it does not perform communication.

The example in Figure 2 shows a case in which, in response to a topic and data structure notified by a sending process 1b-1 to a communication management process 2 (notification shown by reference symbol 201a), a receiving process 1a-1 notifies the communication management process 2 of the same topic and data structure (notification shown by reference symbol 201a), and a receiving process 1a-2 notifies the communication management process 2 of a different topic and data structure (notification shown by reference symbol 201b).
In this case, the communications management process 2 notifies the sending process 1b-1 and the receiving process 1a-1 of communications permission (notification indicated by reference numeral 202a), and notifies the receiving process 1a-2 of communications refusal (notification indicated by reference numeral 202b).
As a result, the receiving process 1a-1 creates a destination file 13-1 in a prescribed format in the topic directory 12-1 and communicates with the sending process 1b-1. On the other hand, the receiving process 1a-2 does not communicate.

As described above, by using a program that manages communications (communication management process 2), the data structures of the topics used in the communications can be made consistent, and communication data with a data structure different from the data structure expected for each topic can be prevented from being sent or received. This prevents communication errors, eliminates unnecessary communications, and is expected to reduce communication volume and CPU load.

In the above, only data structures have been used for ease of understanding. However, the information notified from the communication using process 1 to the communication management process 2 is not limited to data structures, and may also include information necessary for managing pub-sub communication.

Furthermore, the notification from the communication management process 2 may include information necessary for communication management for the communication utilization process 1. For example, in a method using a destination file system, there is a possibility that the name of the destination file 13 may be duplicated, causing the destination file 13 to be overwritten and making communication impossible. However, this can be solved by using the communication management process 2.
That is, when a permission response is made upon receiving a topic usage notification from the receiving process 1a, the communication management process 2 notifies the receiving process 1a of a name that does not overlap with the name of a destination file 13 created by an existing receiving process 1a. The receiving process 1a then creates a destination file 13 with the name notified by the communication management process 2. On the other hand, when a refusal response is made, the communication management process 2 does not notify the name of the destination file 13, thereby preventing the receiving process 1a from creating a destination file 13, thereby preventing unauthorized communication.

Alternatively, the topic directory 12 may be generated by the communication management process 2, and the communication management process 2 may generate the topic directory name after performing some conversion, and notify the converted topic directory name as an authorization response when a topic usage notification is received. This may also prevent unauthorized communication from occurring.

Embodiment 3.
In the first and second embodiments, the destination file system is used to prepare the destination file 13 indicating the destination of the receiving process 1a.
On the other hand, if the receiving process 1a terminates abnormally while this destination file 13 is placed in the topic directory 12, the destination file 13 will not be deleted and will remain. In this case, when the sending process 1b sends data, it will also try to send data to the receiving process 1a that terminated abnormally. Therefore, a method to avoid this will be explained.

Figure 3 is a diagram showing an example of the configuration and operation of an inter-process communication device according to embodiment 3. The inter-process communication device according to embodiment 3 shown in Figure 3 adds a communication management process 2 to the inter-process communication device according to embodiment 1 shown in Figure 1. The other configurations of the inter-process communication device according to embodiment 3 shown in Figure 3 are similar to those of the inter-process communication device according to embodiment 1 shown in Figure 1, so the same reference numerals are used and only the different parts will be described. Note that the communication directory 11 is not shown in Figure 3.

The communication management process 2 manages communication between processes. The communication management process 2 runs as a separate program from the communication using process 1, and monitors the alive state of the communication using process 1.
That is, the communication management process 2 holds the process information notified from the communication using process 1, and periodically checks the operation state of the communication using process 1 using the functions of the operating system.

When the communication management process 2 determines that the communication using process 1 has terminated abnormally, if the communication using process 1 is a receiving process 1a, it deletes the destination file 13 that was used by the receiving process 1a. This enables the communication management process 2 to prevent the sending process 1b from recognizing the abnormally terminated receiving process 1a as a destination.

When the receiving process 1a in the third embodiment starts its own program, it notifies the communication management process 2 of its own process information (for example, a process ID in the case of a UNIX-based operating system) and also notifies the communication management process 2 of the destination file name of the destination file 13 to be used.
Thereafter, the receiving process 1a periodically notifies the communication management process 2 of its own process information.
Furthermore, when the receiving process 1a's program is normally stopped, it notifies the communication management process 2 of its own process information and the communication stop. At this time, the receiving process 1a also deletes the destination file 13 before terminating the program.

Furthermore, the transmitting process 1b in the third embodiment notifies the communication management process 2 of its own process information (eg, a process ID in the case of a UNIX-based operating system) when its own program is started.
Thereafter, the sending process 1b periodically notifies the communication management process 2 of its own process information.
Furthermore, when the transmitting process 1b's own program is stopped normally, the transmitting process 1b notifies the communication management process 2 of the process information and the communication stop.

In FIG. 3, the communication management process 2 monitors the alive status of the communication using processes 1-1 and 1-2 by receiving process information from the communication using processes 1-1 and 1-2. In this case, if the communication using process 1-2 terminates abnormally, the communication management process 2 deletes the destination file 13-2 indicating the destination of the receiving process 1a-2.

As described above, by doing this, it is possible to prevent unnecessary communication operations from occurring even if the receiving process 1a terminates abnormally. This is expected to reduce the amount of communication.

In addition, when the communication management process 2 is notified of the process information at the time of startup from the receiving process 1a, the communication management process 2 may notify the receiving process 1a of the destination file name generated by the receiving process 1a. In this case, the receiving process 1a does not need to notify the communication management process 2 of the destination file name.

In the above, the case where the above function is added to the inter-process communication device according to the first embodiment is shown. However, this is not limited to the above case, and the above function may be added to the inter-process communication device according to the second embodiment, and the same effect as above can be obtained.

In addition, within the scope of the present invention, it is possible to freely combine the various embodiments, modify any of the components of each embodiment, or omit any of the components of each embodiment.

1 Communication using process 1a Receiving process 1b Sending process 2 Communication management process 11 Communication directory 12 Topic directory 13 Destination file

Claims (6)

a receiving process that generates a destination file indicating its own destination in a topic directory corresponding to a topic to be received, among topic directories provided for each topic in a communication directory;
a sending process that identifies a destination from a destination file created in a topic directory corresponding to a topic to be sent among the topic directories, and sends data to the destination. 2. The inter-process communication device according to claim 1, further comprising a communication management process that detects an abnormal termination based on process information notified from the receiving process and the sending process, and if the process that detected the abnormal termination is the receiving process, deletes a destination file indicating the destination of the receiving process. a communication management process that, when a topic and a data structure corresponding to the topic are notified and it is determined that the data structure matches a data structure corresponding to the topic used in a process other than the process that is the notification source, notifies the notification source of communication permission;
The receiving process notifies the communication management process of a topic to be received and a data structure corresponding to the topic, and when communication permission is received from the communication management process, creates a destination file in a topic directory;
2. The inter-process communication device according to claim 1, wherein the sending process notifies the communication management process of the topic to be transmitted and the data structure corresponding to the topic, and when the communication management process notifies the sending process of permission to communicate, identifies a destination from a destination file generated in a topic directory and transmits data to the destination. 4. The inter-process communication device according to claim 3, wherein the communication management process detects an abnormal termination based on process information notified from the receiving process and the sending process, and if the process that detected the abnormal termination is the receiving process, deletes a destination file indicating the destination of the receiving process. A receiving process generates a destination file indicating its own destination in a topic directory corresponding to a topic to be received, among topic directories provided for each topic in a communication directory;
a sending process identifying a destination from a destination file created in a topic directory corresponding to the topic to be sent from among said topic directories, and sending data to the destination. A receiving process generates a destination file indicating its own destination in a topic directory corresponding to a topic to be received, among topic directories provided for each topic in a communication directory;
a sending process identifying a destination from a destination file created in a topic directory corresponding to the topic to be sent among the topic directories, and sending data to the destination.

Images