A multi-process communication method and system

Abstract

The present invention discloses a multi-process communication method and system, including a user application program and a bus scheduler, wherein each user application process realizes mutual communication through a soft bus, the communication between user applications is addressed through the user application process identification name, and the bus scheduler performs routing forwarding according to the target user application process identification name. The present invention provides a simple, feasible and efficient method for communication between multiple processes.

Description

Technical Field

[0001] The present invention belongs to the field of industrial automation, and relates to a multi-process communication technology in an embedded environment, and specifically to a multi-process communication method and system. Background Art

[0002] With the development of information technology, new functions of PLC are constantly being proposed, such as web function, LCD display function, historical data storage function, data cloud function, etc. PLC with only a single control function can no longer meet market demand. At present, the common practice is to use the new functions as threads inside the PLC control process, which makes the control process bloated and difficult to maintain. In order to reduce the complexity and coupling of the entire system and reduce the difficulty of development, the system needs to be split into multiple applications according to business requirements, but how to communicate between multiple applications has become a problem that needs to be solved. The commonly used solutions at present are: pipelines, shared memory, sockets, etc. These solutions are relatively low-level, and it is difficult to achieve high concurrency, low latency, and large data transmission, and they are not easy to transplant. Other communication middleware such as ACE, ICE, Boost ASIO, etc. are relatively complex to understand and use, and are not suitable for use on embedded devices.

[0003] According to the diverse applications of users, PLC controllers are required to be able to easily and quickly integrate third-party applications, but there is a lack of a method suitable for completing communication between multiple applications within the control system. Summary of the invention

[0004] In view of the shortcomings of the above-mentioned prior art, the present invention proposes a multi-process communication method and system, which includes a user application and a bus scheduler, and the user applications communicate with each other through forwarding by the bus scheduler. The present invention provides a simple, feasible and efficient method for communication between multiple processes.

[0005] To this end, the first object of the present invention is to provide a multi-process communication method, wherein user applications communicate with each other through forwarding by a bus scheduler, the communication between user applications is addressed by a user application process identification name, and the bus scheduler performs routing forwarding according to the target user application process identification name; the method comprises the following steps:

[0006] 1) The source user application process starts sending: calling the sending function to send data to the bus scheduling process, and the parameters filled in include the destination user application process identification name, the requested data length and the data content;

[0007] 2) Bus scheduling process forwarding: calling the receiving function to receive the data sent by the source user application process, extracting the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and calling the sending function to forward the data to the destination user application process;

[0008] 3) The destination user application process receives: the receiving function is called to receive the data forwarded by the bus scheduling process. According to the content of the received data, the source user application process identification name is extracted and the callback function is executed; if a response is required, it goes to 4); if no response is required, the communication ends;

[0009] 4) The destination user application process responds: the sending function is called to respond, and the parameters filled in include the destination user application process identification name, the request data length and the data content; the destination user application process identification name filled in this step 4) is the source user application process identification name extracted from the received data in step 3);

[0010] 5) Bus scheduling process forwarding: calling the receiving function to receive the response data from the destination user application process, extracting the source user application process identification name, the destination user application process identification name and the data to be sent according to the received data content, and calling the sending function to forward the data to the source user application process;

[0011] 6) The source user application process receives the response: calls the receiving function to receive the response data forwarded from the bus scheduling process, and executes the callback function according to the received data.

[0012] Furthermore, the user application process also includes the following initialization steps:

[0013] 1) Create a user application process running context;

[0014] 2) Create a socket;

[0015] 3)Configure the socket identifier;

[0016] 4) Establish an ipc connection for the socket.

[0017] Furthermore, the user application sends the following steps when the function sends data:

[0018] 1) Send a delimiter empty frame;

[0019] 2) Send the destination user application process socket identifier frame;

[0020] 3) Send a delimiter empty frame;

[0021] 4) Send data frame.

[0022] Furthermore, the user application process performs the following steps when receiving the data sent by the function:

[0023] 1) Receive the delimiter empty frame;

[0024] 2) receiving a source user application process socket identifier frame;

[0025] 3) Receive the delimiter empty frame;

[0026] 4) Receive data frame.

[0027] Furthermore, the bus scheduling process also includes the following initialization steps:

[0028] 1) Create a bus scheduling process running context;

[0029] 2) Create a socket;

[0030] 3)Configure the socket identifier;

[0031] 4) Bind the socket ipc connection.

[0032] Furthermore, the bus scheduling process receiving function includes the following steps:

[0033] 1) Receive source user application process socket identifier frame;

[0034] 2) Receive the delimiter empty frame;

[0035] 3) receiving the destination user application process socket identifier frame;

[0036] 4) Receive the delimiter empty frame;

[0037] 5) Receive data frame.

[0038] Furthermore, the bus scheduling process forwarding function includes the following steps:

[0039] 1) Send the destination user application process socket identifier frame;

[0040] 2) Send a delimiter empty frame;

[0041] 3) Send source user application process socket identifier frame;

[0042] 4) Send a delimiter empty frame;

[0043] 5) Send data frame.

[0044] A second object of the present invention is to provide a multi-process communication system, comprising:

[0045] 1) The source user application process starts the sending module, which is used to call the sending function to send data to the bus scheduling process. The parameters filled in include the destination user application process identification name, the request data length and the data content;

[0046] 2) The first forwarding module of the bus scheduling process is used to call the receiving function to receive the data sent by the user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the destination user application process;

[0047] 3) The destination user application process receiving module is used to call the receiving function to receive the data forwarded by the bus scheduling process, and extract the source user application process identification name and execute the callback function according to the content of the received data;

[0048] 4) a destination user application process response module, which is used to call a sending function to respond, and the parameters filled in include a destination user application process identification name, a request data length, and data content; the destination user application process identification name comes from the source user application process identification name extracted from the received data by the destination user application process receiving module;

[0049] 5) The second forwarding module of the bus scheduling process is used to call the receiving function to receive the response data from the destination user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the source user application process;

[0050] 6) The source user application process receives the response module, which is used to call the receiving function to receive the response data forwarded from the bus scheduling process, and execute the callback function according to the received data.

[0051] Furthermore, the user application sending function includes: a delimiter empty frame sending submodule, used to send a delimiter empty frame; a destination user application process socket identifier frame sending submodule, used to send a destination user application process socket identifier frame; a data frame sending submodule, used to send a data frame; the user application receiving function includes: a delimiter empty frame receiving submodule, used to receive a delimiter empty frame; a source user application process socket identifier frame submodule, used to receive a source user application process socket identifier frame; a data frame receiving submodule, used to receive a data frame.

[0052] Furthermore, the bus scheduling process receiving function includes: a source user application process socket identifier frame receiving submodule, used to receive the source user application process socket identifier frame; a delimiter empty frame receiving submodule, used to receive the delimiter empty frame; a destination user application process socket identifier frame receiving submodule, used to receive the destination user application process socket identifier frame; a data frame receiving submodule, which receives the data frame; the bus scheduling process forwarding function includes: a destination user application process socket identifier frame sending submodule, used to send the destination user application process socket identifier frame; a delimiter empty frame sending submodule, used to send the delimiter empty frame; a source user application process socket identifier frame sending submodule, used to send the source user application process socket identifier frame; and a data frame sending submodule, used to send the data frame.

[0053] The technical solution of the present invention has the advantages of lightweight design, flexible and easy expansion, and high communication efficiency, including:

[0054] 1) Simple, bus-type topology, user applications are addressed by application process identifiers, and application processes can communicate in both directions without distinction. The size of a single data frame is theoretically unlimited and is only limited by system resources;

[0055] 2) Flexible, user applications can be implemented in multiple languages ​​such as C, C++, Java, Python, etc., and applications from third parties can be easily integrated;

[0056] 3) High performance, the bus scheduler is implemented in C language with high execution efficiency, the underlying communication uses unix socket with low interaction delay.

[0057] The above advantages can support the smooth deployment and application of the present invention on embedded devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the technical solution of the present invention, the drawings required for describing the embodiments are briefly introduced below.

[0059] Figure 1 A diagram of the soft bus architecture of a multi-process communication system according to an embodiment of the present invention;

[0060] Figure 2 A schematic diagram of the communication flow between user application processes of the multi-process communication method according to an embodiment of the present invention;

[0061] Figure 3 This is a schematic diagram of the user application process initialization process according to an embodiment of the present invention;

[0062] Figure 4 A schematic diagram of a user application process sending flow according to an embodiment of the present invention;

[0063] Figure 5 A schematic diagram of a user application process receiving process according to an embodiment of the present invention;

[0064] Figure 6 A schematic diagram of the initialization process of the bus scheduling process according to an embodiment of the present invention;

[0065] Figure 7 A schematic diagram of a bus scheduling process receiving flow chart according to an embodiment of the present invention;

[0066] Figure 8 The figure is a schematic diagram of the sending flow of the bus scheduling process according to an embodiment of the present invention. DETAILED DESCRIPTION

[0067] The following is a clear and complete description of the technology in the embodiments of the present invention in conjunction with the accompanying drawings of the embodiments of the present invention. The described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0068] Terminology explanation:

[0069] 1. ZMQ

[0070] Zero Message Queue is a communication middleware based on socket. It supports multiple communication modes: Request-reply, Pub-sub, ParallelPipeline, Exclusive pair; supports multiple communication environments: inproc, ipc, tcp, multicast (epgm and pgm); supports multiple languages ​​such as C, C++, Java, Python, etc.; supports multiple operating systems such as Windows and Linux.

[0071] 2. DEALER-ROUTER mode

[0072] It is an extended request-response mode. A user application process can be abstracted into a DEALER process. The routing forwarding function of the ROUTER process can realize communication between multiple DEALER processes.

[0073] The embodiment of the present invention is based on the DEALER-ROUTER mode of ZMQ middleware, and is composed of a user application (DEALER) and a bus scheduler (ROUTER). The applications communicate with each other through the forwarding of the bus scheduler. The soft bus method provides a simple, feasible and efficient method for communication between multiple processes.

[0074] Figure 1 The figure shows a soft bus architecture diagram of a multi-process communication system embodiment suitable for embedded devices of the present invention, including DEALER user applications such as WEB, LCD, GCSCORE and ROUTER bus scheduler, and each user application process communicates with each other through the soft bus. The communication between DEALERs is addressed through the "user application process identification name", and ROUTER will route and forward according to the target user application process identification name.

[0075] Example 1

[0076] The following example uses the communication process between the "lcd" user application process and the "gcscore" user application process as an example. As the source user application process, "lcd" actively requests data from the "gcscore" destination user application process. Figure 2 As shown, the communication process is as follows:

[0077] 1. The "lcd" user application process starts sending: calls the dealer_send() sending function to send data to the ROUTER bus scheduling process, and fills in the parameters in sequence: the destination user application process identification name "gcscore", the requested data length and the data content.

[0078] 2. ROUTER bus scheduling process forwarding: call the router_recv() receiving function to receive the data sent from the "lcd" user application process. According to the content of the received data, extract the source user application process identification name "lcd", the destination user application process identification name "gcscore" and the data to be sent, and call router_send() to forward the data to the "gcscore" user application process.

[0079] 3. The "gcscore" user application process receives: the dealer_recv() receiving function is called to receive the data forwarded by the ROUTER bus scheduling process. According to the content of the received data, the source user application process identification name "lcd" is extracted and the receiving processing callback function is executed. It is also checked whether a response is required according to the actual application requirements. If a response is required, it proceeds to steps 4, 5, and 6. If no response is required, the communication ends.

[0080] 4. The "gcscore" user application process responds: call the dealer_send() sending function to respond, and fill in the parameters in sequence: the destination user application process identifier "lcd" comes from the source user application process identifier extracted from the received data in step 3, the request data length and data content.

[0081] 5. ROUTER bus scheduling process forwarding: call router_recv() to receive the response data from the "gcscore" user application process. According to the content of the received data, extract the source user application process identification name "gcscore", the destination user application process identification name "lcd" and the data to be sent, and call router_send() to forward the data to the "lcd" user application process.

[0082] 6. The "lcd" user application process receives the response: it calls dealer_recv() to receive the response data forwarded by the ROUTER process, and executes the callback function that updates the LCD display based on the received data.

[0083] It should be noted that, in order to distinguish between sending and receiving, the source user application process identification name is suffixed with "_TX" and the destination user application process identification name is suffixed with "_RX".

[0084] Example 2

[0085] The following is an example of implementing the DEALER user application process.

[0086] The DEALER user application process includes a sending thread and a receiving thread.

[0087] (I) In this embodiment, the DEALER user application process sends the thread workflow as follows:

[0088] 1. Initialization: Call the DEALER process initialization function dealer_init() to complete the sending initialization. Based on the API (Application Programming Interface) provided by ZMQ, the dealer_init() function is implemented as follows Figure 3 The specific initialization steps are as follows:

[0089] 1) Create a user application process running context: zmq_ctx_new();

[0090] 2) Create a socket: zmq_socket();

[0091] 3) Configure the socket identifier: zmq_setsockopt();

[0092] 4) Establish an ipc connection for the socket: zmq_connect().

[0093] 2. Send: When the user application needs to respond or actively send data to other user applications, call the DEALER user application sending function dealer_send() and fill in the target user application identification name, the data to be sent and the length and other parameters to complete the data sending. Based on the API provided by ZMQ, the dealer_send() function is implemented as follows Figure 4 The specific sending steps are as follows:

[0094] 1) Send delimiter empty frame: zmq_send();

[0095] 2) Send the destination user application process socket identifier frame: zmq_send();

[0096] 3) Send delimiter empty frame: zmq_send();

[0097] 4) Send data frame: zmq_send().

[0098] (II) In this embodiment, the workflow of the DEALER user application process receiving thread is as follows:

[0099] 1. Initialization: Call the DEALER process initialization function dealer_init() to complete the receiving initialization. Based on the API provided by ZMQ, the dealer_init() function is implemented as follows Figure 3 As shown, the initialization steps are the same as those of the user application process sending thread, so they are not repeated here.

[0100] 2. Receiving: When the user application process receives data sent by other user application processes, it calls the DEALER user application process sending function dealer_recv() to complete data reception and execute the receiving processing callback function. The dealer_recv() function is implemented based on the API provided by ZMQ. Figure 5 The specific receiving steps are as follows:

[0101] 1) Receive delimiter empty frame: zmq_recv();

[0102] 2) Receive the source user application process socket identifier frame: zmq_recv();

[0103] 3) Receive delimiter empty frame: zmq_recv();

[0104] 4) Receive data frame: zmq_recv().

[0105] Example 3

[0106] The following is an example of the implementation of the ROUTER bus scheduling process. In this embodiment, the ROUTER soft bus implements receiving and forwarding, and the workflow is as follows:

[0107] 1. Initialization of ROUTER bus scheduling process: Call the ROUTER bus scheduling process initialization function router_init() to complete the sending initialization. Based on the API provided by ZMQ, the router_init() function is implemented as follows Figure 6 As shown, the specific initialization steps are as follows:

[0108] 1) Create a bus scheduling process running context: zmq_ctx_new();

[0109] 2) Create a socket: zmq_socket();

[0110] 3) Configure the socket identifier: zmq_setsockopt();

[0111] 4) Bind the socket ipc connection: zmq_bind().

[0112] 2. ROUTER bus dispatching process forwarding processing: Call the ROUTER bus dispatching process receiving function router_recv() to complete data reception. According to the received data content, extract the source user application process identification name, the destination user application process identification name and the data to be sent, and complete data forwarding by calling the ROUTER bus dispatching process sending function router_send(). Based on the API provided by ZMQ, the router_recv() and router_send() functions are implemented as follows: Figure 7 , 8 As shown, the specific initialization steps are as follows:

[0113] The bus scheduling process receiving function comprises the following steps:

[0114] 1) Receive the source user application process socket identifier frame: zmq_recv();

[0115] 2) Receive delimiter empty frame: zmq_recv();

[0116] 3) Receive the destination user application process socket identifier frame: zmq_recv();

[0117] 4) Receive delimiter empty frame: zmq_recv();

[0118] 5) Receive data frame: zmq_recv().

[0119] The bus scheduling process forwarding function comprises the following steps:

[0120] 1) Send the destination user application process socket identifier frame: zmq_send();

[0121] 2) Send delimiter empty frame: zmq_send();

[0122] 3) Send source user application process socket identifier frame: zmq_send();

[0123] 4) Send delimiter empty frame: zmq_send();

[0124] 5) Send data frame: zmq_send().

[0125] Example 4

[0126] Figure 1 The figure shows a soft bus architecture diagram of an embodiment of a multi-process communication system, including DEALER user applications such as WEB, LCD, GCSCORE and ROUTER bus scheduler. Each user application process communicates with each other through the soft bus. The communication between DEALERs is addressed by "user application process identification name", and ROUTER will route and forward according to the target user application process identification name.

[0127] The bus scheduler of this embodiment is implemented based on the ROUTER mode of the ZMQ communication middleware. Its function is to receive source user application data and forward it to the destination user application. The user application is implemented based on the DEALER mode of the ZMQ communication middleware. Its function is to send data to the destination user application and receive data from other user applications.

[0128] The multi-process communication system of this embodiment includes:

[0129] 1) The source user application process starts the sending module, which is used to call the sending function to send data to the bus scheduling process. The parameters filled in include the destination user application process identification name, the request data length and the data content;

[0130] 2) The first forwarding module of the bus scheduling process is used to call the receiving function to receive the data sent by the user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the destination user application process;

[0131] 3) The destination user application process receiving module is used to call the receiving function to receive the data forwarded by the bus scheduling process, and extract the source user application process identification name and execute the callback function according to the content of the received data;

[0132] 4) a destination user application process response module, which is used to call a sending function to respond, and the parameters filled in include a destination user application process identification name, a request data length, and data content; the destination user application process identification name comes from the source user application process identification name extracted from the received data by the destination user application process receiving module;

[0133] 5) The second forwarding module of the bus scheduling process is used to call the receiving function to receive the response data from the destination user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the source user application process;

[0134] 6) The source user application process receives the response module, which is used to call the receiving function to receive the response data forwarded from the bus scheduling process, and execute the callback function according to the received data.

[0135] Furthermore, the user application sending function includes: a delimiter empty frame sending submodule, used to send a delimiter empty frame; a destination user application process socket identifier frame sending submodule, used to send a destination user application process socket identifier frame; and a data frame sending submodule, used to send a data frame.

[0136] The user application receiving function includes: a delimiter empty frame receiving submodule for receiving a delimiter empty frame; a source user application process socket identifier frame submodule for receiving a source user application process socket identifier frame; and a data frame receiving submodule for receiving a data frame.

[0137] The bus scheduling process receiving function includes: a source user application process socket identifier frame receiving submodule, which is used to receive the source user application process socket identifier frame; a delimiter empty frame receiving submodule, which is used to receive the delimiter empty frame; a destination user application process socket identifier frame receiving submodule, which is used to receive the destination user application process socket identifier frame; a data frame receiving submodule, which receives the data frame; the bus scheduling process forwarding function includes: a destination user application process socket identifier frame sending submodule, which is used to send the destination user application process socket identifier frame; a delimiter empty frame sending submodule, which is used to send the delimiter empty frame; a source user application process socket identifier frame sending submodule, which is used to send the source user application process socket identifier frame; and a data frame sending submodule, which is used to send the data frame.

[0138] The workflow of the system in this embodiment can refer to the communication process between the "lcd" user application process and the "gcscore" user application process in embodiments 1-3, as well as the workflow of the DEALER user application process and the ROUTER bus scheduling process, which will not be repeated here.

Claims

1. A multi-process communication method, characterized in that: The user applications communicate with each other through forwarding by the bus scheduler. The communication between the user applications is addressed by the user application process identification name. The bus scheduler performs routing forwarding according to the target user application process identification name. The steps include: 1) The source user application process starts sending: calling the sending function to send data to the bus scheduling process, and the parameters filled in include the destination user application process identification name, the requested data length and the data content; 2) Bus scheduling process forwarding: Call the receiving function to receive the data sent by the source user application process. According to the content of the received data, extract the source user application process identification name, the destination user application process identification name and the data to be sent, and call the sending function to forward the data to the destination user application process; 3) The destination user application process receives: the receiving function is called to receive the data forwarded by the bus scheduling process. According to the content of the received data, the source user application process identification name is extracted and the callback function is executed; if a response is required, it goes to 4), if no response is required, the communication ends; 4) Target user application process responds: call the send function to respond, and fill in the parameters including the target user application process identification name, request data length and data content; the target user application process identification name filled in this step 4) is the source user application process identification name extracted from the received data in step 3); 5) Bus scheduling process forwarding: Call the receiving function to receive the response data from the destination user application process. According to the content of the received data, extract the source user application process identification name, the destination user application process identification name and the data to be sent, and call the sending function to forward the data to the source user application process; 6) The source user application process receives the response: calls the receiving function to receive the response data forwarded from the bus scheduling process, and executes the callback function based on the received data.

2. The multi-process communication method according to claim 1, characterized in that: The user application process also includes the following initialization steps: 1) Create a user application process running context; 2) Create a socket; 3) Configure the socket identifier; 4) Establish an ipc connection for the socket.

3. The multi-process communication method according to claim 1, characterized in that: The user application process sends the following steps when the function sends data: 1) Send a delimiter empty frame; 2) Send the destination user application process socket identifier frame; 3) Send the delimiter empty frame; 4) Send data frame.

4. The multi-process communication method according to claim 1, characterized in that: The user application process receives the data sent by the function and executes the following steps: 1) Receive the delimiter empty frame; 2) Receive the source user application process socket identifier frame; 3) Receive the delimiter empty frame; 4) Receive data frames.

5. The multi-process communication method according to claim 1, characterized in that: The bus scheduling process also includes the following initialization steps: 1) Create a bus scheduling process running context; 2) Create a socket; 3) Configure the socket identifier; 4) Bind the socket ipc connection.

6. The multi-process communication method according to claim 1, characterized in that: The bus scheduling process receiving function comprises the following steps: 1) Receive the source user application process socket identifier frame; 2) Receive the delimiter empty frame; 3) Receive the destination user application process socket identifier frame; 4) Receive the delimiter empty frame; 5) Receive data frames.

7. The multi-process communication method according to claim 1, characterized in that: The bus scheduling process forwarding function comprises the following steps: 1) Send the destination user application process socket identifier frame; 2) Send a delimiter empty frame; 3) Send the source user application process socket identifier frame; 4) Send delimiter empty frame; 5) Send data frame.

8. A multi-process communication system, characterized in that: include: 1) The source user application process starts the sending module, which is used to call the sending function to send data to the bus scheduling process. The parameters filled in include the destination user application process identification name, the requested data length and the data content; 2) The first forwarding module of the bus scheduling process is used to call the receiving function to receive the data sent by the user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the destination user application process; 3) The destination user application process receiving module is used to call the receiving function to receive the data forwarded by the bus scheduling process, and extract the source user application process identification name and execute the callback function according to the content of the received data; 4) The destination user application process response module is used to call the sending function to respond, and the parameters filled in include the destination user application process identification name, request data length and data content; The destination user application process identification name comes from the source user application process identification name extracted from the received data by the destination user application process receiving module; 5) The second forwarding module of the bus scheduling process is used to call the receiving function to receive the response data from the destination user application process, and extract the source user application process identification name, the destination user application process identification name and the data to be sent according to the content of the received data, and call the sending function to forward the data to the source user application process; 6) The source user application process receives the response module, which is used to call the receiving function to receive the response data forwarded from the bus scheduling process, and execute the callback function according to the received data.

9. A multi-process communication system as claimed in claim 8, characterized in that: The user application process sending function includes: a delimiter empty frame sending submodule, which is used to send a delimiter empty frame; a destination user application process socket identifier frame sending submodule, which is used to send a destination user application process socket identifier frame; a data frame sending submodule, which is used to send a data frame; the user application process receiving function includes: a delimiter empty frame receiving submodule, which is used to receive a delimiter empty frame; a source user application process socket identifier frame submodule, which is used to receive a source user application process socket identifier frame; and a data frame receiving submodule, which is used to receive a data frame.

10. A multi-process communication system as claimed in claim 8, characterized in that: The bus scheduling process receiving function includes: a source user application process socket identifier frame receiving submodule, which is used to receive the source user application process socket identifier frame; a delimiter empty frame receiving submodule, which is used to receive the delimiter empty frame; a destination user application process socket identifier frame receiving submodule, which is used to receive the destination user application process socket identifier frame; a data frame receiving submodule, which receives the data frame; the bus scheduling process forwarding function includes: a destination user application process socket identifier frame sending submodule, which is used to send the destination user application process socket identifier frame; a delimiter empty frame sending submodule, which is used to send the delimiter empty frame; a source user application process socket identifier frame sending submodule, which is used to send the source user application process socket identifier frame; and a data frame sending submodule, which is used to send the data frame.

Images