METHOD FOR INTERPROCESS COMMUNICATION BETWEEN AT LEAST TWO PROCESSES

Description

TECHNICAL FIELD OF THE INVENTION

[0001] The subject of the invention is a method of interprocess communication between at least two processes.

[0002] The technical field of the invention is that of interprocess communication between at least two processes. A process is a coherent set of instructions implemented by a computing unit also called a processor or microprocessor. A coherent set of instructions is, for example, a set of instructions corresponding to a program or an application. The execution of such a program is started, for example, by a command line. A given process corresponds, at the level of the device that implements this process, to a set of resources. In this set of resources there is memory that is private, that is to say accessible only to the process. This memory is allocated to the process by a process scheduler. A process scheduler is also called an operating system.

[0003] The present invention relates to a method which allows, for example, a process A to access data stored in a memory allocated to a process B. In particular, the invention relates to a method implemented by two different devices in order to exchange data from their allocated memories.

[0004] The field of the invention is therefore also that of multi-node IT infrastructures in which it must be possible for processes hosted by different nodes to communicate. TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0005] In the state of the art when a process managed by a computing node of a network wants to communicate with another node of the network, for example to perform a reading action, a rendezvous protocol is used to ensure that both processes are ready.

[0006] This protocol uses the principle of acknowledgment, which consists of a node receiving a first message from a sending node sending a second message to inform the sending node of the successful reception of the first message within a given acknowledgment time. Thus, once the sending node has received the second message, it is certain of the availability of the receiving node and the reading action can be carried out.

[0007] If the sending node does not receive a message within the allotted acknowledgment time, the first message is considered not to have been received and an alert of faulty communication between the two nodes is generated. The problem with this operation is that it does not take into account what the other nodes in the network are doing simultaneously and therefore the possible network congestion which can cause the second message to arrive after the expiration of the acknowledgment time without the communication between the two nodes actually being faulty. If many processes exchange messages simultaneously on the congested network, multiple alerts will then be generated which can lead to a network crash.

[0008] Without going as far as a network crash, this situation degrades the performance of the computing nodes which spend too much time waiting for results from communication actions.

[0009] US 2006 / 277126 A1 relates to an interprocess communication method. SUMMARY OF THE INVENTION

[0010] The invention offers a solution to the problems mentioned above, by making it possible to regulate communications by a self-reservation process which makes it possible to only carry out a communication action when its success is guaranteed while limiting communications on the network.

[0011] One aspect of the invention relates to a method according to claim 1.

[0012] In addition to the characteristics which have just been mentioned in the preceding paragraph, the method according to one aspect of the invention may have one or more additional characteristics among the following, considered individually or according to all technically possible combinations: The update of the token counts is only performed if the business request is successfully processed; The predetermined threshold is zero; The value of the parameter N of the first allocation request is a parameter of the node; A business request is a read request; A business request is a write request; Upon receipt of an allocation request issued by the manager of the first node, the manager of the second node decreases the number of local tokens by the value of the parameter included in the allocation request for the process designated by the request; The resource manager of the second node implements the following steps: Waiting for a notification: If no notification is received then we continue to wait;If a notification is received then for the process designated by the notification the following actions are performed: Reading a number m of tokens, m being the number of tokens available for the process designated as a remote process; Evaluation (2030) of m: If m less than or equal to the predetermined threshold then the notification processing is restarted; If m is strictly greater than the predetermined threshold then, reduction of the number of tokens associated with the process designated by the notification by N, N being the number of tokens requested by the notification, Evaluation of m - N: If m - N is strictly greater than the predetermined threshold then the second resource manager: Issues a response to the notification with the value N as parameter; If m - N is less than or equal to the predetermined threshold then the second resource manager: Issues a response to the notification with the value N' = m as parameter;Increases the number of tokens associated with the process designated as a remote process by N - m. A timeout is performed before restarting the notification processing. ;

[0013] Another aspect of the invention relates to a computer program according to claim 10.

[0014] Another aspect of the invention relates to a recording medium according to claim 11.

[0015] The invention and its various applications will be better understood by reading the following description and examining the accompanying figures. BRIEF DESCRIPTION OF THE FIGURES

[0016] The figures are presented for information purposes only and in no way limit the invention. [ Fig. 1 ] shows a schematic representation of a device implementing the method according to the invention. [ Fig. 2 ] An illustration of steps of the method according to the invention. [ Fig. 3] An illustration of steps implemented by a third-party device to cooperate with the method according to the invention. DETAILED DESCRIPTION

[0017] The figures are presented for information purposes only and in no way limit the invention.

[0018] There figure 1 shows a first node 100. The figure 1 shows that the first node 100 includes: A microprocessor 110 which is also referred to as calculation means; Data storage means 120. This is a schematic representation which groups together transient and non-transient memory. The transient memory is, for example, RAM. The non-transient memory is, for example, a hard disk, an SSD disk or other. These storage means are local or remote depending on the hardware infrastructures on which the invention is implemented. A resource management card 130. The resource management card 130 itself comprises a microprocessor 132, storage means 134 of a type already described and a communication interface 136. The communication interface is, for example, an “Ethernet” interface, a “Fiber Channel” interface, an “InfiniBand” interface or an interface according to another standard used for communications in computing farms.

[0019] There figure 1shows that the storage means of the first node comprise a process area 121. This area comprises instruction codes and working memory corresponding to a first process implemented by the microprocessor 110 of the first node.

[0020] In this description, when an action is assigned to a device, this action is carried out by calculation means of said device implementing instruction codes, also called executable codes, recorded in a storage memory of said device. Similarly, when a device communicates, this means that it sends and / or receives messages via a communication interface. These messages are produced and / or processed by calculation means of said device. Typically, such a message comprises at least one sender identifier and one recipient identifier.

[0021] An action can also be attributed to an application, a process, or software. Application, process, or software means any expression, code, or notation, of a set of instructions intended to cause data to be processed to perform a particular function directly or indirectly (e.g., after a conversion action to other code). Examples of program code may include, but are not limited to, a subroutine, a function, an executable application, source code, object code, a library, and / or any other sequence of instructions designed for execution on a computer system.

[0022] There figure 1shows that the storage means of the resource management card 130 of the first node comprises a resource manager area 135. The resource manager area 135 comprises instruction codes corresponding to the implementation of the method according to the invention and counters which will be described later.

[0023] When the first process sends a message, this message is handled by the resource manager 135 of the resource management card of the first node. In an alternative hardware architecture, the resource manager 135 is implemented by the microprocessor of the first node. In this alternative architecture, the resource management card 130 of the first node is similar to a network interface.

[0024] There figure 1 shows a second node 200. The second node is structurally identical to the first node. The figure 1 shows that the second node has: A microprocessor 210; Data storage means 220; A resource management card 230. The resource management card 230 itself comprises a microprocessor 232, storage means 234 and a communication interface 236.

[0025] There figure 1 shows that the storage means of the first node comprise a process area 221. This area comprises instruction codes and working memory corresponding to a second process implemented by the microprocessor 210 of the second node.

[0026] There figure 1 shows that the storage means of the resource management card 230 of the second node comprises a resource manager area 235. The resource manager area 235 comprises instruction codes corresponding to the implementation of the method according to the invention and counters which will be described later.

[0027] There figure 1 shows a 300 interconnection network. The figure 1 shows that the first node and the second node are connected to the network 300.

[0028] The first node, the second node and the interconnection network 300 belong to a computer not shown. A computer comprises a large number of nodes. Typically this number is several thousand. In practice, the invention applies as soon as there are two nodes and has no upper limit.

[0029] There figure 2 shows a step 1000 of emission by the first process, to the resource manager of the first node, of a business request intended for the second process.

[0030] When we say that a process issues a request to a resource manager intended for a second process on a second node, this can be implemented in at least two ways: The request is actually sent to the resource manager; the request is intercepted, transparently for the sending process, by the resource manager.

[0031] A business request is, for example, a request to read a memory area belonging to another process, or a request to write a memory area belonging to another process. We can extend the notion of reading to the invocation of a function implemented by another process, in this case it is a question of asking this other process to carry out a processing and returning in response the result of said processing.

[0032] In the example described, the business request is considered a read request. In this example, the business request includes at least one remote process identifier.

[0033] There figure 2shows a step 1010 of reception and verification of a business request by the resource manager. In step 1010 the resource manager of the first node performs a verification 1020 in which it checks whether there is at least one token associated with the recipient process of the read request. Here the recipient process is the second process.

[0034] The resource manager area 135 of the resource management card 130 of the first node comprises at least a first token counter. Generally speaking, in this description, a token counter is the association of a process identifier and a number. For the sake of brevity, we refer to it as a counter. The process identifier makes it possible to identify the process and the node that executes it. It is therefore possible to know whether the process is local to the node or remote. The number corresponds to a number of requests that can still be processed by the process identified by the identifier. Each token corresponds to a request. A token is added by increasing the counter by one. A token is removed by decreasing the counter by one.

[0035] If there is a token associated with the second process, that is, if the number of tokens is strictly greater than zero, then the resource manager moves on to a step 1030 of sending the request to the second process.

[0036] In a next step the business request is received by the resource manager of the second node. The second resource manager performs the following actions: Forwarding the request to the second process; Receiving the response from the second process to the request; Increasing 1040 by one (+1) a counter associated with the second process at the second resource manager; Sending the response to the business request to the resource manager of the first node.

[0037] In a next step, the resource manager of the first node receives the response to the business request. The resource manager of the first node then performs the following actions: Transmitting the response to the first process; Decreased 1050 by one (-1) the counter associated with the second process at the resource manager of the first node.

[0038] Note that it is possible for resource managers to have access to the memory allocated to processes. In this case, the resource manager does not need to communicate with the process to perform a read action; it can do it itself and therefore respond to the business request.

[0039] It is also noted that in a variant of the invention the increase by one (+1) of the counter associated with the second process at the level of the second resource manager is controlled by the resource manager of the first node. In this variant the resource manager of the first node sends to the resource manager of the second node a request to increase by one the counter associated with the second process at the level of the second manager at the moment when it decreases by one the counter associated with the second process at the level of the resource manager of the first node. Therefore the order of execution of steps 1040 and 1050 depends on the chosen implementation mode and the availability of the resource managers. Indeed they carry out their actions in parallel.

[0040] If there is no local token then the resource manager of the first node proceeds to a step 1060 of sending, to the resource manager of the second node, a first request for allocation of tokens associated with the second process. This first allocation request includes at least one parameter N, where N is the number of tokens for which allocation is desired.

[0041] N is a parameter of the method according to the invention which is fixed at the time of starting the calculator. In a classic implementation N is of the order of a few units or even included in the interval [2, 10].

[0042] There figure 2shows a step 1070 of reception and processing, by the resource manager of the second node, of a request for allocation of tokens for a process. The resource manager of the second node responds to this request by returning the value of a reading of the counter associated with the process designated by the allocation request at the level of the second node. Once this reading has been carried out, the resource manager of the second node decreases said counter by the number of tokens N requested by the allocation request.

[0043] There figure 2shows a step 1080 of reception, by the resource manager of the first node, of a response to the first allocation request. The response includes a parameter M representing the number of remote tokens associated with the second process before the reception of the allocation request. In other words M is the value of the counter associated with the second process at the resource manager of the second node at the time of reception of the first allocation request.

[0044] The resource manager of the first node then moves on to a step of evaluating M - N, that is, the difference between the number of tokens available and the number of tokens requested. In particular, we test whether this difference is greater than or equal to a predetermined threshold. In our example, this threshold is zero (0).

[0045] If the difference is greater than or equal to the threshold, then the resource manager of the first node moves to a step 1100 of increasing by N the number of tokens associated with the second process at the first node. It then becomes possible again for processes hosted by the first node to issue requests to the second process, and the resource manager of the first node returns to the start of the verification step 1010.

[0046] If the difference is less than the threshold, then, in a step 1110 of evaluating M, the resource manager of the first node evaluates the value of M.

[0047] If M is greater than the predetermined value, zero in our example, then the resource manager of the first node performs the following actions: Sending (1120) a second allocation request, for the second process to the resource manager of the second node, with a parameter equal to M - N. The resource manager of the second node then increases the counter of the second process by N - M, a counter which had been decremented by N in step 1070; Increasing (1130) the number of tokens associated with the second process at the resource manager of the first node by M; Returning to the start of verification step 1010.

[0048] If M is less than or equal to the predetermined value, zero in our example, then the resource manager of the first node performs the following actions: Sending 1140, to the resource manager of the second node, a third allocation request for the second process, with a parameter having the value -N. The resource manager of the second node then increases the counter of the second process by N, a counter which had been decremented by N in step 1070; ; Sending 1150, to the resource manager of the second node, a notification designating the second process with a parameter having the value N; Places itself 1160 in a state of waiting for a response to the notification; Receives 1170 a response to the notification, this response comprising a parameter N'. It then increases the number of tokens associated with the second process at the first node manager by N' and then returns to the start of the verification step 1010. N' can be equal to or different from N.

[0049] Just because the first resource manager goes into a waiting state does not mean it is blocked. It continues to process requests from other processes and other node managers.

[0050] The term notification is used for clarity to refer to a request that is not an allocation request although it has the same structure, namely that it designates a process and has an expected number of tokens.

[0051] There figure 3shows a step 2000, implemented by the resource manager of the second node in which it is waiting for a notification such as the one previously described. If no notification is received then the resource manager of the second node continues to perform its tasks, one of which is to wait for notifications. If a notification is received then it moves on to a step 2010 of reading the notification parameters. In the example the resource manager of the second node receives a notification designating the second process and requesting N tokens. Once these parameters have been read, it moves on to the next step 2020.

[0052] In step 2020 the resource manager of the second node reads the value of the counter associated, at the resource manager of the second node, with the process designated in the notification. This value is here called m. The resource manager of the second node then moves on to a step 2030 of evaluating m.

[0053] In the step of evaluating m, if m is less than or equal to the predetermined threshold, zero in our example, then the resource manager of the second node returns to the start of processing the notification. Otherwise, the resource manager of the second node moves on to a step 2040 of reducing the counter corresponding to the process designated by the notification. This counter is decreased by N and then the resource manager of the second node moves on to a step 2050 of evaluating m - N.

[0054] If m - N is strictly greater than the predetermined threshold, in our example zero, then the resource manager of the second node performs the following actions: Issue (2060) a response to the notification with a parameter having the value N.

[0055] If m - N is less than or equal to the predetermined threshold, in our example zero, then the resource manager of the second node performs the following actions: Issue (2070) a response to the notification with a parameter having the value m; Increase (2080) the number of tokens associated with the process designated by the notification at the resource manager of the second node by N - m.

[0056] We note that the steps for processing the notification by the resource manager of the second node are modeled on those implemented by the resource manager of the first node for managing the business request. In practice, we could do otherwise. The principle is to allocate the maximum possible resources, this maximum being between 1 and N, N being the number of tokens requested by the notification.

[0057] The method according to the invention makes it possible to authorize operations only when the second process has available resources and to limit the number of operations per process to limit network congestion.

[0058] Using a notification when no resources are available rather than repeating the reservation steps until the process has available resources limits the number of messages exchanged in the network. Since the notification has no acknowledgment mechanism, no alert is generated for network congestion reasons, which limits computer crashes.

Claims

1. A method for interprocess communication between at least two processes, each process being hosted by a node on a communication network, each process being assigned at least one private memory, a node further hosting a process including a resource manager, characterised in that a resource manager comprises at least one resource counter for a target process of a communication, the method according to the invention comprising at least the following steps of: - Emitting (1000) by a first process of a first node, to the resource manager of the first node, a specification request intended for a second process of a second node, the specification request being a request to perform processing on the at least one private memory of the second process by the second process and to return the result of said processing in response; - Verifying (1010), by the manager of the first node, that there is at least one token associated with the second process locally: ∘ If there is (1020-OK) a local token, then:

1. The specification request is transmitted (1030) to the second process; 2. The number of local tokens associated with the second process is decreased (1050) by one by the resource manager of the first node; 3. The number of remote tokens associated with the second process is increased (1040) by one by the resource manager of the second node; ∘ If there is no local token (1020-KO):

1. Emitting (1060), by the manager of the first node, a first request for allocation of tokens associated with the second process to the manager of the second node, the first allocation request including a parameter N representing the number of tokens requested; 2. Receiving (1080), by the manager of the first node, a response to the first allocation request, the response including a parameter M representing the number of remote tokens associated with the second process before receiving the first allocation request; 3. Evaluating (1090) the value of M - N: a. If it is greater than or equal to a predetermined threshold (1090-OK), then the manager of the first node increases (1100) the number of local tokens associated with the second process by N and returns to the verification step (1010); b. If it is less than the predetermined threshold (1090-KO), then evaluating (1110) the value of M: i. If it is greater than the predetermined threshold (1110-OK), then the manager of the first node transmits (1120) a second allocation request with a parameter having a value of M - N, increases (1130) the number of local tokens by M, and returns to the verification step (1010); ii. If it is less than or equal to the predetermined threshold (1110-KO), then the manager of the first node:

1. Transmits (1140) a third allocation request for the second process to the manager of the second node with a parameter having a value of -N, 2. Transmits (1150) a notification to the manager of the second node, without an acknowledgement mechanism, specifying that it is waiting for N tokens for the second process; 3. Enters (1160) a condition of waiting for a response to the notification; 4. When it receives (1170) a response to the notification, which includes a parameter N' representing the number of tokens allocated, the manager of the first node increases the number of local tokens associated with the second process by N' and returns to the verification step (1010).

2. The interprocess communication method according to the preceding claim, characterised in that updating the numbers of tokens (1040, 1050) is performed only if the specification request is successfully processed.

3. The interprocess communication method according to the preceding claim, characterised in that the predetermined threshold is zero.

4. The interprocess communication method according to one of the preceding claims, characterised in that the value of parameter N of the first allocation request is a node parameter.

5. The interprocess communication method according to one of the preceding claims, characterised in that a specification request is a read request.

6. The interprocess communication method according to one of claims 1 to 4, characterised in that a specification request is a write request.

7. The interprocess communication method according to one of the preceding claims, characterised in that, upon receiving an allocation request transmitted by the manager of the first node, the manager of the second node decreases the number of local tokens by the value of the parameter included in the allocation request for the process designated by the request.

8. The interprocess communication method according to one of the preceding claims, characterised in that the resource manager of the second node implements the following steps of: - Waiting (2000) for a notification: ∘ If no notification is received, then continuing (2000) to wait; ∘ If a notification is received, then for the process designated (2010) by the notification, the following actions are performed:

1. Reading (2020) a number m of tokens, where m is the number of tokens available for the process designated as the remote process; 2. Evaluating (2030) m: a. If m is less than or equal to the predetermined threshold (2030-KO), then restarting processing (2010) of the notification; b. If m is strictly greater than the predetermined threshold (2030-OK), then reducing (2040) the number of tokens associated with the process designated by the notification by N, N being the number of tokens requested by the notification, c. Evaluating m - N: i. If m - N is strictly greater than the predetermined threshold (2050-OK), then the second resource manager:

1. Transmits (2060) a response to the notification with the value N as a parameter; ii. If m - N is less than or equal to the predetermined threshold, then the second resource manager (2050-KO):

1. Transmits a response to the notification with the value N' = m as the parameter; 2. Increases the number of tokens associated with the process designated as a remote process by N - m.

9. The interprocess communication method according to claim 8, characterised in that a time delay is observed before restarting processing of the notification.

10. A computer program for performing interprocess communications, able to, preferably configured to, implement an interprocess communication method according to one of claims 1 to 9.

11. A recording medium having a computer program for performing interprocess communication according to claim 10 recorded thereon.