NL1025169C2 - Process mobility protocol. - Google Patents

Description

Process mobility protocol

This invention relates to mobile processing techniques and can in particular be applied to real-time systems.

5 Mobile processing means: the migration of processes from a source node (for example a machine) to a target node The migration does not actually take place, but is simulated: a new process is created at the target node and, after the context of the process on the source node is copied, the process on the source node 10 is aborted. However, the net effect is that the processing of a quantity of data has been moved from source to target node.

A process performed on a node is called an "incarnation." The process at the source node is the "old incarnation". The process at the target node is called the "new incarnation".

The requirements for process migration are that the current state of the process on the source node can be transferred to the target node, such that the new incarnation on the target node can continue processing. This means that not only must the process be copied at the target node, but a snapshot of its current content must also be installed. Then the new incarnation of the process must be brought to the same status as the old incarnation. Finally, the old incarnation must be aborted, while the new incarnation is turned on to continue from the point where the old incarnation was stopped.

An operating system (OS) keeps track of the status and context of every process that is in progress and performs scheduling tasks. However, the tasks of an OS do not include moving a process from node to node. After all, OS and are hardware oriented. The notation, in particular, of context and status differs per OS. OSs of the same brand but of a different release, or even OSs of the same brand and of the same release but intended for different hardware systems' 25169 2 can have essential differences. In other words, OS and lack the ability to collaborate and code transfer that is required to implement mobile processing between different systems.

5

Conventional mobile processing systems, such as those used in agent-based systems, require a so-called virtual machine (VM) for implementing process mobility. The VM is a translator, which supplies an instruction set, a set of registers, a collected garbage heap and a memory that can be used for the process. The VM interprets the code of the processes and thus manages the status and context for these processes. The VM also controls the execution of the processes. It is relatively easy to freeze and transport the status and context of a process in such cases. In other words, the use of virtual machines makes process mobility possible between different OSs.

There are, however, major drawbacks. In particular, the service package of a VM is limited in comparison with the services that the OS itself provide. The 20 processes, in other words, are tied to the services that theVM offers. For example, VMs only provide one specific form of shared memory or have no shared memory at all. Moreover, since the VMs use an abstraction layer, they also perform their own scheduling, threading, etc. Therefore, scheduling, threading and 25 real-time behavior at process level are not supported. Finally, the inter-process communication (IPC) is usually not supported by the VMs.

Another disadvantage is that the use of a VM requires processes to be tuned to it (for example, JAVA VM, JADE platform ...).

30 As a result, mobility is limited to processes on the VM and other (capable of collaborating) VMs at different nodes.

There are even more disadvantages: - a VM is not suitable for time and safety-critical systems, 35 - a VM is not suitable for real-time systems, 025169 '3 - the main resources of a node are difficult to reach from the VM.

As is apparent from the features described below and in the claims, the invention is intended to eliminate the above disadvantages. In particular, the invention is directed to safely move a process between different nodes (e.g., different machines with different OSs), without the limitations of a VM.

In order to achieve this goal and also to realize other advantages, which will be explained below, the invention specifically provides a method for promoting process mobility. The invention is implemented in portal processes, so-called gateways. According to a feature of the invention, the gateways transport the mobile process context (the old incarnation) from one to the further node. To this end, the process gateways ensure, at different nodes, equivalent processes that can easily access the resources of the node and whose context is tailored to the hardware and OS of the node. The process gateways are involved in the exchange of the necessary context information to reconstruct an equivalent context for the new incarnation.

More in particular, it is an object of the invention to realize a method for moving a process from a source node to a target node, wherein: - an old incarnation of the process (3) in progress on the source node , stores its own context in a frame (13); - a new incarnation of the process (4) is started at the target node, which new incarnation (4) has the status "ready"; - a direct communication (21) is established between the old incarnation (3) and the new incarnation (4) of the process, in which the stored context is sent from the old incarnation to the new incarnation; 251 69 4 - the new incarnation with processing begins (24), using the received context.

The main advantages of the invention are that the processes can easily gain access to system resources and other processes, that the process mobility method can comply with the safety and protection constraints and that cooperation is possible in a hybrid network.

The method according to the invention can be used to keep the workload in a system balanced. After all, processes entail a workload at the node at which they are executed and too much load at a node can hinder the execution of the processes, in particular when there are time-critical processes. Mobile processing is a way to keep the load in balance by transferring processes from overloaded nodes to nodes with sufficient capacity and low load.

In a favorable embodiment, the old incarnation regularly saves its own context at predetermined synchronization points, which context is wrapped in a frame after receiving a signal from a source gateway.

In another favorable embodiment, the context contains the contents of the memory and the status of the process.

in another favorable embodiment, the new incarnation is started after receiving a signal from the target gateway.

In another favorable embodiment, the signal for the start of the new incarnation is sent after receiving a signal from the source gateway.

251 69 5

In another favorable embodiment, the direct communication is established by means of a socket, the port number of which: - is sent to the target gateway by the new incarnation, and subsequently - is sent by the target gateway to the source gateway. gateway, and then - is sent by the source gateway to the old incarnation.

In another favorable embodiment, the old and new incarnations are multi-threaded processes.

In another favorable embodiment, each thread of the old incarnation stores its own context, one of these threads being a main thread and the stored contexts being packed into a single frame by the main thread.

The invention will now be described in a more detailed manner, with reference to a special embodiment 20 as an example. In this description, reference will be made to the attached Images, of which: - Figure 1 is a time diagram of an example of the implementation of a process mobility method according to the invention; - Images 2a and 2d are time diagrams of an example of an implementation of a multi-threaded variation of the method.

Consider first Figure 1. According to the invention, synchronization points are added to the mobile processes. A synchronization point 5 is a step in which the process (old incarnation) 30 stores information, such as the contents of its memory and its status. This information is comparable to the information stored by a debugger that generates a core dump file.

To execute the process mobility method, the gateway process 1 in progress sends a "move" 125169 signal 6 at the source node to the process 3 (old incarnation) that is in progress at its node. For the sake of clarity, the gateway process 1 in progress at the source node is referred to as the source gateway.

The source gateway 1 also sends a "start process" signal 8 to the gateway process 2 that is in progress at the target node. For the sake of clarity, the gateway process 2 in progress at the target node is referred to as the target gateway. For example, the "move" signal 6 and the "start process" signal 8 can be realized by means of interruptions 10. The "move" signal 6 can be sent after or before the "start process" signal 8. The "move" signal 6 can be an Interrupt. The "start process" signal 8 will most likely be cast in the form of a message containing specific information (path, arguments, environment) of the process to be started.

15

The "move" signal 6 initiates steps 7, 13 and 14, which are performed by the old incarnation to construct a frame. Specifically, when the old incarnation 3 receives the "move" signal 6, it enters a wait state 7. All operations performed between the last synchronization point 5 and the reception of the "move" signal 7 are lost. a step 13, the so-called context wrapping, constructing a frame containing the information stored at the last synchronization point At the end of the context wrapping 13, the process sends an "end" signal 14 to the source gateway 1, to indicate that it has finished packing the context 13. This "end" signal is then passed on from the source gateway 1 to the target gateway 2 by means of a "hold" signal 15. According to another implementation (not shown), the "hoid" signal 15 is sent directly to the target gateway through the old incarnation.

The "start process" signal 8 is a request to start an identical process 4 at the target node. However, this new process 4 (new incarnation) starts at zero. The target gateway 2 can deposit the new incarnation (9) by, for example, using the Fork / Exec instruction in Unix. When 25169-7 starts the new incarnation, it performs a registration 10 via the OS. This registration tells the OS that the new process is one of the new incarnation type. In other words, the new incarnation appears as a mobile. The registration involves a local interaction with the target (local) 5 gateway.

The registration of the new incarnation comprises, for example, the following steps: 1. Installation of packing functions.

10 2. Installation of recovery functions.

3. Installation of unpacking functions.

The wrapping functions are the functions used for wrapping the context.

15

The recovery functions are entry points that enable the process to take on execution from a given process status. This given process status is the process status stored at a predetermined synchronization point (e.g. synchronization point 5).

20

The unpacking functions perform the reverse operation of the packing functions. From a packed context, they construct a useful process duration context. The unpacking functions are used if the process turns out to be a new incarnation.

25

To perform the installation of the packing / repair / unpacking functions, the locations of the functions for the process are stored in, for example, a jump table.

According to a preferred embodiment, the functions installed during the recording step 10 are handlers. A handler is a function that the OS invokes in specific events, such as an exception X or a signal Y. If the exception X occurs or the signal Y is sent to the process, the OS immediately interrupts the execution of the process and calls the appropriate handler. The installation 125169 8 of a handler usually takes the form of a system call, which overrides the OS's default bandier.

Because this embodiment uses low-level interrupts (signals) for inter-process communication and synchronization, the invention can handle real-time scheduling issues. These low-level interrupts can only be generated at the level of a host (i.e., at the local node) and not at the level of a network.

In some OSs, handlers are "volatile," meaning that the OS re-installs the default handler prior to calling the handler. This can be undone by reinstalling a user-defined handler for, for example, signal Y when closing the handler function for signal Y.

15

During registration 10, the new incarnation can also send a message to the target gateway to inform that gateway that the process is mobile. After receiving the message with the information that the process is mobile, the local gateway sends a response. The answer can be a confirmation, or a token that marks the process as a new incarnation. According to another embodiment, the process can deduce the fact that there is a new incarnation from a flag in its context set up during the start 9 action. In other words, the process does not receive this information from the gateway: instead, it checks its context.

Regardless of the algorithm, at the end of registration 10, the process will know whether or not there is a new incarnation of a migrating process (identified by a confirmation from the gateway 30 or a flag in its context). If a process is not a new incarnation, it starts a normal execution. If the process turns out to be a new incarnation, it goes to a preparation step 11.

During the preparation step 11, the new incarnation 4 prepares for receiving the packed context (frame generated 151 69 9 by the old incarnation). Part of the preparation step 11 is that the new incarnation requests the OS for a socket (means of communication).

The preparation step 11 comprises, for example, the following 5 steps: 1. The new incarnation requests a socket, using system calls made available by the OS.

2. The new incarnation sends the port number of the assigned socket to the target gateway in a message.

3. The new incarnation goes to a hold loop, waits for a "listen *" signal 16 and then starts listening through the assigned socket.

According to another embodiment, the new incarnation does not go to a hold loop, but starts listening immediately after having sent the message (port number) to the target gateway.

When the new incarnation has finished recording 10 and preparation step 11, it sends a "hold" signal 12 back to the target gateway 2. This "hold" signal 12 indicates that the new incarnation has the status 20 "ready" and wait for communication to be established. This "hold" signal 12 may contain the address of the socket required by the new incarnation.

The target gateway 2 waits for both "hold" signals 12 and 15. When both signals are received, the target gateway 2 sends the "listen ** signal 16" to the new incarnation. The new incarnation is then in a listening mode 17. The target gateway 2 also sends a "start broadcast" signal 18 to the source gateway. The "start broadcast" signal 18 may contain the address of the socket required by the new incarnation The "start 30 broadcast" signal 18 is transmitted by the source gateway 1 to the old incarnation by means of a "send" signal 19. This "send" signal 19 can be used to send the address of the socket.

According to a preferred embodiment, the old incarnation, after termination of the context packing 13, enters a holding loop in which it continues to request the source gateway for the port number of the assigned socket. Each request is passed on to the target gateway by the source gateway. When the new incarnation has succeeded in getting the request for a socket granted and notifying the target gateway, the target gateway will respond by sending the correct port number to the source gateway. In turn, the source gateway will respond to the request of the old incarnation by issuing this port number. The port number can be included in the "send" signal 19. The "send" signal can also be the port number itself. If the new incarnation has not yet finished asking for a socket and notifying the target gateway, the target gateway responds with a special "not yet ready" response to the source gateway, which will provide the same answer give to the old incarnation This "not ready" answer again initiates an iteration of the holding loop of the old incarnation.

15

After receiving the port number, the old incarnation 3 is in a transmitting mode and uses the socket requested by the new incarnation to establish a direct communication 21 with the new incarnation. During this communication 21, the packed context 20 is sent (formatted transmission). When the context is sent, the new incarnation sends a "ready" signal 22 to the target gateway.

For example, a proprietary library can provide the means for packing the context 13 and sending and receiving the packed context 21. The format is not important.

After receiving the "ready" signal 22, the target gateway sends a "go through" signal 23 to the new incarnation and a "ready" signal 25 to the old incarnation. The "continue" signal 23 causes the new incarnation to begin processing, using the information sent in the packed context. In other words, the new incarnation resumes processing at the last synchronization point 7 of the old incarnation.

251 69 11

The new incarnation has synchronization points, such as point 28, which enable them to move to another node again by the same method.

The "ready" signal 25 is passed through the source gateway to the old incarnation by means of a "break off signal 26. This" break off signal stops the execution 27 of the old incarnation. The "abort signal" initiates a termination function in the old incarnation, allowing it to perform a number of deregistration activities in a controlled manner, release a number of system resources, etc.

According to another embodiment, the old incarnation can be stopped by a cancellation signal from the OS. A controlled type of termination (i.e., with a termination function) is preferable to such a forced termination. The old incarnation may after all still be connected to a number of similar elements in the distributed environment, may be in possession of a number of handles, etc. since it was interrupted in the middle of the work (at the last synchronization point for the "move" signal 6 ).

20

Reference is now made to Figure 2a, in which the method described in relation to Figure 1 is adapted to a multi-threaded process. In this example of an implementation, each thread logs on individually and packs and unpacks its own context.

25

The source gateway sends "move" signal 6 to main thread 3a. When the main thread 3a receives the "move" signal 6, it interrupts the sub-threads 3b and 3c and also interrupts itself. All threads are then in a waiting state, meaning that all acquisition activities have been stopped. Each thread 3a, 3b, 3c of the old incarnation has its own synchronization point 5a, 5b, 5c All processing carried out between each synchronization point and the reception of the "move" signal 6 are lost.

ï 51 69 12

Each thread then wraps its own context. Specifically, each sub-thread 3b, 3c packs its own local context 13b, 13c and closes (stops executing) 27b, 27c. The main thread wraps its own local context 13a and wraps the global context of the old incarnation. The global context 5 can be, for example, a sequence of the packed contexts 13b, 13c, 13a, as illustrated in Figure 2a. When the wrapping of the (global) context is complete, the main thread sends an "end" signal 14 to the source gateway to indicate that the wrapping of the global context is ready. As previously described, the "end" signal is then passed to the target gateway by means of a "hold" signal 15.

According to a preferred embodiment, there are two types of unpacking function: a main thread unpacking function and a sub-thread unpacking function. The main-thread unpacking function is used to extract the context for the main thread (which may fork out into sub-threads; a single-threaded process only has a main thread). The sub-thread extract function unpacks the packed context for a sub-thread.

In the same way as with the single-threaded process, the source gateway also sends a "start process" signal 8 to the target gateway 2. This "start process" signal 8 is a request to start a process 4a at the target node . The process 4a initially has only one thread, which will become the main thread when the other thread starts. The thread 4a performs a registration 10 and preparation 11, as described above. The thread 4a then sends a "hold" signal 12 to the target gateway. When the "hold" signals from the source gateway 1 and the thread 4a have been received, the target gateway 2 sends a "listen" signal to the thread 4a (new incarnation). The thread 4a is then in a listening mode. The target gateway 2 also sends a "start broadcast" signal 18 to the source gateway, which is passed on to the remaining (main) thread 3a of the old incarnation.

Reference is now made to Figure 2b, which shows the steps which the exemplary implementation of the method goes through. The "start broadcast" signal 18 is passed through the source gateway to the remaining thread 3a by means of a "send" signal 19. A direct communication 21 is then established between the remaining thread 3a of the old incarnation and the first 5 thread 4a of the new incarnation.

Each time the first thread 4a receives the context of a sub-thread, the first thread 4a starts a sub-thread with the received context. The sub-threads 4b, 4c are in a hold state. When the global context is sent, the main thread 4a of the new incarnation sends a "ready" signal 22 to the target gateway.

After receiving the "ready" signal 22, the target gateway sends a "continue" signal 23 to the main thread of the new incarnation and a "ready" signal 25 to the remaining thread of the old incarnation. continue "signal 23 causes threads 4a, 4b, 4c to start. After all, the threads are classified by the OS. Then, each thread has its own synchronization point 28a, 28b, 28c during the execution period.

The "ready" signal 25 is passed from the source gateway to the remaining thread 3a of the old incarnation by means of a "break off signal 26. This" break off signal stops the execution activities of the remaining thread 3a, ie, the the execution of the old incarnation stops.

25

Although the special implementations described have particularly favorable properties, they do not cover all possibilities. A variety of alternative implementations are possible. Those alternatives remain within the scope of the invention covered by the patent.

30

For example, it is possible to use message exchange instead of interruptions to send the relevant signals. However, the "move" signal 6 must be an interruption to prevent the move activities from being hampered by recursion.

1251 69

Claims (8)

A method for moving a process from a source node to a target node, wherein: - an old incarnation of the process (3) in progress on the source node stores its own context in a frame (13); 5. a new incarnation of the process (4) is started at the target node, which new incarnation has the status "ready", - direct communication (21) is established between the old incarnation (3) and the new incarnation ( 4) of the process in which the stored context is sent from the old incarnation to the new incarnation - the new incarnation begins processing (24) using the received context. A process relocation method according to the preceding claim, wherein the old incarnation (3) regularly stores its own context at predetermined synchronization points (5), which context is packed after receiving a signal (6) from a source gateway (1) in a frame (13). A process relocation method according to any of the preceding claims, wherein the context contains the contents of the memory and the status of the process. 4. A process displacement method according to any one of the preceding claims, wherein the new incarnation (4) is started after receiving a signal (9) from a target gateway (2). A process displacement method according to the preceding claim, wherein the signal (9) for starting the new incarnation is sent after receiving a signal (8) from the source gateway (1). 30 A process relocation method according to any of the preceding claims, wherein the direct communication (21) is established by means of a socket, the port number of which: 251 69 - is sent (12) by the new incarnation to the target gateway, and then - sent (18) through the target gateway to the source gateway, and then 5. sent through the source gateway (19) to the old incarnation. A process relocation method according to any of the preceding claims, wherein the old and new incarnations are multi-threaded processes. 10 A process relocation method according to the preceding claim, wherein each thread (3a, 3b, 3c) of the old incarnation stores its own context, one (3a) of these threads being a main thread and the stored contexts being saved by the main thread (3a) be packed in a single frame. 251 69