Method for implementing inter-process data interaction based on message queue and shared memory
By adopting inter-process data interaction methods based on message queues and shared memory in traditional monolithic applications, the problem that monolithic applications are difficult to meet new business needs is solved, efficient and flexible data interaction is achieved, system design is simplified and scalability is improved.
Patent Information
- Application Number
- CN202011458085.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-12-10
- Publication Date
- 2025-05-30
- Estimated Expiration
- 2040-12-10
AI Technical Summary
Traditional single applications integrate all business functions, making it difficult to meet new business needs, and modifying the original application will add a lot of work and are not very versatile.
The data interaction between processes is realized based on message queues and shared memory, and the message queues between the main process and the service process are connected, and the shared memory is used for data exchange, decoupling the communication between the main program and the terminal device.
It realizes the efficiency and flexibility of data interaction between processes, simplifies the design of the main process, shortens the time for customized programs, and improves the communication efficiency and scalability of the system.
Smart Images

Figure CN112559207B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data interaction, and specifically to a method for realizing inter-process data interaction based on message queue and shared memory methods. Background Art
[0002] With the rapid growth of business, there are more and more customized applications. However, the generality of such customized programs is not high. Once the business requirements change, under the existing program architecture, the workload of modification is very large. At this time, the traditional monolithic application program architecture is difficult to meet the new requirements. In order to change this situation, it is necessary to transform the existing application program framework. The principle of transformation is to split the original monolithic application program into different service processes according to factors such as business or function.
[0003] The traditional monolithic application program integrates all business functions, making it difficult to meet some new business requirements. Modifying the original application program will increase a large amount of work, and its generality is not high. Moreover, one modification can only meet the current requirements. If the requirements increase or change again, it will inevitably cause some unnecessary repetitive work, consuming a lot of manpower, material resources and financial resources. Summary of the Invention
[0004] (1) Technical Problems to be Solved
[0005] In view of the deficiencies of the prior art, the present invention provides a method for realizing inter-process data interaction based on message queue and shared memory methods, which solves the problems that the traditional monolithic application program integrates all business functions, making it difficult to meet some new business requirements, and modifying the original application program will increase a large amount of work and its generality is not high.
[0006] (2) Technical Solutions
[0007] To achieve the above object, the present invention is realized through the following technical solutions: A method for realizing inter-process data interaction based on message queue and shared memory methods, which realizes inter-process data interaction based on message queue and shared memory methods.
[0008] It includes the following steps:
[0009] (1) The main process starts and creates a message queue. The service process starts and establishes a connection with the main process through the message queue;
[0010] (2) The main process sends an initialization instruction, obtains the terminal list and the name of the shared memory, assembles the message format, and sends the message;
[0011] (3) The service process receives the message, parses the terminal list and the shared memory name in the message according to the definition of the function code in the message, establishes connections with the terminals in sequence according to the terminal list, and creates a shared memory block according to the name of the shared memory;
[0012] (4) The main process sends a start message. After the service process receives the message, it communicates with the terminals, writes the data collected by the terminals into the shared memory; the main process reads the terminal data from the shared memory;
[0013] (5) The main process sends a polling data type message. After the service process receives the message, according to whether the data type to be polled in the message is enabled, it selectively writes the terminal data into the specified area in the shared memory; the main process reads the terminal data from the specified area in the shared memory;
[0014] (6) The main process sends a non-polling data message to the message queue. After the service process receives the message, it processes the message and returns the processing result to the main process;
[0015] (7) The main process sends a stop message. After the service process receives the message, it disconnects all the terminal connections, destroys the shared memory, and restores the initial settings.
[0016] Beneficial effects
[0017] The present invention provides a method for realizing inter-process data interaction based on a message queue and a shared memory. It has the following beneficial effects:
[0018] This method for realizing inter-process data interaction is invented with the application scenario of inter-process data interaction during the automatic detection process of the network configuration terminal device. Of course, this idea can be applied to other application scenarios. The present invention decouples the function of communicating with the terminals from the main process, and separates it into a separate process, which is mainly responsible for the communication work with the terminal devices. The data collected by the terminals is written into the shared memory, and the main process interacts with the service process through the message queue, without having to care about the communication work with the network configuration terminal device, only caring about the interaction of the user interface and the business functions, which greatly simplifies the design of the main process, shortens the time of the customizable program, and at the same time has the following advantages compared with the existing technologies:
[0019] Decoupling: The main program is mainly responsible for the UI interaction and data display work, and the service process is responsible for the communication work with the terminal devices. The two interact through the shared memory;
[0020] Producer / Consumer mode: The service process communicates with the terminals, and the collected data is stored in the shared memory block, that is, producing data, so-called data producer; the main program reads the data from the shared memory, that is, consuming data, so-called data consumer;
[0021] Support for concurrency: The producer / consumer pattern is not adopted. The producer calls a certain method of the consumer. Since the function call is synchronous, the producer will keep waiting and unable to produce data before the consumer method returns. In this way, the producer depends on the processing speed of the consumer. After the main program and the service program adopt the producer / consumer pattern, the producer and the consumer are two independent processes. The producer only needs to throw the produced data into the buffer and then can produce the next data. Basically, it does not depend on the processing speed of the consumer;
[0022] High flexibility and scalability: The main program and the service program are based on the message queue. The message format can be in any format. As long as both parties agree on the format, it is very convenient to implement function expansion;
[0023] High communication efficiency: The non-data part between the main process and the service process is interacted through the message queue, and the data part is interacted through the shared memory. Without losing flexibility, the communication real-time performance and efficiency can be guaranteed. Brief Description of the Drawings
[0024] Figure 1 This is the block diagram of the working principle of the present invention;
[0025] Figure 2 This is the block diagram of the shared memory principle in the application scenario of the distribution network terminal device of the present invention. Detailed Embodiment
[0026] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.
[0027] Please refer to Figure 1-2 , the present invention provides a technical solution: a method for realizing data interaction between processes based on the message queue and the shared memory, and realizing data interaction between processes based on the message queue and the shared memory:
[0028] Specifically, it includes the following steps:
[0029] (1) The main process starts and creates a message queue. The service process starts and establishes a connection with the main process through the message queue;
[0030] (2) The main process sends an initialization instruction, obtains the terminal list and the name of the shared memory, assembles the message format, and sends the message;
[0031] (3) The service process receives the message, parses the terminal list and shared memory name in the message according to the definition of the function code in the message, establishes connections with the terminals in sequence according to the terminal list, and creates a shared memory block according to the name of the shared memory;
[0032] (4) The main process sends a start message. After the service process receives the message, it communicates with the terminals, writes the data collected by the terminals into the shared memory; the main process reads the terminal data from the shared memory;
[0033] (5) The main process sends a polling data type message. After the service process receives the message, it selectively writes the terminal data into the specified area in the shared memory according to whether the data type to be polled in the message is enabled; the main process reads the terminal data from the specified area in the shared memory;
[0034] (6) The main process sends a non-polling data message to the message queue. After the service process receives the message, it processes the message and returns the processing result to the main process;
[0035] (7) The main process sends a stop message. After the service process receives the message, it disconnects all terminal connections, destroys the shared memory, and restores the initial settings.
[0036] According to the application scenario of the present invention, the message queue selection is Nanomsg.
[0037] The message format definition in the present invention is as follows:
[0038] The message format in the message queue of the present invention is defined in the form of a structure. For the convenience of description, the variables in the structure are all described in the form of key-value pairs.
[0039] The first item of the structure is FunCode, which is used to describe the operation type (function code) of the message. The subsequent items are defined according to the FunCode function code. The basic form is as follows:
[0040] enum FunCode
[0041] {
[0042] Init = 0, / / Initialization
[0043] Start, / / Start
[0044] Stop, / / Stop
[0045] DataLoop, / / Data polling setting
[0046] Timing, / / Time synchronization
[0047] SoeList, / / SOE
[0048] CosList, / / COS
[0049] ReadSetting, / / Read set value / intrinsic parameter
[0050] ReadSetting, / / Write setting value
[0051] YK, / / Remote Control
[0052] };
[0053] typedef struct tag_msgInfo
[0054] {
[0055] int funCode;
[0056] / / Subsequent content needs to be determined according to the FunCode function code
[0057] }msgInfo;
[0058] The method of one question and one answer is adopted for both sending and receiving. If the message instruction does not clearly define the response format, a unified default format response is adopted. The structure is as follows:
[0059] typedef struct tag_defaultMsgResp
[0060] {
[0061] int funCode; / / requested funCode
[0062] int result; / / 0-failure / 1-success
[0063] }defaultMsgResp;
[0064] Shared memory is a form of inter-process communication. It achieves communication between processes by mapping a section of memory to the user process space (shared memory needs to use other synchronization mechanisms to achieve synchronization between shared memories). It is also the fastest form of inter-process communication because it maps the memory address of the process to the user process address space, so that the process can directly manipulate the data in the memory. The process does not involve the kernel, thus avoiding the IO copy process, which greatly improves the communication speed.
[0065] Attached Figure 2 The definition format of shared memory is described as follows:
[0066] Naming rule: Project Name.terminals.sm
[0067] The shared memory area is mainly divided into two major parts: the "system area" and the "device data" area. The device data area is arranged in the order of device 1, device 2... device n, as follows:
[0068] System area (1k)
[0069] Spare (used to describe the status of the service process)
[0070] Device data area (1 - n)
[0071] In the subsequent description, the data addresses are all relative to the starting address of this data area, in decimal. The specific meaning and address of each data are determined by the message interaction message;
[0072] Status area (1k)
[0073] Device status (0 - 3): 0 - Communication not connected; 1 - Communication connected;
[0074] YC data area (2k), capacity: 512
[0075] All YC data adopts the 4 - byte Float type.
[0076] YX data area (8k), capacity: 512
[0077] Each YX contains two groups of data, COS and SOE. All timestamps adopt the 7 - byte CPT56 format.
[0078] YX data structure: COS(1B)+PCTime(7B)+SOE(1B)+SOETime(7B)
[0079] DN data area (2k), capacity: 512
[0080] All DN data adopts the 4 - byte Float type.
[0081] The present invention combines two methods to achieve fast response for small data volumes and fast interaction for large data volumes, thereby improving the efficiency of data interaction between processes.
[0082] In step (1), the main process and the service process are connected through a message queue to prepare for subsequent message sending;
[0083] Step (ii): The main process sends an initialization instruction message, and the initialization instruction includes a list of terminal information and the name of the shared memory. After receiving the message in Step (iii), the service process parses the message, and there are two main tasks: one is to connect to the terminal device, and the other is to create the shared memory;
[0084] The detailed content of the initialization instruction message is shown in the following table:
[0085] Key Value Example Remark FunCode Init SMName Name of Shared Memory Dev1 Nested Structure Dev2 Nested Structure ... Nested Structure Devn Nested Structure
[0086] The nested structure of Dev1, Dev2…Devn is shown in the following table:
[0087]
[0088]
[0089] The definition of the nested structure of ProtocalPara is shown in the following table:
[0090] Key Value Example Remark ASDU Common Address 1 Length of ASDU Common Address 2 Length of Transmission Cause 2 Length of Information Object Address 3 Starting Address of Remote Signal 0x1 Starting Address of Telemetry 0x4001 Starting Address of Electric Energy 0x5401 Number of Remote Signals 128 Number of Telemetry 128 Number of Electric Energy 128 t0 t1 t2 t3
[0091] After the first 3 steps are completed, in Step (iv), the main process sends a start communication instruction message, and the start instruction message includes the object of operation (described in the following table). After receiving the message, the service process parses the message and writes the data collected by the terminal into the specified shared memory area. The format of the start / stop instruction message is shown in the following table:
[0092]
[0093] The definition of the message return structure is as follows:
[0094]
[0095] In Step (v), the main process sends a terminal data polling setting instruction message, and the instruction message includes: the object of operation, telemetry polling enable, telecontrol polling enable, power data polling enable, polling data period, etc. By setting this instruction message, the service process will communicate with the terminal according to the enabled data type and polling period, and write the terminal data into the specified area of the shared memory for the main process to read. The description of the data polling instruction message is shown in the following table:
[0096]
[0097]
[0098] In step (six), a non-data polling instruction message is sent. The non-polling instruction message includes time synchronization instructions, SOEList / COSList, read setting values / intrinsic parameters, write setting values, remote control, and other instruction messages. The non-polling instruction messages are described one by one as follows:
[0099] The time synchronization instruction message is described in the following table:
[0100]
[0101] The SOEList instruction message is described in the following table:
[0102]
[0103]
[0104] The return format of the SOEList instruction message is shown in the following table. In other cases, it is returned in the default format.
[0105]
[0106] The COSList instruction message is described in the following table:
[0107] Key Value Example Remark FunCode COSList Operation Object Device 1, Device 2... Device n Start / Stop Start / Stop / Read Dot 1,2,3 Support Multiple
[0108] The return format during read operation is shown in the following table. In other cases, it is returned in the default format.
[0109]
[0110] The read setting value / intrinsic parameter instruction message is described in the following table:
[0111] Key Value Example Remark FunCode Read Setting Value / Read Intrinsic Parameter Operation Object Device 1, Device 2... Device n Dot 1,2,10,20,25,30,50
[0112] The return format of the read setting value / intrinsic parameter instruction message is shown in the following table. In other cases, it is returned in the default format.
[0113]
[0114] The write setting value instruction message is described in the following table:
[0115]
[0116] The return format of the write operation is shown in the following table. In other cases, it is returned in the default format.
[0117]
[0118]
[0119] The format of the remote control instruction message is described in the following table:
[0120]
[0121] The return format of remote control operation is shown in the following table:
[0122]
[0123]
[0124] Step (VII): Send a stop instruction message. Referring to Step (II), set FunCode to Stop. After the service process receives the message, it will automatically disconnect from all terminals and destroy the shared memory
[0125] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.
[0126] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A method for realizing data interaction between processes based on message queue and shared memory, Characterized in that: Realize data interaction between processes based on message queue and shared memory; including the following steps: (1) The main process starts and creates a message queue, the service process starts, and establishes a connection with the main process through the message queue; (2) The main process sends an initialization instruction, obtains the terminal list and the name of the shared memory, assembles the message format, and sends the message; (3) The service process receives the message, parses the terminal list and the shared memory name in the message according to the definition of the function code in the message, establishes a connection with the terminal in turn according to the terminal list, and creates a shared memory block according to the name of the shared memory; According to the shared memory including a system area and a device data area, the data area is sequentially divided into a status area, a YC data area, a YX data area, and a DN data area for each terminal; (4) The main process sends a start message, after the service process receives the message, communicates with the terminal, and writes the data collected by the terminal into the shared memory; the main process reads the terminal data from the shared memory; (5) The main process sends a polling data type message, after the service process receives the message, selectively writes the terminal data into the specified area in the shared memory according to whether the data type to be polled in the message is enabled; the main process reads the terminal data from the specified area in the shared memory; (6) The main process sends a non-polling data message to the message queue, after the service process receives the message, processes the message, and returns the processing result to the main process; (7) The main process sends a stop message, after the service process receives the message, disconnects all terminal connections, destroys the shared memory, and restores the initial settings.
Citation Information
Patent Citations
Method for calling FPGA equipment by multi-service request process and related device
CN110955535A