JPH05204673A - Method and process of communication between process using named pipe - Google Patents

Abstract

PURPOSE: To obtain a method and device for transmitting a message between a message transmitting process and a message receiving process in a computer system without registering the message type in the system. CONSTITUTION: A process A which wants to receive a message of a type X generates a pipe 106 with a name X. A process D which wants to send a message of the type X to other relative processes in the system opens all instances of a pipe X108 with a name and writes the message to respective instances. The system automatically warns the receiving process A at the other end of a pipe instance and the receiving process A reads the message out of the pipe 106 with the name in response to that.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION This invention relates generally to inter-process communication in multi-tasking or multi-processing computer systems. In particular, the present invention selectively distributes messages by processes in the system to other message receiving processes via named pipes, all according to message type, and without using table registration of the receiving process. A method and apparatus.

[0002]

BACKGROUND OF THE INVENTION The present invention includes shared memory, semaphore, queues, pipes and named pipes for interprocess communication (IPC) within a computer system. Name most. The characteristics of various methods of these IPCs are described in the paper TALKING TASKS, b.
eginning at page 403 in BYTE magazine, November 19
It is summarized in 90 issues.

This disclosure relates to the use of named communication channels or named pipes. One scenario for using named pipes for interprocess communication is message distribution. For example, in some systems, the message server receives messages from other processes running on that system and then distributes the messages to other processes desiring to receive the messages. This technique is commonly used in desktop computer window operating systems, such as the OS / 2 (trademark of IBM Corporation) operating system. One common approach to using named pipes in such operating systems is to have a message server distribute the message to every process in the system and ask if it contains relevant information. Each process that receives is a decision. This is called a broadcast method. Another common approach is to register the processes and the particular type of message that each of them wants to receive. This is sometimes referred to as the registration approach. Clearly, the broadcast technique results in a large amount of traffic wasted in the computer. An example of the latter registration approach is Software-P
practice and Experience, Vol.20 (S1), pages S1 / 3-S1 / 1
7, another paper published in June 1990 INTERPROCESS COMM
UNICATION INTHE NINTH EDITION UNIX SYSTEM by David
Described in Presotto and Dennis Ritchie. For example, a connection server using the registration approach is described from page S1 / 10 of this paper. In this example, the server process creates a pipe and advertises its service and that pipe to other processes. The customer process connects to the pipe when it wants to use the service,
Communicate to the server an indication of the type of service being registered and requested. This type of service may be a request to receive certain types of system messages.

Paper PORTABLE IPC ON VANILLA UNIX, Mark
Rain, Penobscot Research Center, Deer Isle, Maine 04
627 describes a modification of the registration method. This paper describes a channel server that has a service that provides IPC channels and acts as a server registration for customer processes. The server gets an IPC channel (pipe) from the channel service. The server then registers itself with the channel service along with an indication of the services it offers.

[0005]

Such a registration approach can be inconvenient to maintain. For example, if a registered process terminates abnormally, the registration by the server process that maintains the registration will not be automatically removed without special configuration to trap this condition. Furthermore, both broadcast and registration techniques consume considerable resources, which is desirable to reduce.

[0006]

The present invention is a computer
A method and apparatus for communicating a message between a message sending process and a message receiving process in a system. A process that wants to receive certain types of messages creates a communication channel, or named pipe. This pipe terminates in the receiving process and is managed by the computer's operating system. The name by which the process can address that channel is assigned corresponding to the message type that the producing process wishes to receive. In other words, the message type identification identifies the channel name. A process that sends a message of the selected type to another process in the system opens a communication channel with a name that corresponds to the selected message type. The send process then describes the message to the channel using the system function call provided for that purpose. The process of writing to this channel alerts the receiving process at the other end of the channel, in response the receiving process reads the message from the transmitting channel.

In the preferred embodiment, after the receiving process has created the communication channel, the receiving process is kept inactive until the sending process is reactivated by the system by writing a message to said channel. After a message is read from a channel by a receiving process, the receiving process regains inactivity until another process writes to the channel. However, the receiving process remains active if it wishes,
The use of semaphores sent by the operating system can determine when a message is present on that pipe.

In a type of system in which named communication channels are available, that is, in systems such as the OS / 2 operating system, many instances of channels with the same name can exist at the same time. Thus, as used in the present invention, each application that wants to receive type X messages instantiates a channel with the name X. A sending process wishing to send a message to all processes in the system simply opens all instances of communication channels in the system with the same name corresponding to the message type being sent.

Therefore, it can be seen that the selective message distribution function or service can be easily integrated into the system using channels such as named pipes and without using a registration mechanism. Message distribution can be performed by a process that knows only the type identification of the message being sent and can be received by any process that wants to receive a message of a specified type. The sending process need not know the process of receiving the message. The send process only opens a named system channel for the message type being sent and writes the message to that channel. Similarly, the process of receiving the message may not know the process of sending the message.

[0010]

DETAILED DESCRIPTION A named pipe is a communication means in the operating system of a multitasking computer.
It can be used to send and receive data and messages between processes running in the system or even between processes in different systems. Named pipes are now well known in the art. The following are the characteristics of the named pipe. Pipes are built by system functions when requested by a process. The pipe is owned by the process that creates it, and one end of it begins with the process that created it. In general, the creator and owner of a named pipe is the sender of data, etc. to another process at the other end of the pipe. However, the owner of the pipe can also receive the data. In fact, using this mode of operation is an advantage of the invention, as will be explained later. Pipes can also be created for double motion. That is, pipes can be used to send data in both directions along a pipe between processes. Each pipe has a name, which allows you to address the pipe (handles the name on some systems,
Converted to a number, by which the device is addressed). Multiple instances of named pipes are allowed,
Addressable by the process of interest.

Another form of IPC called a semaphore generally receives the act of sending data on a pipe so that the sender does not overflow the pipe and the receiver knows when to read data from the pipe. Used to synchronize motion. These semaphores are also commonly used to ensure atomic write / read operations on pipes.

The process that owns a pipe can terminate it at any time. If the process itself terminates, all named pipes owned by that process are also terminated. In other words, no named pipe lasts longer than its creator. Operations on these named pipes, data generation, transmission / reception, and termination are performed by system functions at the request of other processes. For example, the OS / 2 operating system allows manipulation of named pipes through a set of system calls including: DosCallNmPipe: performs a complete set of operations to write to a named pipe. This is a named pipe open,
Includes write and close. DosClose: Close a file, device or pipe. DosConnectNmPipe: Connects an application with a named pipe and allows the application to read from and write to that pipe. DosDisConnectNmPipe: disconnects the application from the named pipe after the application has read or written. DosMakeNmPipe: Creates a named pipe using the name supplied by the application, returns a handle that can address the application, reads it,
Performs named pipe functions such as write, open and close. DosOpen: Opens a file or named pipe. DosPeekNmPipe: An application can inspect data arriving via a named pipe without transferring that data from the pipe. DosNmPHandState: The application can ask about pipe characteristics (eg message type vs. block type). DosONmPipeInfo: The application can ask for statistics about the named pipe (eg current number of instances, maximum number of possible instances). DosONmPipeSemState: The application is in the pipe state (eg data in pipe, amount of data in pipe)
You can ask about. DosRead: Read from a file or named pipe. DosReadAsync: An application can asynchronously transfer a specified amount of data from a pipe or file to a buffer. DosSetNmPHandState: Sets the read and blocking model for the named pipe. (If no data is available in the pipe when the call is made, blocking signals the application to stop until data arrives in the pipe). DosSetNmPipeSem: Connect a system semaphore to a named pipe. This semaphore is then used by the application as an indicator of when data arrives on that pipe. DosWaitNmPipe: An application can wait for a named pipe to be created. DosWrite: Write to a file or named pipe. DosWriteAsync: An application can asynchronously transfer a specified amount of data from a buffer to a pipe or file.

These features and their use are well known to those skilled in the programming arts. They are especially OS / 2 Programmers Reference Guide, Document Num
ber64F0275, September 1989 in detail.

FIG. 1 illustrates a prior art method of using named pipes in the prior art to perform inter-process message transfer. This is a simplified example that includes a single multi-tasking computer system 100.
In this example, assume that at least four separate application processes AD are running in the system when relevant. In FIG. 1, the message server 102
And the registration table 104 is also shown. For example, application program A, if it wants to receive certain classes or types of messages generated by the system or other applications, registers itself with message server 102 by an appropriate system call. The registration request includes instructions related to receipt from the message type registration process. Suppose application A requests that message server 102 examine all received type X messages. Similarly, at some point, application C has also requested to receive a type X message from message server 102. Application D has requested to receive a type Y message. When a system function that enables registration is performed, the resulting registration table 104 contains the requesting process. It will be appreciated that, according to this particular embodiment, the registration table 104 includes separate entries for applications A, C and D, as well as an indication for each type of message each application wishes to receive.

Once the registration request is received at message server 102 and an appropriate entry is created in registration table 104, a named pipe leading from message server 102 to that application is also created. As shown, the particular pipe name and request type for a given requester is entered into the registration table 104. For example, if application A requests to be registered to receive type X messages, a pipe 106 is created from message server 102 to application A (if there is no pipe to application A yet). The identification of these pipes is arbitrary and is independent of the type of message sent through them or the receiving process, except through the registration table 104. To send the message for distribution to Message Server 102,
For example, application to message server 10
A pipe 108 to 2 or other communication channel can also be created. In this simplified example, details of communication from the application to the message server 102 are omitted.

Here, application D of FIG. 1 has all other system applications wishing to receive type X messages.
Suppose you want to generate a type X message for distribution to a process. Message is channel or pipe 10
8 is sent to the message server 102. The message server 102 receives the message, notes the type contained in the message, and searches the registration table 104 to identify all registered processes that want to receive the type X message. In this example, the message server 102 uses message type X
Discover applications A and C registered as Accordingly, message server 102 registers pipe identifications associated with applications A and C in registration table 104.
And route the received message from application D to applications A and C through these pipes. For application A,
The message specifies the route by the pipe 106 identified by the PIPENAME (pipe name) field of the registration table 104.

As already briefly explained, this typical type of message arrangement has certain drawbacks. The first drawback is that the registration table 104 needs to be managed. The second drawback is that this management is not always automatic. For example, suppose for some reason Application A disappears from the system. It is a malfunction of the system,
It may be due to a bug in the program or some other cause. In such cases, the registration table 104
Is not automatically updated and application A remains in registration table 104. When the message server 102 attempts to communicate with the application identified by the table entry, the error occurrence is detected and the table entry is eventually removed from the system. However, the registration table 104 is restored to the correct state only after processing one or more error states resulting from the communication.

FIG. 2 illustrates a similar messaging implementation in a system designed in accordance with the present invention. In this example, there is no explicit message server. Such an example will be briefly described later. Also in this example, FIG.
In the present embodiment, it is assumed that four applications A through D within computer system 200 are active.
The system functions provided for manipulating pipes are conceptually shown as one block 202. Dashed lines in the figure represent invocation of system functions by applications. Each application includes a RECEIVE module and a SEND module, eg 206 and 208 associated with application A. When an application wants to receive a given type of message from another application, that application's RECEIVE module creates a named pipe, and the created pipe is part of the producing application's RECEIVE module. The named pipe 210 indicating the end of the applications A to D in the RECEIVE module is an example. In accordance with the present invention, each pipe is named to identify the message type sent through that pipe. So, for example, if application A wants to receive two message types X and Y, its RECEIVE module calls each instance of two pipes terminating in its RECEIVE module. An instance is for each message type, each named by a system function that identifies its associated message type. Because the application creates a named pipe, the application owns the named pipe, unlike the general situation in FIG. 1 where the pipe is owned by the message server 102. One advantage of this arrangement is that system functions automatically terminate the pipe if the application terminates for any reason. For example, the OS / 2 operating system closes all files and pipe handles owned by a process during normal or abnormal termination of the process.
Use DosClose function. This configuration makes registration unnecessary, as will become apparent later.

As shown in FIG. 2, each of the named pipes is terminated at the other end with a block of system functions 202. This termination is, of course, conceptual. In practice, each of these pipes simply exists in the system and is identified to the operating system by the consistent naming convention associated with each instance of the pipe having a particular type of message. And this naming convention allows processes like A to D to access pipes and instances of pipes through the system functionality of sending messages.

When an application wants to send a message of a certain type to all other applications that want to look at this type of message, the sending application uses the message type, such as pipename, to make the appropriate system call. .. The system call finds each instance of the pipe named for that message type and sends the message through the pipe to the appropriate RECEIVE module. The dashed line in FIG. 2 represents the communication process in which the SEND module of the application makes system calls to send such messages to other associated receiving processes.

FIGS. 3 and 4 show the RECE of each application.
The main steps performed by the IVE module and the SEND module are shown respectively. The source code corresponding to these steps is given in Appendix A and Appendix B, respectively.

The RECEIVE module will now be described with reference to FIG. 3 and Appendix A. This module runs when an application wants to configure itself to receive messages of the specified type. Step 310
Generates a pipe name according to the type of message the application wants to receive. There are various ways to generate a pipe name. Since this is a self-explanatory function, detailed description of its operation is not necessary. The only requirement is that for a given type of message, the same pipe name will be generated by all related applications. In the preferred embodiment, the code for generating the name is included in the source library. This library is RECE of each application
Included in the code for the IVE module and compiled into that module. In Appendix A, this library code is
It is called PIPENAME.C and is included in the RECEIVE module on line 8. The main body of the RECEIVE module is line 1
Starts with 0. System function call DosMakeNmPi on line 13
pe actually creates a pipe that is owned by and terminates in the producing application. This corresponds to step 320 in FIG. DosMakeNmPipe is another feature to generate pipe names "build_pipe_nam
Call e ". The pipe name is predetermined based on the type of message that needs to create the pipe. Function Do
sMakeNmPipe is the number of parameters. The first parameter identifies the "build_pipe_name (X)" contained in the library source program PIPENAME.C. As mentioned above, this function will generate the pipe name for DosMakeNmPipe.
This corresponds to step 310 in FIG. DosMakeNmPipe creates a pipe and returns "pipe_handle". The pipe is thereby addressed via another system function call. Argument of DosMakeNmPipe, X represents the message type of the generated type. The success or failure of the pipe creation on line 14 is returned by DosMakeNmPipe in the return code variable "rc" on line 14. This example creates a blocking mode pipe. This causes the operating system to Dos until the message appears in the pipe.
This means suspending the operation of the process executing the ConnectNmPipe function call (sometimes called the dormant process). When the message appears on the pipe, Appendix A
The operating system restarts the operation of the deferred process (rewakes the process) so as to start reading the message on line 16 of the. If the pipe was created in non-blocking mode, the RECEIVE process does not have to manage the pipe operation itself, for example by using the DosSetNmPipeSem function call.

An alternative way to generate a consistent pipe name that reflects the message type associated with the pipe is to provide a system function call for that purpose.

After the pipe has been successfully created, the RECEIVE module waits on the pipe to receive the message corresponding to that pipe, as indicated by rc set equal to NO_ERROR. This corresponds to "sleep" in the illustrated embodiment. This action occurs at step 330 of FIG. 3 and line 14 of Appendix A. If the application wants to receive other types of messages, the RECEIVE module needs to create pipes for these message types and wait on those pipes. If the message is sent, the waiting application is awakened by the operating system receiving the message without looping and checking or otherwise consuming system resources. In this preferred embodiment, the RECEIVE module uses the system function call DosConnectNmPipe.
The function prepares a pipe to accept DosOpen system calls from the message sender. The RECEIVE module remains dormant until another application performs the DosOpen function for the specified message type.

When a message sender joins a named pipe (performs a DosOpen system function with the specified pipe name), the sender is connected to the pipe. In fact, the sender is connected to every instance of the named pipe with the same name. The send application described in connection with the SEND module sends a message that it wants to convey by another system call. Correct message
Any RE connected to a type pipe instance
The CEIVE module receives messages from that pipe. This action occurs at 340 in FIG. 3 and line 16 in Appendix A. The system function DosRead does the actual message reading from the pipe on line 16 of Appendix A. The message is read into the parameter "buffer" specified in the function. The actual write to "buffer" is a line
Get up at 25. Reading and writing message bytes from the pipe continues until the parameter "bytes_read" on line 21 indicates that no more bytes will come. This signals the end of the message. At this point, the pipe must be reset in preparation for the next message. This action occurs in step 350 of FIG. 3 and line 22 of Appendix A.
The system function call DosDisConnectNmPipe performs this action on line 22. RECE after the pipe is reset
The IVE module returns to step 330 and waits to receive the next message.

The RECEIVE module also activates the appropriate functions so that the message can be manipulated after it has been read and stored in the buffer. However, this function is not shown because it is not particularly relevant to the present invention.

The application SEND module is shown in FIG. 4 and Appendix B. The SEND module, when it performs the sending of a type X message to all other related applications, generates a pipe name corresponding to the message type in the same way as previously described for the RECEIVE module. This action occurs at step 410 of FIG. 4 and line 15 of Appendix B. Next, at line 16 (and step 420), the SEND module begins a loop that binds to all instances of the named pipe with names corresponding to the message type in the system. In each loop, the system function opens the next instance of the pipe name. When there are no more pipe instances, the operating system informs the SEND module of the return code. System function call on line 18
DosOpen actually does the join with each named pipe. The loop performing the message write to each pipe occurs at line 21 in Appendix b. At line 24 (step 430 in FIG. 4), the actual writing of the message to the pipe occurs via the DosWrite system call. In each loop,
The DosWrite function will automatically write to the next instance of the named pipe. After each writing to the pipe, the DosClose system function call disconnects the sending application from the pipe at line 25 (step 440 of FIG. 4) and the parameter byte_read to the DosRead function at line 18 of the RECEIVE module of the application bound to the pipe. 0 of
Receive a byte display. The pipe disconnection (close) by the SEND module is for the pipe instance.
Indicates the end of a "send" operation. The loop is step 430 in FIG.
And 440 iterate writing the message to all instances of the named pipe. Then this particular send
Execution of the module is terminated, stopping its operation until the application wants to send another message.

By the method described above, the messaging application does not need to know which application wants to receive a particular message. The receiving application may also not know which application sends the message. And, importantly, messages are delivered flexibly and powerfully throughout the system, significantly reducing the system overhead required to achieve the goal. A consistent pipe naming convention identifies the types of messages that the receiving application wants to receive and allows the sending application to communicate with all other applications that want a specified type of message without having to identify the applications or register them. To be able to do.
Message read and write operations on named pipes are automatic atomic operations. That is, once the ends of two pipes have been combined to send a message, a write-read operation by the pipe cannot interrupt any other sending application until the pipes are disconnected. This is an automatic feature that uses system functions to manage the actual transfer of messages.

FIG. 5 illustrates one particular embodiment using the present invention. This embodiment requires the use of one desktop computer process to provide message services to other processes running on the desktop computer. For example, this service can be used to transfer operational messages from a background process for logging and screen display to computer users. The message service provides the user with an integrated view of selected types of messages for processes that do not access the computer display screen. For example, this exemplary message service can be used to provide a solution to the problem of a separate software process in the OS / 2 (trademark of IBM) operating system. The detached process cannot currently output a screen without interrupting the operation of the computer. By definition, a separate process is not given a "screen" or "keyboard" for user I / O activity. This reduces system overhead. However, the detached process causes a problem in that it cannot communicate with the user without controlling the size of the screen, even when an abnormal state requires communication with the user, so that the screen transmission of another application occurs. Considerably interfere with. This message service allows the separate process to display a screen message to the user without the interference. The system console process 500 simply puts a window on the screen and displays the message without interference.

Specifically, the purpose of the system console process 500 is to provide a message of a specified type, eg type Z, to another process A running on that computer.
To D and display them on the display screen 510 intelligently and without interference. For example, the system
It can be assumed that the console process 500 is designed to display received messages in the order in which they are received, and to display them only in screen windows that do not interfere with other information displayed on the screen at the same time. is there. When the computer is turned on, the system console process 500 is loaded as a background process within that computer. One of its first actions is to generate the pipe name Z. The pipe name Z corresponds to the message type it wants to receive. One end of the pipe ends in the system console process 500. The other end conceptually terminates in a block of system functions 520, as in FIG. By design, all processes A-D in the system will have the following if they want to display errors, logging and general informational messages to the user.
Message type Z shows that this is possible. Thus, when such an event occurs in a process, even in a separate process, that process simply produces the desired message as type Z and makes the appropriate system call to the named pipe Z. Is sent through that pipe. As a result, system console process 500 receives the message and takes appropriate action to create a display window on display screen 510. The system console process 500 then displays a message in that window, alerts the user with a tone signal if necessary, and removes the window at the user's request. All this is done while the display process is managing this process for all messages of type Z it receives from any other known process.

Appendix A / ******************************************** ************************ / / * * / / * RECEIVE.C * / / * * / / ********* ************************************************** ********* / 1) #define INCL_DOS 2) #define INCL_DOSNMPIPES 3) #define INCL_DOSERRORS 4) #include <os2.h> 5) #include <stdio.h> 6) #define PIPE_SIZE 1024 7 ) #define MAX_PIPE_INSTANCES 5 8) #define X 3 9) #include "pipename.c" 10) int main (void) (11) USHORT rc; 12) HPIPE pipe_handle; / * Generate named pipe * / 13) rc = DosMakeNmPipe (/ * Create a pipe instance * / build_pipe_name (X), / * Get the pipe name of data type X * / & pipe_handle, / * Return the pipe handle * / 0U, / * OpenMode: Inward ( (Customer to server) * / / * Child can inherit * / MAX_PIPE_INSTANCES, / * Open in blocking mode * / 0U, / * advise outgoing buffer size * / PIPE_SIZE, / * specify incoming buffer size Advice * / 0x5000u1); / * DosWait Default timeout of NmPipe * / / * Wait for message on pipe * / 14) while (rc == NO_ERROR) (15) rc = DosConnectNmPipe (pipe_handle); / * Accept pipe DosOpen from sender * / / * Accept pipe Preparation * / / * OS / 2 blocks this action until the sender * / / * DosOpen this pipe instance * / / * Received message and its reading * / 16) while (rc == NO_ERROR) ( / * Keep reading from sender until all data is read * / / * Keep reading from sender * / 17) USHORT bytes_read; 18) static BYTE buffer [PIPE_SIZE]; 19) rc = DosRead (pipe_handle, buffer, sizeof buffer , &bytes_read); / * Read data from pipe * / 20) if (rc == NO_ERROR) (21) if (bytes_read == 0) / * No more data from sender * / {/ * pipe Reset * / 22) rc = DosDisConnectNmPipe (pipe_handle); 23) break; / * disconnect the current sender * /} 24) else / * show received data * / (25) write (1, buffer, byte_read); / * Write to ordinary output device # 1 * /}} / * if * /} / * while * /} / * while * / return 0;} / * main * / / * -------------------- end of file -------------------- * /

Appendix B / ******************************************** ************************ / / * * / / * SEND.C * / / * * / / ********* ************************************************** ********* / 1) #define INCL_DOS 2) #define INCL_DOSNMPIPES 3) #define INCL_DOSERRORS 4) #include <os2.h> 5) #include <stdio.h> 6) #define PIPE_SIZE 1024 7 ) #define MAX_PIPE_INSTANCES 5 8) #define X 3 9) #include "pipename.c" 10) int main (void) (11) HPIPE pipe_handle [MAX_PIPE_INSTANCES]; 12) USHORT rc; 13) PSZ pipename; 14) int i , number_of_instances = 0; / * Get PIPENAME * / 15) pipename = build_pipe_name (X); / * Get pipe name of data type X * / / * Combine all instances of this pipe name * / / * All A loop that joins the available pipe instances of * / / * * / 16) for (i = 0; i <MAX_PIPE_INSTANCES; + + i) {17) USHORT action_taken; 18) rc = DosOpen (/ * Join * / pipename, & (pipe_handle [number_of_instances]), & action_taken, 0UL, / * file size * / 1U, / * file attributes * / 1U, / * open flag: open if pipe exists * / / * fail if it does not exist * / 0x0041U, / * child Can inherit, does not reject any * / / * Write-only access * / 0UL / * reserve ULONG * /); 19) if (rc == NO_ERROR) {+ + number_of_instances;}} / * for * / 20) printf ("Number of instances =% u / n", number_of_instances); / * Write a message to each instance of this pipe name * / 21) for (i = 0; i <number_of_instances; + + i) { / * For each pipe instance: * / / * Write and detach * / 22) USHORT bytes_written; 23) static BYTE data [] = "Test Data"; 24) DosWrite (pipe_handle [i], data, sizeof data, &byte_written); / * Detach an instance of this pipe name * / 25) DosClose (pipe_handle [i]); / * Detach a pipe instance * /} / * for * / 26) return 0;} / * main * / / * ------------------- -end of file -------------------- * /

[Brief description of drawings]

FIG. 1 is a block diagram illustrating a prior art message distribution system that uses a registration approach.

FIG. 2 is a block diagram illustrating a system that uses named communication channels according to the present invention.

FIG. 3 is a flow diagram of a message receiving module having the code shown in Appendix A.

FIG. 4 is a flow chart of a message transmission module having the code shown in Appendix B.

FIG. 5 is a diagram showing an embodiment of a message distribution service according to the present invention.

[Explanation of symbols]

 100 computer system 102 message server 104 registration table 106 pipe 108 pipe 200 computer system 202 system function 206 RECEIVE module 208 SEND module 210 named pipe

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Christopher John Lennon United States 27511, Carrey, North Carolina, East Guerrell Court 104, etc. (72) Inventor Timothy Nelson Skags United States 27707, Durham, North Carolina Number E 5323 (72) Inventor Philip Anthony Smith 7308 Beacon Hill Court, Raleigh, NC 27604, USA

Claims (13)

[Claims] 1. A method of delivering a message between a message sending process and a message receiving process in a computer system, the receiving process terminating at one end of the receiving process and managed by the operating system of the computer system. Creating a communication channel to be assigned and assigning a system name to the channel corresponding to the message type that the receiving process wishes to receive via said channel; and the sending process to send a message of the selected message type is selected. A communication channel with a name corresponding to a different message type in the system; the sending process writing the message to the channel; and the receiving process writing from the channel to the message. A step of creating, opening, writing, and reading the channel, the steps of creating, opening, writing and reading the channel being performed by the operating system in response to a system function call by the process. 2. The method of transmitting a message between message transmitting / receiving processes according to claim 1, further comprising the step of putting the receiving process into a predetermined state waiting for a message, following the step of generating the communication channel. 3. The step of putting the receiving process into a predetermined state is executed by the operating system in response to a system function call by the receiving process, terminating one end of the channel in the receiving process, and transmitting by the operating system. 3. The method of delivering messages between message sending and receiving processes of claim 2, further comprising the step of waiting for acceptance of a channel open function call from the process. 4. The method of transmitting a message between message transmitting / receiving processes according to claim 2, further comprising the step of alerting the receiving process by a system semaphore in response to the transmission of the message via the communication channel. 5. The step of reading from the channel by a receiving process further comprises the step of reading a message information block from the channel each time it responds to a system function call after being alerted until an empty block is received. 4. A message transmission method between the message transmission / reception processes of 4. 6. The process of claim 1, wherein the step of opening a communication channel by the sending process further comprises the step of opening all communication channels in the system having a name corresponding to the message type being sent. Message delivery method. 7. The method of delivering messages between message sending and receiving processes of claim 6, wherein the step of writing a message to the channel includes the step of writing to all open channels having a name corresponding to the message type being sent. 8. A mechanism for a computer system to communicate a message between a message sending process and a message receiving process, means for creating a communication channel, means for naming the communication channel, and sending a message on the channel. Means for opening the channel at a first end of the channel for opening, and means for opening the channel at a second end for receiving a message from the channel,
System means for managing a communication channel between processes in the system by a system function call issued from the process, and means for a receiving process to generate a communication channel terminating at one end of the receiving process by utilizing the channel generating means. A means for the receiving process to assign to the channel a system name corresponding to the message type received by the receiving process via the channel utilizing the channel naming means, and the message type sent by the sending process. Means for opening a channel having a name corresponding to, a sending process for writing a message to said channel, a system means for alerting a message receiving process, and a receiving process for reading a message from said channel. Between message sending and receiving processes with Mechanism for transmitting the message. 9. The message sending / receiving process of claim 8 wherein the means in the sending process for opening the channel further comprises means for opening all instances of the channel having the same name corresponding to the message type being sent. A mechanism for transmitting messages. 10. The receiving processor further comprises means for resetting the channel after the receiving process receives the previous message so that the receiving process allows the sending process to send a later message using that channel. A mechanism for transmitting a message between the message transmission / reception processes of item 8. 11. A message sending device, used in a computer system for delivering a message from a sending process to a message receiving process via a named pipe terminating in the receiving process, said message sending device being managed by said system, said message sending device comprising: The system means includes means for opening any instance of a named pipe having a name corresponding to the message type sent by the sending process, and means for writing a message to each instance of the named pipe, the system means A message sending device including means for alerting a receiving process connected to each instance of an attached pipe. 12. An instance of a named pipe, after writing a message to the pipe instance,
The message transmission device according to claim 11, further comprising means for closing. 13. A message from a sending process to a message receiving process in a computer system,
A method of sending through a named pipe terminated by the receiving process and managed by the system, which opens any instance of the named pipe with a name corresponding to a message type sent by the sending process. A method of sending a message comprising the steps of: writing the message to each instance of the named pipe, and wherein the system means automatically alerts a receiving process associated with each instance of the named pipe of the message.