JP2002505050A - Asynchronous message processing system and method - Google Patents

Abstract

(57) [Summary] An asynchronous message processing system and method are provided in which a process is defined by a state and a type. Input messages received at a network node are stored in an input message queue and processed according to the order in which they arrived. Also, the outgoing messages are stored in an outgoing message queue and forwarded to the destination network node in the order in which they were created. Input messages addressed to a process are processed by calling specific message processing application code that completes processing and modifies the process state. Modifying the process state is the smallest unit in the sense that it occurs completely or not at all, and does not partially modify the process state.

Description

Description: FIELD OF THE INVENTION The present invention relates to a distributed asynchronous message processing system and method. BACKGROUND OF THE INVENTION Various models of communication processing for specification and implementation of distributed systems have become popular. Most well-known systems are remote from the ADA rendezvous mechanism, just as they are based on a synchronous model of communication in which the source also suspends until the suspended destination responds. Moving to procedure call. Such a system has significant advantages in practice. Because procedure calls can hide telecommunications, existing local applications can be turned into distributed applications with minimal impact. However, in intrinsic distributed reactive or command and control systems, the synchronization model has several problems. Any system that waits for a specific event and processes back is prone to communication deadlock. In general, since such a deadlock occurs depending on the state of the entire system, an extremely simplified system (ie, a fixed number of finite state machines having only a few states and accurate communication patterns) ) Can only be analyzed. While tightly organizing communications into a client / server hierarchy can avoid deadlocks, it results in a clumsy organization where active objects (ie, spontaneous message sources) cannot communicate directly with each other. Tends to. In particular, peer protocol processing and handling of exceptions and failure conditions are problematic because they involve message flows in the opposite direction to normal communication patterns. After all, even with a high-speed Reduced Instruction Set Computer (RISC), command and control is not possible because of the simple state transitions caused by arriving messages and the short message transmission time. Adjusting the bulk of the system requires milliseconds of CPU time. Delays between distant nodes on the network are measured in milliseconds, and round trip times are often tens of milliseconds. The ratio between the message transmission time between distant nodes and the local message processing time is called the "time constant ratio". The time constant ratio in the above time interval is approximately 10 ^Three -10 ^Four Which is already extremely high. The round trip time is dominated by the propagation delay, but does not decrease since it depends essentially on the speed of light. Thus, as the global network grows further, it will increase by an additional factor of 10. However, processing and transmission times can be expected to decrease by at least a factor of 10 in the next few years. As a result, the index of the time constant ratio is 10 ^Five To a degree. Temporal ratio is a critical parameter that characterizes a distributed system. From daily personal experience, it would be preferable to spend 5 seconds of a telephone call in order to have a 5 minute conversation (time-ratio r in this case is 1/60), but if the call takes 5 minutes (That is, the time constant r is 1), it will be distorted. Furthermore, if the user waits for 5 minutes for a conversation for 5 seconds, the person becomes naturally angry (time constant ratio r is 60). When the time constant ratio r exceeds 1, it means that the waiting process is suspended. If the cost of a context switch is not too high, it will do something else. Thus, a high time constant r can make one think about how many "threads" are needed to keep the processor busy. In the current worlds of local area networks (LANs) and personal computers (PCs), distributed applications (typically having a time constant r of 10 to 100) are slightly running, and a synchronous communication model can be executed. It is. However, the time constant r is 1000, and the time constant r alone is 10 ⁶ That is no longer appropriate. One problem is that the suspension must save execution of the stack, so that in the worst case enough processes or threads must be allocated enough stack space. Thus, the stack area typically ranges from 10 kilobytes to 1 megabyte. In a system in which a relatively large number of "objects" occur simultaneously, depending on the size of the time constant r, excessive or infeasible memory requests may be caused. A second problem is that in current applications, the overhead due to suspension itself is longer than typical transition times. SUMMARY OF THE INVENTION It is an object of the present invention to obviate or mitigate the above-mentioned disadvantages. A first aspect of the present invention is a method for asynchronous message processing in a network node having a processor and a memory, the method comprising a plurality of application codes associated with a process state and identifiable by a pid (process identifier). Maintaining a process in memory for each message received by the processor, wherein the processor is addressed to any of the plurality of processes based on a destination pid that forms part of the message. And process the message as a function of the process state of the destination process by executing the application code associated with the destination pid, changing the process state of the destination process if necessary, and during that time the application task Send if necessary Generating a message, it is an asynchronous message processing method characterized by comprising the steps of: said node forwards the outgoing message. According to a second aspect of the present invention, there is provided a network node for connecting to a digital network. The network node receives an incoming message, stores the received message in an input message queue, and outputs an outgoing message. An interface to the digital network for reading and transferring from the queue, and maintaining in memory a plurality of processes consisting of application code associated with the process state and identifiable by a pid (process identifier); Reading out the messages from the input message queue one at a time in the order in which they were received, and to which of the plurality of processes the message is addressed based on the destination pid that forms part of the message Is determined and associated with the destination pid. The application code to process the message as a function of the process state of the destination process, change the process state of the destination process if necessary, and if necessary, A processor for writing the outgoing message to the buffer location. A third aspect of the present invention is a digital network including a plurality of network nodes, each of which receives an incoming message and stores it in an input message queue. An interface with a digital network for reading and transmitting a message to be sent from an output message queue, and a plurality of processes that can be identified by a pid (process identifier) consisting of application code related to a process state. Maintaining in memory and reading messages from the input message queue one at a time in the order in which they were received, and for any of the plurality of processes based on the destination pid that forms part of the message. Determine if the message is addressed Executing the application code associated with the destination pid to process the message as a function of the process state of the destination process, changing the process state of the destination process if necessary, and And a processor for writing the outgoing message to the next available buffer location in the queue. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic block diagram of a network according to the present embodiment. FIG. 2 is a block diagram of one node on the network shown in FIG. FIG. 3 is a diagram showing an overall flow of a message in a node according to the embodiment of the present invention. FIG. 4 is a diagram illustrating a shared input buffer ring. FIG. 5 is a diagram showing a typical message syntax. FIG. 6 shows a summary of the kernel data structure and the status registers. FIG. 7 is a diagram showing a cancellation log (trail) mechanism. FIG. 8 is a flowchart showing a kernel loop. Detailed Description of the Preferred Embodiment FIG. 1 shows a network context implementing a system and method according to an embodiment of the present invention. The network context is made up of a plurality of processing nodes 10 interconnected by a digital communication network 20. Communication network 20 may be a local area network, a wide area network, or a global network. The network 20 shall be capable of transmitting digital messages between any processing nodes 10 up to a reasonable maximum size. The network 20 may be either connection-oriented or connectionless media, but preferably has a reasonably low rate of message loss, data corruption, or delivery failure. By using lower layer protocols, many communication technologies can be utilized or applied in the implementation of the present invention. However, as a representative specific example, in this embodiment, it is assumed that a single cell ATM (asynchronous transfer mode) is used. In this case, a single virtual channel exists in each direction between each pair of nodes 10, and a table that maps node identifiers to local virtual channel identifiers exists for each node. Suppose. Further, it is assumed that the quality of service provided is sufficiently low that message corruption will occur such that no upper layer protocol is required. Node structure FIG. 2 illustrates the structure of each node 10. As shown, node 10 has at least access to a high speed local bus 30, a processor or CPU 32, some shared random access memory 34, and a communication network 20 (see FIG. 1). And an intelligent communication adapter 36 to be provided. The communication adapter 36 and the bus 30 are configured to enable direct memory access (DMA) between the communication adapter 36 and a message buffer in the shared memory 34. It is also assumed that the message buffer is visible from the processor 32. In a preferred embodiment of the present invention, normal communication between the processor 32 and the communication adapter 36 shall only occur via the shared memory 34, except under possible exceptional conditions. No interrupt is generated. In addition to the virtual channel between each pair of nodes, each node has a "loop back" channel for itself, and a node can send messages to itself. Such a loop back channel may be implemented in communication adapter 36, emulated in processor 32, or over a communication network. Each processor executes the runtime environment according to the embodiment of the present invention and some application code without the intervention of a standard OS (operating system). It should be understood that the runtime environment can be run in the context of a conventional OS, but the description is significantly more complex. Overview of the real-time environment Further, embodiments of the present invention will be elaborated while considering operation at a single node 10. The runtime environment in the processor 32 is controlled by a kernel that runs on the processor 32 periodically or continuously. The case of “periodic” is an operation method used in the context of the OS, but since the continuous execution is preferable, the latter is assumed in the following description. Each proset 32 also executes "processes" of the application invoked by the kernel. Each process has a lifetime between the time it is created by another process and the time it terminates spontaneously. As used herein, the term "process" refers to application code that executes concurrently with other processes by time-sharing processor time and saving stacks between time-sharings allocated to a particular process. Is different from its traditional meaning, such as a continuous stream of. The “process” referred to in this specification is defined by the following. (1) A process state consisting of various states stored in a shared memory 34 owned by a process existing from the time the process is created until the process is terminated. (2) The process behavior (behavior) is defined. Process types defined by code operating on various states and causing state transitions Again, only the process state and process type definitions exist for the life of the process. The kernel is continuous in the sense that it starts and does not end. Controlled by the kernel while the application process runs. The kernel calls the application process directly. In this sense, the kernel is always running. In a broad sense (at a glance), the kernel takes only one message at a time, received by a particular node, determines which process the message is intended for, Execute the completion code indicated by the type, change to one or more possible states according to the process state, output one or more messages to be sent to other processes, and finally return to the kernel. A sequence of such steps processed for each message is considered to constitute one "state transition" or simply one "transition". The kernel does not process the next message received by a particular node until the state transition associated with the previous message has completed. In fact, the kernel does nothing until a return from the application code executes and a transition occurs. A process is in "active" mode while the application code invoked in connection with a particular process executes. When the application task has completed, the process is in "inactive" mode. During inactivity, the process state and type continue to exist, but the processor does not execute any application code associated with the process and does not cause any possible state changes to the process. Time sharing also completes the transition of application code without the intervention of other processes, so there is no need to perform context switches between processes. It is a preferred feature of the present invention that state transitions are atomic. The minimum unit means that all operations related to the state transition occur or none of them occur. If for some reason all operations associated with the state transition are not completed, the effect on the state of any operation that has already been completed needs to be reverted. The behavior of each process is uniquely determined by the state and process type of the process. The states of different processes do not overlap. The process state of a process can only change due to the receipt of the message and its processing. The state transitions of the process are serialized, forming a strict sequence. Processes exclusively "own" (and are responsible for) state data and storage. The application code associated with the process type completely specifies the state changes and outgoing messages for each incoming message. A successful reply from this code completes the state transition. During the transition, each process goes into inactive mode and waits for the next message. Upon completion of the application code for each transition, a return code is returned to the kernel. The return code is either "commit" indicating that the code was executed successfully, or "abort" indicating that the code was not successfully executed. In the case of a successful return code, a successful state transition occurs. The kernel will perform some "post-transition" processing before transitioning to the next incoming message, which will be explained in more detail later. Process creation, termination, and identification Every process "P" is created as a by-product of the state transition of an existing process "A" on the same processor. P continues to exist while choosing to be independent of A. The process ends when the last message is received, by modifying the completion return code. Such modifications are detected by the kernel and processed during post-transition processing. At this time, the state storage assigned to the termination process is returned to the appropriate memory pool, the process type is returned to the default type, and all messages are discarded. Also, since the realization number (incarnation number) is incremented, all outstanding messages for the completed process are discarded. Both creation and termination of a process are part of the smallest unit of transition. In particular, the generation of P is part of the smallest unit transition for its generating side, A. Since direct creation occurs only locally (ie on the same shared memory), in order to get a spawned remote process, the process must run indirectly via an existing agent. Nevertheless, the agent may impose appropriate security restrictions. Once created, each process has a destination pid (process identifier), and other processes are used to address messages to the process. The destination pid will be described later. To make the destination pid available globally, an initial connection protocol is required. Initially, only the process knowing the pid of the process P and P itself are local sources. The usual way to get the pid of a remote process is to send an initial request to a well-known "name server" process, from which the response contains the desired pid. This applies to both existing processes and newly created processes. The process name of a well-known name server process (at least one for each node) can be handled in two ways, and is preferably used in a combination of the methods. The first is to provide a fixed index (fixed or realization number) for each of the good servers everywhere on all nodes. The second method relies on a common distributed name service based on having a well-known process register itself (the name server itself utilizes the first method). Schematic message flow Messages are the only means of communicating between nodes, whether or not the processes are on the same node. FIG. 3 schematically illustrates the flow of messages on a single node. Each node has a rotating input buffer ring 50 and a rotating output buffer ring 52, both of which share a portion of shared memory (see FIG. 2). It is formed using. The processor 32 executes a kernel 54 and controls execution of an application process 56. The kernel 54 has various functions. Here, the kernel 54 executes a dispatcher function and reads data from the input buffer 50. The application process 56 writes to the output buffer 56. The ordered input stream 58 from all other nodes is merged into a single serial input stream 60. In the case of ATM, the integration is performed somewhere in the absence of the ATM network. In other network environments, the integration is performed in the adapter 36 as shown. The incoming message is inserted into the next empty slot of the rotary input buffer ring 50. The kernel 54 processes messages in the order in which they arrive by asynchronously pulling messages from the input buffer ring 50 and activating the appropriate application processes 56 without the need for any process scheduling. Activation of the appropriate application process 56 will be described in more detail later. The output message is input to a subsequent slot in the rotating output buffer ring 52. Adapter 36 sequentially retrieves messages from output buffer ring 52 and places them in a single serial output stream 62 that includes a sequential stream 64 to all other nodes. It is possible for the adapter to reorder messages between the various streams, but not within a single stream. The rotating input buffer ring 50 and the rotating output buffer ring 52 provide for automatic reuse of free buffers without requiring explicit intervention of the kernel 54 by utilizing a rotating ring mechanism. Things. The input process, code execution, and output process can be desynchronized while allowing the transition execution speed to vary depending on the size of the ring. The load on the system can be represented by the occupancy of each buffer ring 50,52. The size of the buffer rings 50, 52 must be large enough (ie, to the same extent as other loss mechanisms) so that the loss rate due to buffer flooding is acceptably low. Input buffer ring Details of the recording of the input buffer ring 50 or the individual buffers will be described with reference to FIG. Rotating input buffer ring 50 is a data structure in shared memory 34 for processing messages received from communication adapter 36. The rotating input buffer ring 50 is more preferably statically configured as a ring of fixed (maximum) size message buffers (ie, a circularly connected list), such as at node initialization. . By using a static ring structure, it is not necessary to perform a dynamic list operation during the processing period, and the mutual exclusion problem and the problem of clear buffer reuse management can be avoided. Alternatively, buffers may be dynamically added to or deleted from the ring by the processor to adapt to gradual changes in occupancy statistics. Each message buffer contains the address of the next message buffer in the chain. These addresses collectively define where the ring is stored in memory. For a statically configured ring, these addresses are constant. FIG. 4 shows the fields in each message buffer (excluding the address of the next buffer). Each message buffer has a status word 70 used for synchronization, described below, and may also include some additional control information where possible (eg, a virtual channel identifier in the case of ATM). Each message buffer has space to store the body 72 (or content) of the message. The order and contents of the fields in each buffer can be set to suit a particular message protocol or buffering technique. In another embodiment (not shown), the message body and some or all of the dynamic control / status fields are placed in different areas of memory so that only a pointer to the body is written during buffering. You may. Such variations are useful in systems where the virtual memory address used by the processor is different from the physical memory address used by the adapter. This is because, according to this variant, each can have its own static ring-structured pointer (in a different memory address space) on the same (unlinked) message buffer. is there. As shown in FIG. 4, the body of the message 72 includes a destination pid field 74, a source pid field 76, and a data field 78. Messages are addressed to individual processes by having the corresponding pid in their destination pid field 74. The size and structure of the destination pid field 74 and the source pid field 76 are determined according to the addressing requirements for each particular instance in the network. The general structure of the pid field is a node identifier 80 used to identify the node associated with the process, a local pid 82 to identify the process on each node, and a process with a specific local pid 82 And an implementation number 84 that is used as an increment counter that is incremented each time it is generated. The realization number 84 is provided to limit the reuse of the pid or to distribute the process. A particular implementation of a process type is a process instance. The process instance table holds a mapping from the local pid 82 of the destination pid to the information needed to execute the application code associated with the indicated process. In the process instance table, one record 83 is prepared for each local pid 82. The record mainly consists of a code pointer 86 to a location in shared memory that stores application code for processing messages for the process instance, and a status pointer 88 to status information of the process instance. The realization index of pid is also held in field 90 of this record. It may include a pointer to a structure containing the generic attributes of the process type. It may further include (per instance) debug control or other attributes related to performance measurement. These attributes are different for each modification and execution mode (for example, simulation, development, field context). Output buffer ring The output buffer ring is similar to the input buffer ring. Input buffer operation by adapter One function of the communication adapter 36 is, for example, to transfer a valid received message (ie, a cell that is not “empty”) to the buffer pointed to by the state variable input_write_head in the input buffer ring 50 (DMA Transfer). The state variable input_write_head is used in the input buffer ring 50 to point to the next empty buffer. This state variable may be dedicated to the adapter 36 or held on the shared memory 34, but it is assumed that only the adapter 36 can read or rewrite (except at initialization. ). Upon each successful message transfer, adapter 36 sets a flag in the status field in the current buffer to indicate that the buffer is occupied by a valid message and sets input_write_head to the next in the chain. Advance to buffer. For example, another state variable, input_read_head, is maintained by kernel 54 and is used to control the reading of messages from the input buffer ring, as will be explained in greater detail below. Output buffer operation by adapter Another function of the communication adapter 36 is to transfer (via DMA) a valid (ie, "non-empty cell") message written to the output buffer ring 52 to the output communication stream 62. . For example, the state variable output_read_head is used to point to the message to be read from the output buffer ring 52. This state variable may be dedicated to the adapter 36 or may be held in the shared memory 34, but it is assumed that only the adapter 36 can read and rewrite data. except). For each successful message transfer, the adapter 36 sets a flag in the status field of the current buffer to indicate that the buffer is available again, and advances the output_lead_head to the next buffer in the chain. For example, another state variable output_write_head is maintained by the kernel 54 to control the writing of messages to the output buffer ring 52, which will be described in more detail below. Message syntax FIG. 5 shows a typical message syntax. As described above, the message syntax includes a destination pid 74 and a source pid 76 at the beginning of each message. The source pid 76 is automatically stamped for each message by the kernel 74 run time system. Also, the destination pid 74 is inserted by the kernel as part of the send message primitive operation. Application code 56 does not have direct access to any of these fields in the message, but can ask the message originator as an explicit call. The remaining message content (ie, data field 78) is associated with the message marshalling / de-marshalling device, and is ideally integrated with the application programming language. Details of this will not be referred to herein. Typically, it encodes a method 92, a format indicator 94 (such as the number of arguments 96 and the compression type of the signature), a standard machine independent basic type indication (including pid), and some checksum 98. . This format can also be encrypted. Kernel data structure and environment registers FIG. 6 illustrates how a run time system is configured in a particular embodiment. In this embodiment, the kernel maintains a system stack 100 and a trail stack 102 (described below). A series of environment registers are as shown below. mi- "mssage in" = input_read_head: accesses the message source pid and destination pid for messages in the input buffer ring 50. If the message exists, mi.status is true. mi.dest.pid is the destination pid included in the message. in-input byte stream: used to demarshal the code and extract the message fields from the message in the input buffer ring 50. no- "next out" = output_write_head: the next available output buffer in the output buffer ring 52 to set the destination pid and source pid. out-output byte stream: used by marshalling code in output buffer ring 52 to format the output message. pe-process entry: accesses all process instances and type attributes via process instance table 85. sp-stack pointer: start of system stack 100 te-trail stack end: end of undo log trail stack 102 pc-program counter: points to the next executable instruction in the execution code. Thus, the variables associated with the input and output buffer rings have been described. The main advantage of the system stack and the trail stack is that in the whole system, only one is needed for each processor. The illustrated memory pool 104 is an area in the memory 34 (see FIG. 2) that is reserved for process state storage. The code memory 106 is an area in the shared memory 34 for storing application codes. An active timer list 112 (managed by the kernel) is also located in shared memory 34. The code pointer 86 is shown pointing to the location in the code memory 106 where the application code is stored from the record pointed to by pe in the process instance table 85. State pointer 88 is shown pointing to the location in the state memory 104 where the process state for that process instance was stored from the same record in process instance table 85. The process state may include one or more timer pointers 114 for the timers in the active timer list 112. Cancel log mechanism There are several ways to implement the minimum unit of state transition. Assuming that only a few states are updated by most messages, and that the real need to recover the old state is extremely rare, all state variables that have changed, as illustrated in FIG. Software can be implemented efficiently based on logging of old values of. For this purpose, a single system resource of sufficiently large size, called the trail stack 102, is required. The trail stack 102 is composed of an array (or stack) composed of (address, value) pairs. Initially, and just before each application task is executed, the environment register te (trail end) is set to point to the start position 103 of the trail stack 103. When writing a state word during the execution of an application task, the address (addr) of the pointed location and the current value (oldval) must first be written to the trail stack 102. (Support for language compilers and code generators allows this requirement to be fulfilled efficiently.) When the transition is completed (ie, the application task has completed successfully and the process is in suspended mode) Te is reset to the top of the trail stack 102 and is ready for the next message. When a transition needs to be interrupted, the trail is processed in reverse order (from the back), restoring the old value to the location pointed to by process state memory 104. Such a process is realized, for example, by the following code. New values written during the failed transition are discarded. Trailing applies to all state variable updates. State variables consist of those pointed to by the process's state pointer in the memory segment and arrive from there. Updating the state variables is related to the timer area (creating, resetting, and deleting timers used by the process; the timer will be described in detail later), the process instance table (related to creating a process), and memory • Include changes in the pool (related to dynamic memory allocation). At present, timer operations, process creation, and memory allocation are all automatically included in the atomic action. Trailing is not required for updating the stack, or the output message buffer, or other volatile variables. Of course, for optimization, initialization (construction) code for the state object is required. Of course, it should be appreciated that other mechanisms can be used to achieve the smallest unit without departing from the spirit of the invention. Kernel dispatch process Processor 32 executes the kernel during application code execution. The kernel has a main loop that runs only once per input message. FIG. 8 illustrates the kernel loop in the form of a flowchart. The kernel loop is described in the above context, which introduces the kernel data structure and environment registers described with reference to FIG. As already mentioned, the kernel has an internal state variable input_read_head (or mi) that points to the next available message in the input buffer 50. The kernel executes the idle task while the status register mi.status is equal to zero indicating that the input buffer is empty (exit branch Yes at block 200 and proceed to block 202). The function of the kernel is to process incoming messages in the order of arrival as quickly as possible. If the incoming message arrives (go to branch No in block 200) and if the status flag field of the message buffer pointed to by input_read_head indicates that it is a valid message, the kernel will return the destination of the message. mi. Dest, derive the local pid from the destination pid, verify that the local pid is in the correct range, and use it to access the record in the process instance table 85. The field of the process instance record contains the realization index, which must exactly match the destination pid derived from the incoming message. If the derived realization index is out of range, the input message is considered invalid (go to branch No at block 204), the error counter is incremented (block 206), and its status field is cleared. By doing so and advancing the input_read_head pointer (block 222), the message is discarded. If the message pid is valid (go to branch Yes at block 204), the kernel sets the environment variables for process execution and atomic support, and by means of a code pointer in the process instance table. Call the application code pointed to. If the application code needs access, one (conceptual) environment variable may provide the message origin pid. (However, applications rarely need to query the origin of the message, it is sufficient to simply copy the pointer to the message source field into a hidden environment variable (preferably a register), It is even effective, and if the application needs it, it is sufficient to use an indirect memory reference to retrieve the source field.) Similarly, the application code is available at this location. When requesting information (eg, pid or process type attributes), a pointer to the process instance table record is left in an environment variable (possibly in a register). To invoke the application code, a status pointer 88 and a code pointer 86 are read from the process instance table 85, fetched into registers according to the call convention, and / or pushed onto the stack. The command field of the method or message must be derived. Also, a pointer to the next field of the message after this command, the input byte stream register, is fetched into the register and / or pushed onto the stack. A copy (kernel local) of output_write_head is made to support the smallest unit for the output message (block 210). The application code is then invoked, calling the application code pointed to by the code pointer, passing the input byte stream in and the status pointer as parameters, and expecting a return code or result "res" ( Block 212). When the application code is returned to the kernel, its return code res (either in a register or at the top of the stack, as appropriate) may be "commit" or "abort". Is shown. If the code indicates that a decision has been made to abort (No at block 214), the kernel resets output_write_head from its locally stored value and cancels all output messages. Then, the initial state of the process needs to be restored (block 216). The input message is then discarded by clearing the status field and advancing input_read_head to the next message (block 222). If the return code indicates "commit" (block 214, Yes), all output messages generated by the application code will start with the stored value of output_write_head and return to the current value of output_write_head. Continuing, the status field must be set to be processed by the communication adapter. The trail can be reset simply by assigning trail_start to trail_end (block 218). In the special case of a process terminating, the pid and process state associated with the process are deallocated (block 220). Eventually, the input message is discarded by clearing the status field and advancing the input_read_head to the next input message (block 222). If a software exception occurs during the execution of the application code (arrow 223), appropriate diagnostic information can be obtained (block 224) and the system stack returns to the normal time (ie, the application code The call is reset to a point just before the call) and control transfers to the abort process (block 216) as described above. The related diagnostic information is roughly composed of the following ascending order of size and descending order of utility. (0) error type and program counter (1) current input message (2) (complete) current process state (3) complete input buffering (both recently processed messages and near future messages) As an example of a software exception, for each type of process, there may be a maximum allowed time for a process transition for that type. If the transition exceeds this time limit, an exception is raised and processed as described above. In the embodiments described herein, there is no difference in processor overhead depending on whether the message is external or completely internal. If the internal message is optimized to eliminate potential copy operations from the output buffer to the input buffer, this difference will at most be the DMA cost of the copy. To optimally implement (in assembler language) a kernel loop as described above, about 50 machine language instructions are sufficient, and on a typical workstation the kernel overhead is only a fraction of a microsecond. No. The process transition may generate an output message for which a response is required. Such a process transition is completed (as usual) and the process enters an "inactive" mode. When the expected response is received, it is placed in the input buffer ring and processed by activating the original process in the usual manner. Since it is assumed that messages may be lost, provisions are made for the timer to detect such lost messages. One possible general rule is that processes waiting for a response to a message use a timer to detect a lost message. Such a process is said to be in a "transient state", and if either the original message or its response is lost, the process will instead endlessly enter such a state. Can stay. When the timer expires, a timeout message is sent, triggering some recovery action by the process. The type of recovery action that can be taken depends on the type of process involved and the nature of the failure. For example, in the case of an exchange between "persistent" processes (processes with backups or processes that are automatically regenerated), the action is the partner (by sending a message) May be checked, the partner's name may be rebound, or it may be done continuously until successful. In the case of a bunch of processes (eg, a process that manages call setup and transactions), simply aborting the action with some entry created by external means to the process. In systems where a large number of processes enter the interstitial state and almost always leave the state, it is important to keep the cost of both setting and canceling the timer very low. In the present specification, it is assumed that the timeout value is an arbitrary value, and a timeout value considerably larger than a normal response time is used. The actual value of the timeout is not particularly important, and there is usually no need to provide an exact timeout delay. In such a situation, in order to achieve extremely low cost, a data structure of the following format is used. The timer can be created or destroyed by a process using the following two processing procedures. The timer pointer is maintained in the process state. This process creates a new timer record and returns its pointer. The owner field gets the id of the currently executing process, and a timer record is attached to the global timer chain. (If a different clock resolution is required, that resolution is an input parameter.) Such a timer chain is a global variable managed by the kernel. The above removes the timer from the global timer chain (it must be a dual link chain for efficiency) and then deallocates the timer. By using the following macros, you can set and cancel timers at very low cost. Configured to perform a timer scan (between application process executions) that runs on all chained timers while decrementing non-negative value fields by regular interrupts by the real-time clock can do. Any value fields that go to zero result in a message being sent to the owner process. In the present embodiment, it is assumed that the timeout message has the command "timeout", so that the resulting action is purely state driven. As an alternative, set_timer can include the message code used on the timeout message. Many modifications and variations of the present invention are possible in light of the above teachings. Therefore, it should be noted that the invention may be practiced otherwise than as specifically described herein without departing from the scope of the appended claims. Although a particular mechanism for implementing the smallest unit of state transition has been described herein, it should be noted that other mechanisms may be utilized. A process ID (pid) can be used to indicate the capability of the process. Having a pid gives an entity the right to send all messages accepted by the associated process, thereby demonstrating the ability to be. In the embodiments described herein, the pid is binary and can be stored in any convenient data structure, passed freely in a message, etc. Also, there is no need for any controls or restrictions on the ability to deliver. In such a system, previously authorized capabilities can only be revoked by destroying the process and then creating a new process with another pid and performing that function if necessary. Node reinitialization is an extreme example of this. A practical assumption is that a mild and cooperative environment is credible in that all nodes are not malicious, but can malfunction under fault conditions. The realization number fills the other unused bits of the pid, but does not reuse the same process id during some time interval, and is therefore sufficient to purge the old stored pid. It has become. An inexpensive way to undo prominent capabilities is to increment the realization number of the process while maintaining its state. Of course, a mounting form that does not use the realization number is also possible.

[Procedure of Amendment] Article 184-8, Paragraph 1 of the Patent Act [Submission date] August 20, 1999 (1999.8.20) [Correction contents]                                The scope of the claims 1. Asynchronous messages in a network node with processor and memory Processing method,   Note the application code for multiple application tasks Storing it in the   While maintaining a plurality of process states in the memory, each process state is Each process state is associated with one of the application tasks by a pid (process Identifier), and   The node receives an input message, each containing a particular one of the pids. Receiving,   For each input message received, the processor will Identifying an application task associated with a particular one of the pids Execute as a function of a particular process state identified by the Steps A method for processing an asynchronous message, comprising: 2. Further comprising the step of making a change to the particular process state. 2. The asynchronous message processing method according to claim 1, wherein 3. further,   During execution, the steps by which the application task generates output messages ,   After the application task has completed successfully, the node Transferring the page, 2. The method according to claim 1, further comprising: 4. In addition, the interface forms part of the node that receives incoming messages And store them in the input message queue in the order in which they were received Comprising the steps of:   The processor executes the associated application without interruption until completion Read the message stored in the input message queue. And process them one at a time, 2. The method of claim 1, wherein: 5. further,   Application tasks output messages in the order in which they were created Storing in a message queue;   In response to the application task completing successfully, Table that the messages generated by the solution task can be forwarded Storing an indication in the message queue; With   The interface sends a message containing an indication that it can be forwarded. Read from the output message queue and transfer one at a time; The method of claim 4, wherein: 6. Each process has a process type that identifies the associated application task. 2. The asynchronous message processing method according to claim 1, wherein the asynchronous message processing method has a loop definition. 7. The processor creates a new process to create a new process instance. 7. The method according to claim 6, wherein a process state is assigned to each of the memories. Asynchronous message processing method. 8. The process state is a past value that existed before the application task started Consists of multiple state variables with   All states in which the processor has been modified by application tasks Logging a past value for the variable;   If the application task is completed, aborted, or an exception Ending with   When the application task terminates in either aborted or exceptional form Recovering the modified state variable to a previous value; 2. The asynchronous message processing method according to claim 1, further comprising: . 9. For all state variables modified by the application task The step of logging past values is a step in which the processor causes each past value and its Address as the trail stack pointed to by the trail stack pointer. To a location in memory allocated by Is realized by incrementing   If the application task is completed and completed, the processor Reset the trail stack pointer,   If the application task is aborted or terminated abnormally, the processor Restores each of the past values in the trail stack to the original address in the memory Do The method of claim 8, wherein the asynchronous message processing method comprises: 10. Messages stored in the output message queue by the application task The message is only forwarded when the application task has completed and completed. The method according to claim 8, wherein the asynchronous message processing method comprises: 11. The incoming message is a send identifying the process that sent the message 2. The asynchronous message processing method according to claim 1, further comprising a source pid. 12. Input message queue and output message queue are stored in the memory And accessible by the processor and the interface Accessible by direct memory access by All communication and control between interfaces is done only through these queues The asynchronous message processing method according to claim 5, wherein: 13. For each pid, the location of the corresponding process state in the memory and the associated application Process instance to map the location of the 2. The asynchronous message as claimed in claim 1, wherein a distance table is used. Page processing method. 14． The execution of application tasks is a kernel task that calls them directly Controlled by   Message generated by application task associated with specific pid And then forwarded by the node and expect a response to the input message. To wait, the application task starts a timer and the application Execution to completion and control of kernel tasks A kernel task decrements it periodically, and   When the timer expires, the kernel task addresses the particular pid. Generating an encrypted timeout message; 2. The asynchronous message processing method according to claim 1, further comprising: . 15. A network node for connecting to a digital network,   Receives incoming messages and stores them in the input message queue The message to be sent is read from the output message queue and transferred. Digital network interface,   Stores application code for multiple application tasks And run to store multiple process states Memory that can be   The process state is maintained in the memory, and each process state is stored in a pid (process identification). Each pid is identified by one of the application tasks And receive messages one at a time from the input message queue. Read in the order in which the A particular task identified by the pid of the input message Can be run as a function of state to execute without interruption Rup With the Rosessa, A network node comprising: 16. The processor further changes the specific process state, Writes the output message to the next available buffer location in the output message queue The network according to claim 15, wherein the network can be operated so as to input data. Work node. 17． A digital network consisting of multiple network nodes , Each network node   Receives incoming messages and stores them in the input message queue The message to be sent is read from the output message queue and transferred. Digital network interface,   Stores application code for multiple application tasks And run to store multiple process states Memory that can be   The process state is maintained in the memory, and each process state is stored in a pid (process identification). Each pid with one of the application tasks. Associate and receive messages one at a time from the input message queue Read in the order, the application associated with the pid of the input message Task is identified by the pid of the input message. Executes without interruption as a state function and changes the state of that particular process Output message and the next available buffer in the output message queue. A processor operable to write to the buffer location; A digital network, comprising: 18. In addition, a process that knows the pids of several processes running on each node A first name node of the plurality of network nodes. A process on a second of the plurality of network nodes The first node queries the process name server to identify And the process name server sends the process name of the process on the second node. 18. The digital communication device according to claim 17, wherein the response is performed with a access identifier. network.

────────────────────────────────────────────────── ─── Continuation of front page    (72) Inventor Eric Bierman             Canada, K2P2G2, Onta             Rio, Ottawa, 1701-71 Somerset             Treat W

Claims (1)

[Claims] 1. Asynchronous messages in a network node with processor and memory Processing method,   The pid (process i) consists of application code associated with the process state. dentifier (process identifier) in memory Steps to maintain;   A node receiving an input message;   For each message received, the processor forms part of the message. To any of the plurality of processes based on the destination pid And determine the application code associated with the destination pid To process the message as a function of the process state of the destination process. Modifying the process state of the destination process if necessary;   Steps in which the application task generates outgoing messages during execution When,   The node forwarding the outgoing message; A method for processing an asynchronous message, comprising: 2. In addition, the interface forms part of the node that receives incoming messages And store them in the input message queue in the order in which they were received Comprising the steps of:   The processor reads a message stored in the input message queue. Process one at a time, 2. The method of claim 1, wherein: 3. In addition, the application code generates output messages in the order in which Therefore, there is the step of storing in the output message queue,   The interface reads a message from the output message queue And transfer one at a time, The method according to claim 2, wherein 4. Each process has a process type that identifies the associated application code. 2. The asynchronous method according to claim 1, further comprising storing the loop definition in a memory. Message processing method. 5. The processor creates a new process to create a new process instance. 5. The method according to claim 4, wherein a process state is assigned to each of the memories. Asynchronous message processing method. 6. The process state is a past value that existed before the start of the application code Consists of multiple state variables with   further,   The processor has been modified by application code during the transition period Logging past values for all state variables;   The application code is in any form: completed, aborted, or exception Ending with   If the application code terminates in either aborted or exceptional form Recovering the processor by modifying the state variable to a past value; , 2. The method according to claim 1, further comprising: 7. For all state variables modified by the application code The step of logging past values is a step in which the processor executes each past value and its Address as the trail stack pointed to by the trail stack pointer. To a location in memory allocated by Is realized by incrementing   If the application code completes and terminates, the processor Reset the trail stack pointer,   If the application code is aborted or exceptionally terminated, the processor Restores each of the past values in the trail stack to the original address in the memory You , 7. The method according to claim 6, wherein: 8. Messages stored in the output message queue by application code Messages are only transferred when the application code has completed and finished 7. The method according to claim 6, wherein: 9. The input message is the sender that identifies the process that sent the message The asynchronous message processing method according to claim 1, further comprising a pid. 10. Input message queue and output message queue are stored in the memory And accessible by the processor and the interface Accessible by direct memory access by All necessary normal communication and control between interfaces 4. The method according to claim 3, wherein the method is performed only. 11. Each pid is a location of the corresponding process state in the memory or an application. Process instance to map to the location in memory of the code The asynchronous message processing according to claim 1, wherein a table is used. Method. 12. further,   Messages are generated by specific processes and subsequently forwarded by nodes. And the particular process expects a response to the input message The process starts a timer and the kernel decrements it periodically When,   When the timer expires, the processor sends a timeout message to the feature. Sending to a predetermined process; 2. The method according to claim 1, further comprising: 13. A network node for connecting to a digital network,   Receives incoming messages and stores them in the input message queue The message to be sent is read from the output message queue and transferred. Digital network interface,   The pid (process i) consists of application code associated with the process state. dentifier (process identifier) in memory Maintain and receive messages one at a time from the input message queue. Read out in the order in which they were received, and based on the destination pid that Which of the multiple processes the message is addressed to Determines and executes the application code associated with the destination pid to Process the message as a function of the process state of the destination Change the process state of the destination process if any, and output messages if necessary. Write the outgoing message to the next available buffer location in the message queue. With Sessa, A network node comprising: 14． A digital network consisting of multiple network nodes , Each network node   Receives incoming messages and stores them in the input message queue The message to be sent is read from the output message queue and transferred. Digital network interface,   The pid (process i) consists of application code associated with the process state. dentifier (process identifier) in memory Maintain and receive messages one at a time from the input message queue. Read out in the order in which they were received, and based on the destination pid that Which of the multiple processes the message is addressed to Determines and executes the application code associated with the destination pid to Process the message as a function of the process state of the destination Change the process state of the destination process if any, and output messages if necessary. Sey The processor that writes outgoing messages to the next available buffer location in the queue. And A digital network, comprising: 15. In addition, a process that knows the pids of several processes running on each node A first name node of the plurality of network nodes. A process on a second of the plurality of network nodes The first node queries the process name server to identify And the process name server sends the process name of the process on the second node. 15. The digital communication device according to claim 14, wherein the response is performed with a access identifier. network.