CN110928701A - Communication registration method and device - Google Patents

Communication registration method and device Download PDF

Info

Publication number
CN110928701A
CN110928701A CN201811100658.4A CN201811100658A CN110928701A CN 110928701 A CN110928701 A CN 110928701A CN 201811100658 A CN201811100658 A CN 201811100658A CN 110928701 A CN110928701 A CN 110928701A
Authority
CN
China
Prior art keywords
message
server
reply
registration
shared memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201811100658.4A
Other languages
Chinese (zh)
Inventor
赵冉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Ingenic Semiconductor Co Ltd
Original Assignee
Beijing Ingenic Semiconductor Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Ingenic Semiconductor Co Ltd filed Critical Beijing Ingenic Semiconductor Co Ltd
Priority to CN201811100658.4A priority Critical patent/CN110928701A/en
Publication of CN110928701A publication Critical patent/CN110928701A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/541Client-server

Abstract

The invention provides a communication registration method and a device, wherein the method comprises the following steps: after the server is started, a shared memory is established; the server side broadcasts a query message to the process and waits for the process to reply, wherein after the process is started, the shared memory is mapped and a registration message is broadcasted; the server receives the registration message; and the server side responds to the registration information, registers the progress and replies a confirmation message. The registration of the process is completed through the scheme, so that the multi-process communication can be effectively carried out, and the aim of simply and efficiently carrying out the multi-process communication is fulfilled.

Description

Communication registration method and device
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a communication registration method and apparatus.
Background
Inter-process communication refers to the propagation or exchange of information between different processes, and common inter-process communication methods include: pipeline, message queue, semaphore, shared memory, socket.
Wherein, the pipeline divide into: the method comprises a nameless pipeline and a named pipeline, wherein the nameless pipeline can only be used for communication between processes with affinity, the named pipeline can exchange data between unrelated processes, but the named pipeline can only bear a plain byte stream, and the data of the pipeline is cleared when the data is read out. The message queue can complete a plurality of inter-process message transmission works, but the efficiency is low and the real-time performance is poor. Semaphores are used for interprocess synchronization, and if data needs to be transferred between processes, a shared memory needs to be combined. Shared memory means that two or more processes share a given memory area, which is fast and efficient because the processes directly access the memory, and then need to be synchronized because multiple processes can operate a block of memory at the same time. Socket is an inter-process communication mode of a surface phase network, and can not only realize inter-process communication in the same local computer but also realize communication of processes on different hosts.
The most direct multi-process message communication method is to establish one-to-one communication between two processes needing communication, which wastes resources and is not beneficial to unified management. The common multi-process message communication is realized by using socket, but the message transmission speed is low, and the real-time performance is not good.
An effective solution is not provided at present for how to efficiently perform multi-process message communication in real time.
Disclosure of Invention
The embodiment of the invention provides a communication registration method and a communication registration device, which aim to achieve the aim of efficiently carrying out multi-process communication in real time.
The embodiment of the invention provides a communication registration method, which comprises the following steps:
after the server is started, a shared memory is established;
the server side broadcasts a query message to the process and waits for the process to reply, wherein after the process is started, the shared memory is mapped and a registration message is broadcasted;
the server receives the registration message;
and the server side responds to the registration information, registers the progress and replies a confirmation message.
In one embodiment, after the server broadcasts a query message to a process and waits for a reply from the process, the method further includes:
determining whether the query message needs process reply or not through a control bus established by the shared memory;
and in the case that the reply is determined to be needed, storing the query message in a specific memory location.
In one embodiment, after the server broadcasts a query message to a process and waits for a reply from the process, the method further includes:
determining whether the query message needs process reply or not through a control bus established by the shared memory;
and under the condition that the reply is determined not to be needed, sequentially arranging the query messages in a ringbuffer mode.
In one embodiment, the server broadcasting a query message to a process and waiting for a reply from the process includes:
the server adds header information in the query message, wherein the header information is used for indicating that the message is a broadcast message;
and the server side sends out the query message added with the header information.
The embodiment of the present invention further provides a communication registration apparatus, located at a server, including:
the establishing module is used for establishing a shared memory after the server is started;
the broadcast module is used for broadcasting the query message to the process and waiting for the process to reply, wherein after the process is started, the shared memory is mapped and the registration message is broadcasted;
a receiving module, configured to receive the registration message;
and the registration module is used for responding to the registration information, registering the progress and replying a confirmation message.
In one embodiment, the above apparatus further comprises:
the first determining module is used for determining whether the inquiry message needs process reply or not through a control bus established by the shared memory after the server broadcasts the inquiry message to the process and waits for the process reply;
and the storage module is used for storing the query message in a specific memory location under the condition that the reply is determined to be needed.
In one embodiment, the above apparatus further comprises:
a second determining module, configured to determine, through a control bus created by the shared memory, whether the query message needs to be replied by the process after the server broadcasts the query message to the process and waits for a reply from the process;
and the arrangement module is used for sequentially arranging the query messages in a ringbuffer mode under the condition that the reply is determined not to be needed.
In one embodiment, the broadcasting module includes:
an adding unit, configured to add header information to the query message, where the header information is used to indicate that the message is a broadcast message;
and the sending unit is used for sending the query message added with the header information.
In the embodiment of the invention, after the server is started, a shared memory is created, an inquiry message is broadcasted to a process, and the process is waited to reply, wherein after the process is started, the shared memory is mapped, and a registration message is broadcasted; and after receiving the registration message, the server registers the process and replies a confirmation message. The registration of the process is completed through the mode, so that the multi-process communication can be effectively carried out, and the aim of simply and efficiently carrying out the multi-process communication is fulfilled.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principles of the invention. In the drawings:
FIG. 1 is a block diagram of a multi-process messaging system according to an embodiment of the present invention;
FIG. 2 is a flow chart of a method of multi-process message communication according to an embodiment of the invention;
FIG. 3 is a flowchart of a method for multi-process communication registration according to an embodiment of the present invention;
fig. 4 is a flowchart of a communication registration method according to an embodiment of the present invention;
fig. 5 is a block diagram of a communication registration apparatus according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail with reference to the following embodiments and accompanying drawings. The exemplary embodiments and descriptions of the present invention are provided to explain the present invention, but not to limit the present invention.
To better illustrate the present application, the following explanations of several terms involved are as follows:
1) IPCMessage: the method is a message communication mechanism realized by a share memory;
2) client: each process for mapping the shared memory is called a client;
3) ClientInterface: providing a method for operating a Client;
4) ringbuffer: and the messages are sequentially arranged backwards from the initial position of the buffer, and when the buffer is full, the messages return to the initial position for continuous storage.
Considering that the existing multi-process message communication is realized by using socket, the message transmission is influenced by network conditions, the speed is slow, and the requirements cannot be met for some use scenes with high real-time requirements. Therefore, in the embodiment, by utilizing the advantages of high speed and high efficiency of shared memory and combining the requirement that the messages among the multiple processes can be flexibly and quickly transmitted, an efficient multi-process message communication mechanism is provided, so that the efficiency is improved, the resources can be saved, and the technical effects of improving the message transmission speed and the message transmission flexibility among the multiple processes are achieved.
As shown in fig. 1, in this example, a multiprocess messaging system is provided, which may include: a shared memory 10, the shared memory 10 being divided into a first control bus 101 and a second control bus 102, wherein:
the first control bus 101 is used for the server 103 to actively send control messages to all the processes 104 and receive messages replied by the processes;
the second control bus 102 is used for processes to actively send messages to the server and other processes.
For messages requiring immediate results, a specific memory location may be set for storing to increase response time. For example, the first control bus may be provided with a specific memory location for storing messages requiring immediate results to be returned.
On one bus, messages which only need to be received by the opposite Client and do not need to be replied (for example, when a plurality of messages are sent simultaneously) are sequentially arranged in a ring buffer mode, and the time for reserving the messages is related to the size of the shared memory. For example, the first control bus may be provided with a ringbuffer mode, wherein messages of the server are sequentially arranged according to the ringbuffer mode under the condition that the process does not need to reply to the messages.
Similarly, the second control bus may be provided in the form of the first control bus. That is, the second control bus may be provided with a ringbuffer mode, in which messages of processes at the transmitting end are sequentially arranged according to the ringbuffer mode under the condition that the processes at the receiving end do not need to reply to the messages.
For a control bus, a server end and a client end are controlled, the server end is used for managing a registered client list, and a client interface is distributed to each client. The client end is used for realizing a client interface and registering the client by matching with the server. Specifically, the first control bus includes a server side control module and a process side control module, wherein the server side control module is configured to manage a registered process list and allocate a process access interface to each process, and the process side control module is configured to implement the process access interface. Similarly, the second control bus may include a server side control module and a process side control module, where the server side control module is configured to manage a registered process list and allocate a process access interface to each process, and the process side control module is configured to implement the process access interface.
Based on the above multiprocess communication system, in this example, a multiprocess communication method is further provided, as shown in fig. 2, the method may include the following steps:
step 201: a control bus receives a message sent by a process;
step 202: the method comprises the steps that a control bus adds header information to a message sent by a process, wherein the header information is used for indicating an ID of the process sending the message and an ID of the process receiving the message, and the IDs are used for uniquely identifying the processes;
step 203: the control bus sends out the message added with the header information.
After the control bus sends out the message added with the header information in step 203, the control bus can determine whether the message needs to be replied; setting a specific memory location on a control bus under the condition that the message needs to be replied; and storing the message through the specific memory location.
After the control bus sends out the message added with the header information, the process can receive the message added with the header information; the process extracts the ID of the process receiving the message in the header information; comparing the ID of the process receiving the message with the ID of the process; if so, the message with the added header information is processed. That is, for the recipient process, it can be determined whether the received message itself needs to be processed by the process ID in the header information, and if so, it is processed, and if not, it is discarded.
In practical implementation, not only the message that needs to be processed by itself is indicated in the header information, but also the message that indicates that the message is a broadcast message is indicated in the header information, which is also needed to be processed by the process of the receiving party. That is, after comparing the ID of the process receiving the message with the ID of itself, it may be determined whether the ID of the process receiving the message identifies the message as a broadcast message; in case that it is determined to be a broadcast message, the message to which the header information is added is processed.
The control bus can be divided into a first control bus and a second control bus, wherein the first control bus is used for the server side to actively send control messages to all processes and receive messages replied by the processes; and the second control bus is used for actively sending messages to the server and other processes by the processes. Specifically, one shared memory can be divided into two parts which are respectively used as two buses, one bus is used for the server to actively send control messages to all clients and clients to reply messages, and the other bus is used for the clients to actively send messages to the server and other clients, so that the simultaneous bidirectional communication of the server and the clients is realized, and the real-time performance of control is guaranteed.
Because the communication among the multiple processes is realized by accessing the server and the processes to the same communication system, the problem of communication registration is involved, and each process can be registered in time. In this example, a registration method based on server-side priority start and a registration method based on process priority start are proposed, and the following two registration methods are described as follows:
1) as shown in fig. 3, the registration method based on server-side preferential initiation may include the following steps:
step 301: after the server is started, a shared memory is established;
step 302: the server side broadcasts a query message to the process and waits for the process to reply, wherein after the process is started, the shared memory is mapped and a registration message is broadcasted;
step 303: the server receives the registration message;
step 304: and the server side responds to the registration information, registers the progress and replies a confirmation message.
Specifically, after the server broadcasts a query message to the process and waits for the process to reply, whether the query message needs the process to reply or not can be determined through a control bus created by the shared memory; and in the case that the reply is determined to be needed, storing the query message in a specific memory location.
After a server broadcasts a query message to a process and waits for the process to reply, whether the query message needs the process to reply or not can be determined through a control bus established by the shared memory; and under the condition that the reply is determined not to be needed, sequentially arranging the query messages in a ringbuffer mode.
That is, different processing is used for messages that need to be replied to and messages that do not need to be replied to.
The step 302, where the server broadcasts the query message to the process and waits for a reply from the process, may include: the server adds header information in the query message, wherein the header information is used for indicating that the message is a broadcast message; and the server side sends out the query message added with the header information.
2) The registration method based on the preferential initiation of the process, as shown in fig. 4, may include the following steps:
step 401: after the process is started, a shared memory is established;
step 402: the process actively broadcasts a registration message and waits for receiving a server message, wherein after the server is started, the shared memory is mapped and a query message is broadcast;
step 403: the process receives the query message;
step 404: and the process responds to the inquiry message and broadcasts a registration message, wherein the server side responds to the registration message to register the proceeding process.
Specifically, after a process broadcasts a registration message and waits for receiving a server message, whether the registration message needs to be replied or not can be determined through a control bus established by a shared memory; in the event that a reply is determined to be required, the registration message is stored at a particular memory location.
After a process broadcasts a registration message and waits for receiving a server message, whether the registration message needs a process reply or not can be determined through a control bus established by the shared memory; and under the condition that the reply is determined not to be needed, sequentially arranging the registration messages in a ringbuffer mode.
The process of step 402 broadcasts the registration message and waits for receiving the server message, which may include: adding header information in the registration message, wherein the header information is used for indicating that the registration message is a broadcast message; and sending out the query message added with the header information.
The multi-process communication method is described below with reference to a specific embodiment, however, it should be noted that the specific embodiment is only for better describing the present application and is not to be construed as a limitation of the present application.
In this example, the IPCMessage is considered as a control bus, and each client on the bus can communicate with any client, and can also broadcast to all clients. The IPCMessage allocates a unique id to each client, and assigns the id of a process for sending and receiving the message to the message adding header information, and can also assign the broadcast id to send the message to all processes.
One process sends a message and informs other processes through a semaphore, the other processes receive the message and compare whether the message is the same as the id of the other processes, if the id is the same or the id is broadcast, the message is processed, and otherwise, the message is ignored.
Wherein, the IPCMessage may include: the server end and the client end are controlled, the server end is used for managing a registered client list, and a client interface is distributed to each client. The client end is used for realizing a client interface and registering the client by matching with the server.
Firstly, a shared memory is divided into two parts which are respectively used as two buses, one bus is used for a server to actively send control messages to all clients and client reply messages, and the other bus is used for the client to actively send messages to the server and other clients, so that the simultaneous two-way communication of the server and the clients is realized, and the real-time performance of control is guaranteed.
On one bus, messages which only need to be received by the opposite Client and do not need to be replied (for example, when a plurality of messages are sent simultaneously) are sequentially arranged in a ring buffer mode, and the time for reserving the messages is related to the size of the shared memory. For messages requiring immediate results, a specific memory location may be set for storage to increase response time.
The negotiation process of the server and the client is as follows:
1) if the server side is started first, a shared memory is created, a client message is broadcasted and inquired and the client is waited to reply, after the client is started, the shared memory is mapped, a client message is broadcasted and registered, and the server registers the client and replies a confirmation message.
2) If the client end is started first, a shared memory is created, client information is broadcasted and registered, the server end information is waited to be received, the shared memory is mapped after the server end is started, the client information is broadcasted and inquired, the client information is broadcasted and registered after the client receives the client information, and the server registers the client and replies confirmation information.
3) If a new client is added, the client actively broadcasts a registration client message, and the server registers the client and replies a confirmation message.
In the above example, the bus and the shared memory are combined, so that the communication efficiency and the communication flexibility of the multi-process message are improved. Specifically, full-duplex communication between the client and the server is realized through the two buses, real-time performance of control of adding a new client and the like is guaranteed, the problem that messages on one bus are frequent is solved through the ringbuffer, and the response speed is improved by storing the messages needing to be replied in time at the fixed position of one bus.
Based on the same inventive concept, the embodiment of the present invention further provides a communication registration apparatus, as described in the following embodiments. Because the principle of the communication registration apparatus for solving the problem is similar to the communication registration method, the implementation of the communication registration apparatus can refer to the implementation of the communication registration method, and repeated details are not repeated. As used hereinafter, the term "unit" or "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated. Fig. 5 is a block diagram of a communication registration apparatus according to an embodiment of the present invention, as shown in fig. 5, the communication registration apparatus located at a server may include: a creation module 501, a broadcast module 502, a reception module 503, and a registration module 504, and the structure will be described below.
A creating module 501, configured to create a shared memory after a server is started;
a broadcasting module 502, configured to broadcast a query message to a process and wait for a process reply, where after the process is started, the shared memory is mapped, and a registration message is broadcast;
a receiving module 503, configured to receive the registration message;
a registration module 504, configured to register a process and reply to a confirmation message in response to the registration information.
In one embodiment, the above-mentioned communication registration apparatus may further include: the first determining module is used for determining whether the inquiry message needs process reply or not through a control bus established by the shared memory after the server broadcasts the inquiry message to the process and waits for the process reply;
and the storage module is used for storing the query message in a specific memory location under the condition that the reply is determined to be needed.
In one embodiment, the above-mentioned communication registration apparatus may further include: a second determining module, configured to determine, through a control bus created by the shared memory, whether the query message needs to be replied by the process after the server broadcasts the query message to the process and waits for a reply from the process; and the arrangement module is used for sequentially arranging the query messages in a ringbuffer mode under the condition that the reply is determined not to be needed.
In one embodiment, the broadcasting module 502 may include: an adding unit, configured to add header information to the query message, where the header information is used to indicate that the message is a broadcast message; and the sending unit is used for sending the query message added with the header information.
In another embodiment, a software is provided, which is used to execute the technical solutions described in the above embodiments and preferred embodiments.
In another embodiment, a storage medium is provided, in which the software is stored, and the storage medium includes but is not limited to: optical disks, floppy disks, hard disks, erasable memory, etc.
From the above description, it can be seen that the embodiments of the present invention achieve the following technical effects: after the server is started, creating a shared memory, broadcasting a query message to a process and waiting for a process reply, wherein after the process is started, mapping the shared memory and broadcasting a registration message; and after receiving the registration message, the server registers the process and replies a confirmation message. The registration of the process is completed through the mode, so that the multi-process communication can be effectively carried out, and the aim of simply and efficiently carrying out the multi-process communication is fulfilled.
Although the present application provides method steps as described in an embodiment or flowchart, additional or fewer steps may be included based on conventional or non-inventive efforts. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or client product executes, it may execute sequentially or in parallel (e.g., in the context of parallel processors or multi-threaded processing) according to the embodiments or methods shown in the figures.
The apparatuses or modules illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. The functionality of the modules may be implemented in the same one or more software and/or hardware implementations of the present application. Of course, a module that implements a certain function may be implemented by a plurality of sub-modules or sub-units in combination.
The methods, apparatus or modules described herein may be implemented in computer readable program code to a controller implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, Application Specific Integrated Circuits (ASICs), programmable logic controllers and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may therefore be considered as a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
Some of the modules in the apparatus described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary hardware. Based on such understanding, the technical solutions of the present application may be embodied in the form of software products or in the implementation process of data migration, which essentially or partially contributes to the prior art. The computer software product may be stored in a storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to perform the methods described in the various embodiments or portions of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same or similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. All or portions of the present application are operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
While the present application has been described with examples, those of ordinary skill in the art will appreciate that there are numerous variations and permutations of the present application without departing from the spirit of the application, and it is intended that the appended claims encompass such variations and permutations without departing from the spirit of the application.

Claims (10)

1. A method for communication registration, comprising:
after the server is started, a shared memory is established;
the server side broadcasts a query message to the process and waits for the process to reply, wherein after the process is started, the shared memory is mapped and a registration message is broadcasted;
the server receives the registration message;
and the server side responds to the registration information, registers the progress and replies a confirmation message.
2. The method of claim 1, wherein the server broadcasts a query message to the process and waits for a reply from the process, and wherein the method further comprises:
determining whether the query message needs process reply or not through a control bus established by the shared memory;
and in the case that the reply is determined to be needed, storing the query message in a specific memory location.
3. The method of claim 1, wherein the server broadcasts a query message to the process and waits for a reply from the process, and wherein the method further comprises:
determining whether the query message needs process reply or not through a control bus established by the shared memory;
and under the condition that the reply is determined not to be needed, sequentially arranging the query messages in a ringbuffer mode.
4. The method of claim 1, wherein the server broadcasting a query message to a process and waiting for a process reply comprises:
the server adds header information in the query message, wherein the header information is used for indicating that the message is a broadcast message;
and the server side sends out the query message added with the header information.
5. A communication registration apparatus, located at a server, comprising:
the establishing module is used for establishing a shared memory after the server is started;
the broadcast module is used for broadcasting the query message to the process and waiting for the process to reply, wherein after the process is started, the shared memory is mapped and the registration message is broadcasted;
a receiving module, configured to receive the registration message;
and the registration module is used for responding to the registration information, registering the progress and replying a confirmation message.
6. The apparatus of claim 5, further comprising:
the first determining module is used for determining whether the inquiry message needs process reply or not through a control bus established by the shared memory after the server broadcasts the inquiry message to the process and waits for the process reply;
and the storage module is used for storing the query message in a specific memory location under the condition that the reply is determined to be needed.
7. The apparatus of claim 5, further comprising:
a second determining module, configured to determine, through a control bus created by the shared memory, whether the query message needs to be replied by the process after the server broadcasts the query message to the process and waits for a reply from the process;
and the arrangement module is used for sequentially arranging the query messages in a ringbuffer mode under the condition that the reply is determined not to be needed.
8. The apparatus of claim 5, wherein the broadcasting module comprises:
an adding unit, configured to add header information to the query message, where the header information is used to indicate that the message is a broadcast message;
and the sending unit is used for sending the query message added with the header information.
9. A server device comprising a processor and a memory for storing processor-executable instructions which, when executed by the processor, implement the steps of the method of any one of claims 1 to 4.
10. A computer readable storage medium having stored thereon computer instructions which, when executed, implement the steps of the method of any one of claims 1 to 4.
CN201811100658.4A 2018-09-20 2018-09-20 Communication registration method and device Pending CN110928701A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811100658.4A CN110928701A (en) 2018-09-20 2018-09-20 Communication registration method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811100658.4A CN110928701A (en) 2018-09-20 2018-09-20 Communication registration method and device

Publications (1)

Publication Number Publication Date
CN110928701A true CN110928701A (en) 2020-03-27

Family

ID=69856304

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811100658.4A Pending CN110928701A (en) 2018-09-20 2018-09-20 Communication registration method and device

Country Status (1)

Country Link
CN (1) CN110928701A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101777012A (en) * 2009-12-31 2010-07-14 深圳市蓝韵实业有限公司 Three-dimensional image server multi-task managing and scheduling method
CN103455380A (en) * 2012-06-05 2013-12-18 上海斐讯数据通信技术有限公司 Multi-process communication system and establishment and communication method thereof
CN104346229A (en) * 2014-11-14 2015-02-11 国家电网公司 Processing method for optimization of inter-process communication of embedded operating system
CN105760217A (en) * 2016-03-23 2016-07-13 深圳森格瑞通信有限公司 Method for accessing shared memory
CN107491355A (en) * 2017-08-17 2017-12-19 山东浪潮商用系统有限公司 Funcall method and device between a kind of process based on shared drive

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101777012A (en) * 2009-12-31 2010-07-14 深圳市蓝韵实业有限公司 Three-dimensional image server multi-task managing and scheduling method
CN103455380A (en) * 2012-06-05 2013-12-18 上海斐讯数据通信技术有限公司 Multi-process communication system and establishment and communication method thereof
CN104346229A (en) * 2014-11-14 2015-02-11 国家电网公司 Processing method for optimization of inter-process communication of embedded operating system
CN105760217A (en) * 2016-03-23 2016-07-13 深圳森格瑞通信有限公司 Method for accessing shared memory
CN107491355A (en) * 2017-08-17 2017-12-19 山东浪潮商用系统有限公司 Funcall method and device between a kind of process based on shared drive

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
啦啦风吹: "Windows进程间通信--共享内存映射文件(FileMapping)--VS2012下发送和接收", 《HTTPS://WWW.CNBLOGS.COM/LALAFENGCHUI/P/4223584.HTML》 *

Similar Documents

Publication Publication Date Title
KR102004160B1 (en) Apparatus and method for logical grouping method of iot connected client nodes using client identifier
CN108449410B (en) Message management method, system and related device in cloud platform
US8898191B2 (en) Method for providing connections for application processes to a database server
US9424027B2 (en) Message management system for information transfer within a multitasking system
JP2008033952A (en) Most eligible server in common work queue environment
US9448862B1 (en) Listening for externally initiated requests
JP2002223214A (en) Method and apparatus for communication between computer systems using sliding transmission window for ordered message in cluster computer environment
CN106803841B (en) Method and device for reading message queue data and distributed data storage system
CN110928700B (en) Multi-process communication method and device
CN103827830A (en) System and method for preventing single-point bottleneck in a transactional middleware machine environment
CN112822300B (en) RDMA (remote direct memory Access) -based data transmission method and device and electronic equipment
CN110928703B (en) Multi-process communication registration method and device
CN110928702B (en) Multi-process message communication system
CN106911739B (en) Information distribution method and device
CN110928701A (en) Communication registration method and device
US9130881B2 (en) Direct return to source (DRS) routing of customer information control systems (CICS) transactions
CN112448977A (en) System, method, apparatus and computer readable medium for assigning tasks
CN112822299B (en) RDMA (remote direct memory Access) -based data transmission method and device and electronic equipment
CN112134938B (en) Message processing method, device, terminal and computer readable storage medium
KR20190035592A (en) Distributed Broker Coordinator System and Method in a Distributed Cloud Environment
JP5381242B2 (en) Multiprocessor system and control program
US20210173712A1 (en) Method and supporting node for supporting process scheduling in a cloud system
WO2012071860A1 (en) Synchronization communication method between single-boards of a multiple dwelling unit and multiple dwelling unit thereof
US9588924B2 (en) Hybrid request/response and polling messaging model
CN117076409B (en) File sharing method, device, system, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200327