A method to implement cross-process communication in Electron based on pipes
By implementing cross-process communication based on pipelines in Electron, the problem of Electron lacking standard cross-process communication methods is solved, the reliability and accessibility of communication is improved, and the stability of cross-process data interaction and reliable transmission of messages is achieved.
Patent Information
- Application Number
- CN202411662430.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-20
- Publication Date
- 2025-04-08
- Estimated Expiration
- 2044-11-20
AI Technical Summary
The Electron framework lacks standard cross-process communication methods, which makes it difficult to ensure the accessibility and communication reliability of messages in cross-process interactions.
A pipeline-based approach is used to implement cross-process communication in Electron, creating two pipelines to realize duplex communication of messages, and using Electron as the main application to create and maintain pipelines. Third-party applications are directly connected to the pipeline, avoiding the complexity of creating and maintaining pipelines.
The reliability and accessibility of inter-process communication in the Electron scenario are improved, and the closed-loop management of communication and the reliability of messages are ensured through mechanisms such as online messages, heartbeat messages and response messages.
Smart Images

Figure CN119149270B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of process communication, and in particular to a method for realizing cross-process communication in Electron based on pipelines. Background Art
[0002] In a multi-tasking, multi-process operating system, different processes may need to communicate with each other and share information to complete more complex tasks. Generally, processes are isolated from each other. In a multi-process operating system, each process has independent memory space and independent resources. This isolation ensures that the error of one process will not directly affect other processes, and also enhances the stability and security of the system.
[0003] The operating system generally provides basic communication methods, such as pipes, shared memory, sockets, etc. Pipes are a basic IPC mechanism that allows one process to write data to a pipe, and another process to read the data from the pipe. It provides a one-way communication mechanism, but in practice, communication is generally two-way communication, which requires reading and writing data at the same time.
[0004] Electron is an open source framework for building cross-platform desktop applications. Electron uses HTML, CSS and JavaScript to build desktop applications, combining the Chromium rendering engine and the Node.js runtime environment, so that developers can use front-end technology to create powerful desktop applications. Node.js provides server-side capabilities, allowing developers to use back-end functions in desktop applications. At the same time, using its cross-platform nature, developers can use the same code to build desktop applications for Windows, macOS and Linux operating systems, and its application is very extensive. However, Electron does not provide a standard cross-process communication method, and cross-process communication is a common technical means for desktop application development to achieve data interaction between applications. In cross-process interaction, the accessibility of messages is the key to communication. For this reason, it is necessary to determine whether the application exists and whether the application is turned on when communication is required. Therefore, the present invention proposes a method for realizing cross-process communication in Electron based on pipelines to improve the reliability and accessibility of inter-process communication in the Electron scenario. Summary of the invention
[0005] The purpose of the present invention is to provide a method for implementing cross-process communication in Electron based on pipelines to ensure the security and reliability of cross-process communication.
[0006] To achieve the above purpose, the technical solution adopted by the present invention is as follows:
[0007] A method for implementing cross-process communication in Electron based on pipes, including:
[0008] Step 1. Create the first pipeline and the second pipeline in Electron;
[0009] Step 2: Open the Electron development application and the third-party application and link them to the first pipeline and the second pipeline;
[0010] Step 3: The developed application goes online to generate an online message and sends it to the third-party application through the first pipeline. The third-party application reads the online message and waits for data interaction between the developed application and the third-party application.
[0011] Step 4: The development application generates a data interaction message and sends it to the third-party application through the first pipeline. The third-party application reads the data interaction message and parses the data in the data interaction message to complete the data interaction; or the third-party application generates a data interaction message and sends it to the development application through the second pipeline. The development application reads the data interaction message and parses the data in the data interaction message to complete the data interaction;
[0012] During the data interaction process in step 4, the development application sends a heartbeat message to the other party through the first pipeline or the third-party application sends a heartbeat message to the other party through the second pipeline at regular intervals. The other party receives the heartbeat message, adds the application that sends the heartbeat message to the created heartbeat queue, removes the application that does not send a heartbeat message within a set heartbeat time from the heartbeat queue, and marks the application as unresponsive. The development application or the third-party application only interacts with the applications in the heartbeat queue.
[0013] Furthermore, step 1 includes: step 11, loading Electron and obtaining the cache path of Electron; step 12, determining whether there is a cache file containing the first pipeline and the second pipeline in the cache path, and if not, creating the first pipeline and the second pipeline in the cache path in the form of a cache file.
[0014] Furthermore, in step 2, linking the first pipeline and the second pipeline specifically includes the following operations: obtaining the cache path of Electron, reading the cache file from the cache path, and linking the development application / third-party application to the first pipeline and the second pipeline.
[0015] Further, the third-party application includes one or more.
[0016] Furthermore, the data structure of the online message includes the application sending the message and the message type is a broadcast message.
[0017] Furthermore, the development application generates an online message / data interaction message / heartbeat message and sends it to the third-party application through the first pipeline, and the third-party application reads the online message / data interaction message / heartbeat message, which specifically includes the following steps: step a1, the development application generates an online message / data interaction message / heartbeat message; step a2, creating a writable stream object; step a3, writing the online message / data interaction message / heartbeat message to the first pipeline through the writable stream object; step a4, the third-party application monitors the first pipeline, and when the online message / data interaction message / heartbeat message is written to the first pipeline, a readable stream object is created; step a5, reading the online message / data interaction message / heartbeat message to the third-party application through the readable stream object.
[0018] Furthermore, the third-party application generates a data interaction message / heartbeat message and sends it to the development application through the second pipeline, and the development application reads the data interaction message / heartbeat message, which specifically includes the following steps: step b1, the development application generates a data interaction message / heartbeat message; step b2, creates a writable stream object; step b3, writes the data interaction message / heartbeat message to the second pipeline through the writable stream object; step b4, the development application monitors the second pipeline, and when the second pipeline has a data interaction message / heartbeat message written, creates a readable stream object; step b5, reads the data interaction message / heartbeat message to the development application through the readable stream object.
[0019] Furthermore, the data structure of the data interaction message includes a universal unique identifier of the message, an application sending the message, an application receiving the message, a message entity, and a message type of data message.
[0020] Furthermore, step 4 also includes: after the development application or third-party application reads the data interaction message, it needs to send a response message to the corresponding third-party application or development application that sent the message. The data structure of the response message includes the application that sends the message, the application that receives the message, the universal unique identification code of the corresponding data interaction message, and the message type is a response message.
[0021] Furthermore, the data structure of the heartbeat message includes an application sending the message and a message type of a heartbeat message.
[0022] Compared with the prior art, the present invention has the following beneficial effects:
[0023] The present invention realizes cross-process communication based on pipelines, creates two pipelines to realize duplex communication of messages, and uses Electron as the main application to create and maintain the two pipelines. When a third-party application communicates with the main application, the two pipelines are directly connected, and the third-party application does not need to create pipelines for maintenance. For data interaction in different directions, the two pipelines are created. The function of the write pipeline is first played for the message producer, and the function of the read pipeline is played for the message consumer. The read pipeline is only responsible for reading messages, and the write pipeline is only responsible for writing messages. In this way, the interaction of data can be isolated to avoid mutual influence, and the interaction ability of data can also be improved.
[0024] In the data interaction process of the present invention, the closed-loop management of communication between applications and the reliability of messages are guaranteed through online messages and heartbeat messages. Online messages ensure that third-party applications can perceive the existence of Electron applications in a timely manner, and heartbeat messages help to keep each application active and prevent communication interruptions caused by unexpected interruptions. At the same time, the reliability of messages can be effectively ensured through reply messages, and the loss or repeated transmission can be avoided by confirming the receipt of messages. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] Figure 1 The figure is a flow chart of the method of the present invention.
[0026] Figure 2 It is a schematic diagram of a specific implementation of the present invention. DETAILED DESCRIPTION
[0027] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than 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.
[0028] like Figure 1 As shown, an embodiment of a method for implementing cross-process communication in Electron based on a pipeline includes:
[0029] Step 1. Create the first pipeline and the second pipeline in Electron;
[0030] Step 2: Open the Electron development application and the third-party application and link them to the first pipeline and the second pipeline;
[0031] Step 3: The developed application goes online to generate an online message and sends it to the third-party application through the first pipeline. The third-party application reads the online message and waits for data interaction between the developed application and the third-party application.
[0032] Step 4: The development application generates a data interaction message and sends it to the third-party application through the first pipeline. The third-party application reads the data interaction message and parses the data in the data interaction message to complete the data interaction; or the third-party application generates a data interaction message and sends it to the development application through the second pipeline. The development application reads the data interaction message and parses the data in the data interaction message to complete the data interaction.
[0033] The present invention realizes cross-process communication based on pipelines, creates two pipelines to realize duplex communication of messages, and uses Electron as the main application to create and maintain the two pipelines. When a third-party application communicates with the main application, the two pipelines are directly connected, and the third-party application does not need to create pipelines for maintenance. For data interaction in different directions, the two pipelines are created. The function of the write pipeline is first played for the message producer, and the function of the read pipeline is played for the message consumer. The read pipeline is only responsible for reading messages, and the write pipeline is only responsible for writing messages. In this way, the interaction of data can be isolated to avoid mutual influence, and the interaction ability of data can also be improved.
[0034] The present invention has the ability of message communication through the creation of pipelines and the connection between applications, but it is not stable because its opening and closing are random during the use of the development application. Therefore, it is necessary to notify all third-party applications on the pipeline when the development application is closed or opened to ensure that the third-party applications can perceive the existence and disconnection of the development application in time. When the third-party application on the pipeline receives the online message, it means that it can interact with the development application that sent the online message.
[0035] When the development application is closed, it may not be able to notify the third-party application on the pipeline. At this time, the third-party application may mistakenly believe that the closed third-party application is still active, resulting in the inability to effectively reach the message. Therefore, it is necessary to detect the activity of the development application and the third-party application. For this reason, in the data interaction process of step 4, the development application sends a heartbeat message to the other party through the first pipeline or the third-party application sends a heartbeat message to the other party through the second pipeline at regular intervals (such as an interval of 5s), and the heartbeat message is used to perform active updates. The other party receives the heartbeat message and adds the application that sends the heartbeat message to the created heartbeat queue. When the other party receives the heartbeat message, it indicates that data interaction with the application can be performed. At the same time, it is also necessary to remove the application that has not sent a heartbeat message within a set heartbeat time (such as 5s) from the heartbeat queue, and mark this application in an unresponsive state. The heartbeat time is the time interval between the last heartbeat message sent by the application, and a timer is set accordingly for update. When data interaction is required, the development application or the third-party application needs to determine whether there is an application that needs to communicate in the current heartbeat queue. If so, the message is pushed to the corresponding pipeline.
[0036] In some embodiments, step 1 includes: step 1 includes: step 11, loading Electron, obtaining the cache path of Electron; step 12, determining whether there is a cache file containing the first pipeline and the second pipeline in the cache path, if not, creating the first pipeline and the second pipeline in the cache path in the form of a cache file. After Electron is loaded, the app.ready event will be triggered in the main process, and it is safer to access local files and resources at this time. The purpose of obtaining Electron's cache path is to save the pipeline to the cache path of the Electron system later, and to maintain the pipeline through the Electron system. If there is a cache file containing the first pipeline and the second pipeline in the cache path, there is no need to create it, and it can be used directly later.
[0037] In some embodiments, in step 2, linking the first pipeline and the second pipeline specifically includes the following operations: obtaining the cache path of Electron, reading the cache file from the cache path, and linking the development application / third-party application to the first pipeline and the second pipeline. For example, the cache file is opened through the Node file module and read using the read method, so that the development application / third-party application is linked to the first pipeline and the second pipeline.
[0038] In some embodiments, the third-party applications that communicate with the Electron development application include one or more, and all third-party applications that communicate with Electron will reuse the above two pipelines to interact with the Electron development application for data.
[0039] Figure 2 As a specific embodiment, Electron application A communicates with two third-party applications App B and App C. Application A sends a message to App B / App C, and App A pushes the message into the first pipe, and App B / App C listens to the message in the first pipe; or App B / App C sends a message to application A, and App B / App C pushes the message into the second pipe, and application A listens to the message in the second pipe. Taking application A sending a message to App B / App C as an example, application A acts as a message producer, and App B / App C acts as a message consumer. At this time, the first pipe is a write pipe writepipe for application A, and a read pipe readpipe for App B / AppC. Application A and App B / App C use the properties of the first pipe as a write pipe and a read pipe to write and read messages respectively. App B / App C sends a message to application A in the same way, so it will not be repeated.
[0040] In some embodiments, the development application generates an online message / data interaction message / heartbeat message and sends it to a third-party application through a first pipeline, and the third-party application reads the online message / data interaction message / heartbeat message, specifically including the following steps: step a1, the development application generates an online message / data interaction message / heartbeat message; step a2, creates a writable stream object; step a3, writes the online message / data interaction message / heartbeat message into the first pipeline through the writable stream object; step a4, the third-party application monitors the first pipeline, and when the first pipeline has an online message / data interaction message / heartbeat message written, creates a readable stream object; step a5, reads the online message / data interaction message / heartbeat message into the third-party application through the readable stream object. The writable stream object is created by fs.createWriteStream, and the readable stream object is created by fs.createReadStream.
[0041] In some embodiments, a third-party application generates a data interaction message / heartbeat message and sends it to a development application through a second pipeline, and the development application reads the data interaction message / heartbeat message, specifically including the following steps: step b1, the development application generates a data interaction message / heartbeat message; step b2, creates a writable stream object; step b3, writes the data interaction message / heartbeat message into the second pipeline through the writable stream object; step b4, the development application monitors the second pipeline, and when the second pipeline has a data interaction message / heartbeat message written, creates a readable stream object; step b5, reads the data interaction message / heartbeat message into the development application through the readable stream object. The writable stream object is created by fs.createWriteStream, and the readable stream object is created by fs.createReadStream.
[0042] Since a development application needs to communicate with multiple third-party applications, and each third-party application also needs multiple development applications, when exchanging messages, it is necessary to specify to whom the message is to be sent and where the message comes from.
[0043] The data structure of the online message of the present invention includes the application sending the message (such as from: "app a") and the message type is a broadcast message (such as type: "broadcast").
[0044] The data structure of the data interaction message of the present invention includes the universal unique identifier of the message (such as id: "1bcacaf2"), the application sending the message (such as from: "app b"), the application receiving the message (such as from: "app a"), the message entity (such as data: "data string"), and the message type is a data message (such as from: "app b"). The universal unique identifier ensures the uniqueness of the message.
[0045] After the development application or third-party application reads the data interaction message, it needs to send a reply message to the corresponding third-party application or development application that sent the message. The data structure of the reply message includes the application that sent the message, the application that received the message, the universal unique identifier of the corresponding data interaction message, and the message type is a reply message. The reply message contains the universal unique identifier of the corresponding data interaction message, so as to make a one-to-one reply. When the sender of the data interaction message receives the reply message, it indicates that the message has been sent successfully. Otherwise, the retransmission logic is triggered, and the number of retransmissions of the retransmission logic can be specified according to the specific business scenario. Generally, 3 retransmissions are sufficient.
[0046] The data structure of the heartbeat message of the present invention includes an application for sending the message and a message type of a heartbeat message.
[0047] Each message of the present invention preferably uses JSON data or protobuff data to ensure data compatibility and is compatible with application programs developed in more development languages such as c, python, java, etc.
[0048] Finally, it should be noted that the above embodiments are only preferred embodiments of the present invention to illustrate the technical solutions of the present invention, rather than limiting them, and certainly not limiting the patent scope of the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention. In other words, any changes or modifications made to the main design concept and spirit of the present invention that have no substantive significance, and the technical problems they solve are still consistent with the present invention, should be included in the protection scope of the present invention. In addition, the direct or indirect application of the technical solutions of the present invention in other related technical fields is also included in the patent protection scope of the present invention.
Claims
1. A method for implementing cross-process communication in Electron based on pipelines, characterized in that: include: Step 1. Create the first pipeline and the second pipeline in Electron; Step 2: Open the Electron development application and the third-party application and link them to the first pipeline and the second pipeline; Step 3: The developed application goes online to generate an online message and sends it to the third-party application through the first pipeline. The third-party application reads the online message and waits for data interaction between the developed application and the third-party application. Step 4: The development application generates a data interaction message and sends it to the third-party application through the first pipeline. The third-party application reads the data interaction message and parses the data in the data interaction message to complete the data interaction; or the third-party application generates a data interaction message and sends it to the development application through the second pipeline. The development application reads the data interaction message and parses the data in the data interaction message to complete the data interaction; In the data interaction process of step 4, the development application sends a heartbeat message to the other party through the first pipeline or the third-party application sends a heartbeat message to the other party through the second pipeline at regular intervals. The other party receives the heartbeat message, adds the application sending the heartbeat message to the created heartbeat queue, removes the application that does not send a heartbeat message within a set heartbeat time from the heartbeat queue, and marks the application as unresponsive. The development application or the third-party application only interacts with the applications in the heartbeat queue; Develop an application to generate an online message / data interaction message / heartbeat message and send it to a third-party application through a first pipeline, and the third-party application reads the online message / data interaction message / heartbeat message, specifically including the following steps: step a1, develop an application to generate an online message / data interaction message / heartbeat message; step a2, create a writable stream object; step a3, write the online message / data interaction message / heartbeat message into the first pipeline through the writable stream object; step a4, the third-party application monitors the first pipeline, and when the online message / data interaction message / heartbeat message is written into the first pipeline, a readable stream object is created; step a5, read the online message / data interaction message / heartbeat message into the third-party application through the readable stream object; The third-party application generates a data interaction message / heartbeat message and sends it to the development application through the second pipeline, and the development application reads the data interaction message / heartbeat message, which specifically includes the following steps: step b1, the development application generates a data interaction message / heartbeat message; step b2, creates a writable stream object; step b3, writes the data interaction message / heartbeat message into the second pipeline through the writable stream object; step b4, the development application monitors the second pipeline, and when the second pipeline has a data interaction message / heartbeat message written, creates a readable stream object; step b5, reads the data interaction message / heartbeat message into the development application through the readable stream object; The third-party application includes one or more; the data structure of the data interaction message includes the universal unique identification code of the message, the application sending the message, the application receiving the message, the message entity, and the message type is a data message.
2. According to claim 1, a method for implementing cross-process communication in Electron based on pipelines is characterized in that: Step 1 includes: step 11, loading Electron and obtaining the cache path of Electron; step 12, determining whether there is a cache file containing the first pipeline and the second pipeline in the cache path, and if not, creating the first pipeline and the second pipeline in the cache path in the form of a cache file.
3. According to claim 2, a method for implementing cross-process communication in Electron based on pipelines is characterized in that: In step 2, linking the first pipeline and the second pipeline specifically includes the following operations: obtaining the cache path of Electron, reading the cache file from the cache path, and linking the development application / third-party application to the first pipeline and the second pipeline.
4. According to claim 1, a method for implementing cross-process communication in Electron based on pipelines is characterized in that: The data structure of the online message includes the application that sent the message and the message type is a broadcast message.
5. According to claim 1, a method for implementing cross-process communication in Electron based on pipelines is characterized in that: Step 4 also includes: after the development application or third-party application reads the data interaction message, it needs to send a response message to the corresponding third-party application or development application that sent the message. The data structure of the response message includes the application that sends the message, the application that receives the message, the universal unique identification code of the corresponding data interaction message, and the message type is a response message.
6. According to claim 1, a method for implementing cross-process communication in Electron based on pipelines is characterized in that: The data structure of the heartbeat message includes the application sending the message and the message type is a heartbeat message.
Citation Information
Patent Citations
Cluster-based Node.js multi-process management method and system
CN113986491A