JPH10207724A - Distributed application execution program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To dynamically construct application space by executing the transfer of a message between processes constituting applications by identifying these processes without identifying a program to be a process generating source. SOLUTION: Message passing between distributed applications Ap1, Ap2 is executed through message passing operator parts M1, M2 and communication medium interface parts C1, C2. The ID of a distributed application execution system is specified and process ID for identifying one or plural processes generated by a program identified by the system ID is specified. Message transfer between processes can be executed by distinguishing a program constituting the distributed applications from another program driven on a remote procedure access system and identifying individual processes generated from the program constituting the distributed applications.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a distributed application execution system in a distributed processing system in which a plurality of nodes such as personal computers and workstations are organically connected via a network.

[0002]

2. Description of the Related Art An application executed in a distributed system is composed of a plurality of processes generated at individual nodes separated through a network. A process refers to the state of a running program and distinguishes it from a program simply as a sequence of instructions. The process occurs when the processor executes the original program.

When a distributed application execution system for executing a plurality of distributed applications is realized by using an existing inter-process communication technique, for example, a remote procedure call (remote procedure call; RPC), the following problem to be solved is obtained. There's a problem. That is, the procedure specified by the caller in the RPC is performed by identifying the program. This has a problem that it becomes a restriction when dynamically setting up a distributed application space composed of a plurality of processes.

[0004]

Accordingly, the present invention provides
An object of the present invention is to provide a distributed application execution system capable of dynamically setting up a distributed application space composed of a plurality of processes.

[0005]

[Means for Solving the Problems]

(1) The distributed application execution system of the present invention comprises:
In a distributed application execution system for executing an application for passing messages between processes existing on the nodes on a distributed processing system in which a plurality of computer nodes are connected via a network, a generation source of a process constituting the application First identification means for identifying a program, and second identification means for identifying at least one process generated by the program identified by the first identification means, and message passing between the processes is provided. Is characterized in that the process is specified by the identification of the program by the first identification means and the identification of the process by the second identification means.

[0006] With this configuration, message transfer between the processes constituting the application can be performed not by identifying the program that is the source of the process of the application but by identifying the process.
Therefore, for example, a plurality of processes generated from the same program can be identified and messages can be transferred between the processes.

[0007]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of a distributed application execution system according to the present invention will be described with reference to the drawings. First, in the first embodiment, message passing (message passing) between a plurality of processes constituting a distributed application is performed by a remote procedure call (RP
An example of a system configuration realized by C) will be described. In the second embodiment, an example of a system configuration in which message passing between a plurality of processes constituting a distributed application is realized by inter-process communication using a so-called socket interface will be described.

(First Embodiment) FIG. 1 is a logical configuration diagram showing an example of a distributed application execution system according to a first embodiment of the present invention. The distributed application execution system executes a distributed application on a distributed processing system in which an intranet having one or a plurality of (computer) nodes and various corresponding local networks are interconnected via the Internet. Things.

[0009] The distributed application execution system includes a plurality of processes separated by a network.
A specific process which is encompassed by a dashed line L in FIG. The distributed application execution system executes a plurality of distributed applications in the same space. Each distributed application has a plurality of execution processes, and performs message passing between these execution processes to cooperate.

FIG. 2 is a software configuration diagram for realizing a message passing function between such distributed applications. As shown in FIG. 2, the message passing between the distributed applications Ap1 and Ap2 is performed by the message passing operator units M1 and M1.
2 through the communication media interface units C1 and C2.

FIG. 3 is a block diagram showing a more specific configuration example for realizing such message passing. The distribution evaluation unit 10, the development tools (monitor and debugger) 11, and the system initializer 12 correspond to the application Ap1 (Ap2). The message passing operator unit 30 including the message dispatcher 31 and the message transmission request unit 32 corresponds to the message passing operator unit M1 (M2). The communication media interface 60 having the network interface 61 corresponds to the communication media interface C1 (C2).

In this embodiment, the communication media interface unit 60 performs a remote procedure call (RPC) to a communication media interface unit of another node via a communication medium 70 as shown in FIG. Has become.

Here, a communication media interface unit 6 for performing message passing by calling a remote procedure.
A specific configuration example of 0 will be described. FIG. 4 is a block diagram schematically showing a configuration in a case where message passing between processes is performed by calling a remote procedure between nodes (nodes A and B) separated via a network. Node A process and Node B
Both processes are components of one distributed application.

Here, a case where node A transmits a message to node B by calling a remote procedure will be described. As shown in the figure, both processes of the node A and the node B have a transmission thread 800 (70) for message passing by a remote procedure call.
0) and the receiving thread 400 (900), and the message processing thread 300 generated by the receiving thread
(600).

The communication media interface 500 of the reception thread 900 that receives a message transmission request as a procedure call request includes a reception preparation procedure 501, a dispatch procedure 502, an actual processing procedure 503, and an RPC 504. The RPC 504 is implemented as a runtime library called from the reception preparation procedure 501 or the dispatch procedure 502.
Input a message transmission request (procedure call request) transmitted from the message transmitting process via the port 505.

The reception preparation procedure 501 requests the RPC 504 to transfer control to the dispatch procedure 502 when a message arrives. The dispatch procedure 502 processes the procedure call request and calls the actual processing procedure 503. The actual processing procedure 503 generates the message processing thread 600 and generates the message dispatcher 601. The message dispatcher 601 processes a received message. The message processing thread 600 is executed by a thread different from the receiving thread 500. Therefore, the actual processing procedure 503 of the receiving thread 500 is immediately terminated, and the state immediately shifts to the next message waiting state. The receiving thread 400
Is configured in the same way as the receiving thread 900. FIG. 5 schematically shows the data structure of the procedure call request message processed by the message processing thread 600.

FIG. 6 is a flowchart showing the operations of the reception preparation procedure 501, the dispatch procedure 502, and the actual processing procedure 503. FIG.
9A is a flowchart illustrating the operation of the reception preparation procedure 501. First, in step S1, an RPC transport handle is obtained. This process is performed by designating the process ID of the own process as a parameter to the RPC 504.
By calling a predetermined library routine. The RPC transport handle has a specific data structure for maintaining information regarding communication. Next, in step S2, the dispatch procedure 502 is registered in the port map. This process is realized by specifying a parameter described below and calling a predetermined library routine of the RPC 504.

Specification parameters: RPC service transport handle Program number (distributed application execution system ID) Version number (process ID) Dispatch procedure Transmission protocol (TCP or UDP)

In step S3, the process proceeds to an event waiting process for waiting for a message given as a procedure call request. Here, when a message from the procedure calling process arrives, RPC becomes 5
04 passes control to the dispatch procedure 502.
Here, a C language source list of the reception preparation procedure 501 will be described as a more specific configuration example.

[0020] / ********************************************** ************ * cmirpc.x; Protocol definition file in ONC RPC language * rpcgen -b cmirpc.x ******************* **************************************** / struct packetInfo {opaque senderHostID [4]; / * Sender host ID * / u_long senderPID; / * sender process ID * / opaque receiverHostID [4]; / * receiver host ID * / u_long receiverPID; / * receiver process ID * / opaque msg <>; / * message body * /}; / ********************* * progran definition ****************** *** / program CMIPROG {version CMIVERS {int CMISVC (packetInfo) = 1; / * procedure number * /} = 1; / * version number (provisional) * /} = 0x211d1ae3; / * program number * / / ** ************************* * cmirpc.h; Header file ****************** ********** / #ifndef _CMIRPC_H_RPCGEN #define _CMIRPC_H_RPCGEN #include <rpc / rpc.h> struct packetInfo {char senderHostID [4]; u_long senderPID; char receiverHostID [4]; u _long receiverPID; struct {u_int msg_len; char * msg_val;} msg;}; typedef struct packetInfo packetInfo; #define CMIPROG ((unsigned long) (0x211d1ae3)) #define CMIVERS ((unsigned long) (1)) #define CMISVC ( (unsigned long) (1)) extern int * cmisvc_1 (); extern int cmiprog_1_freeresult (); / * the xdr functions * / extern bool_t xdr_packetInfo (); #endif / *! _CMIRPC_H_RPCGEN * / / ******* ************************************ * cmirpc_xdr.c; external data representation conversion routine **** **************************************** / #include "cmirpc.h" bool_t xdr_packetInfo (xdrs, objp) register XDR * xdrs; packetInfo * objp; {register long * buf; int i; if (! xdr_opaque (xdrs, objp-> senderHostID, 4)) return (FALSE); if (! xdr_u_long (xdrs, & objp-> senderPID)) return (FALSE); if (! xdr_opaque (xdrs, objp-> receiverHostID, 4)) return (FALSE); if (! xdr_u_long (xdrs, & objp-> receiverPID)) return (FALSE); if (! xdr_bytes (xdrs, (char **) & objp-> msg.msg_val, (u_int *) & obj p-> msg.msg_len, ~ 0)) return (FALSE); return (TRUE) ;} / **************************** * Receive preparation procedure *************** ************* / void cmilisten (u_long SelfProcessID) (SVCXPRT * transp; int sock = RPC_ANYSOCK; int proto = IPPROTO_TCP; / * Delete registration of specified program number and version number from port map Except * / (void) pmap_unset (CMIPROG, SelfProcessID); / * Get RPC service transport handle * / transp = svctcp_create (sock, 0, 0); if (transp == NULL) {exit (1);} / * Register the dispatch procedure in the portmap * / / * The second argument of svc_register () is the program number * The third argument is the version number.

* CMIPROG * (defined in the header file as a value of 0x2211d1ae), which is the application execution system ID, is designated as the second argument. * SelfProcessID, which is the process ID of the own process, is designated as the third argument.

* / If (! Svc_register (transp, CMIPROG, SelfProcessID, cmiprog, proto)) {exit (1);} / * Enter a loop waiting for a procedure call request * / svc_run (); exit (1);｝

FIG. 6B is a flowchart showing the operation of the dispatch procedure 502. In the dispatch procedure 502, a procedure number and an RPC service transport handle are specified as parameters. This process uses a predetermined library routine of the RPC 504.

First, in step S21, a branching process based on the procedure number is performed. That is, when “0” is designated as the procedure number, the process shifts to step S20, executes only the response process for returning the value, and ends. This procedure number “0” is reserved for a specific purpose, that is, for confirming the operation of the receiving side. If "1" is designated as the procedure number, the process proceeds to step S23, where the received argument (message) is decoded, and the process proceeds to step S24 to execute the actual processing procedure 50.
Call 3 Here, the decoded argument is specified, and the procedure called from the remote is called. Upon completion of the calling process, the process proceeds to step S26,
The memory area allocated by the decoding is released, and the process ends.

If a value other than "0" or "1" is designated as the procedure number, an error is generated. Here, as a more specific configuration example of the dispatch procedure 502, a C language source list of the procedure will be described.

/ ************************ * Dispatch procedure *************** ************* / static void cmiprog (struct svc_req * rqstp, SVCXPRT * transp) {union {packetInfo cmisvc_1_arg;} argument; char * result; bool_t (* xdr_argument) (), (* xdr_result) (); char * (* local) (); / * Separation by procedure number * / switch (rqstp-> rq_proc) {case NULLPROC: / * Procedure number 0: Response only without returning value * / (void ) svc_sendreply (transp, xdr_void, (char *) NULL); return; case CMISVC: / * Procedure number 1: * / xdr_argument = xdr_packetInfo; xdr_result = xdr_int; local = (char * (*) ()) cmisvc_1; break; default: / * Other * / svcerr_noproc (transp); return;} (void) memset ((char *) & argument, 0, sizeof (argument)); / * Decode received arguments * / if (! svc_getargs (transp, xdr_argument, & argument)) {svcerr_decode (transp); return;} / * Actual processing procedure * / Result = (* local) (& argument, rqstp); / * Encode the return value and send it to the caller * / if (result! = NULL &&! Svc_sendreply (transp, xdr_result, result)) (svcerr_systemerr (transp );} / * Free memory allocated by decoding * / if (! Svc_freeargs (transp, xdr_argument, & argument)) {exit (1);} return;}

FIG. 6C shows an actual processing procedure 503.
6 is a flowchart showing the operation of the first embodiment. The actual processing procedure 503 generates the message processing thread 600 in step S30, and passes an argument (message) to the message dispatcher 601. The message dispatcher 601 processes a message. The message processing thread 600 is executed by a thread different from the receiving thread 900. Therefore, the actual processing procedure 503 of the receiving thread 900 is immediately terminated, and the state immediately shifts to the next message waiting state. Here, a C language source list of the actual processing procedure 503 will be described as a more specific configuration example.

/ **************************** * Actual processing procedure ************** ************* / int * cmisvc_1 (packetInfo * packetInfoPtr, struct svc_req * rqstp) (struct packetInfo * packetInfoPtr2; int result; u_long tid; / * Allocate memory and arguments (message) * / PacketInfoPtr2 = (struct packetInfo *) malloc (sizeof (packetInfo)); memcpy (packetInfoPtr2, packetInfoPtr, sizeof (packetInfo)); packetInfoPtr2-> msg.msg_val = (char *) malloc (packetInfoPtr-> msg.msg_le n); memcpy (packetInfoPtr2-> msg.msg_val, packetInfoPtr-> msg.msg_val, packetInfoPtr-> msg.msg_len); / * Create a Message processing thread and pass the argument (message) * / result = thr_create (0, 0, (void * (*) (void *)) MessageDispatcher, packetInfo Ptr2, 0, &tid); return (&result);}

On the other hand, a transmission thread 800 for transmitting a procedure call request to a reception thread 900 of a process on which a procedure is called includes a message transmission request unit 100 and a communication media interface unit 200.
It is composed of Communication media interface unit 20
0 comprises a transmission procedure 201 and an RPC 202. The RPC 202 is implemented as a runtime library called from the transmission procedure 201,
The RPC 202 outputs the request message from the port 203 and sends it to the port 505 of the process on which the procedure is called. The transmission thread 700 is
The configuration is the same as that of the transmission thread 800.

FIG. 7 is a flowchart showing the operation of the transmission procedure 201. This transmission procedure 201
The transmission request unit 100 specifies a destination host ID, a process ID, and a message as parameters.

First, in step S40, a client handle is obtained. This client handle has a specific data structure for holding connection information with the receiving side. This processing is realized by calling a predetermined library routine of the RPC 202 by specifying the following parameters.

Designated parameters: Host ID Program number (distributed application execution system ID) Version number (process ID) Other (buffer size, etc.)

Next, in step S41, a remote procedure is called. This processing is realized by calling a predetermined library routine of the RPC 202 by specifying the following parameters.

Specified parameters:-Client handle-Procedure number-Argument encoding procedure-Argument body (message)-Return value decoding procedure-Return value storage field-Timeout time

Here, as a more specific configuration example of the transmission procedure 201, a C language source list of the procedure will be described.

[0036] / **************************** * Send procedure *************** ************* / int cmisend (const struct packetInfo * packetInfoPtr) {int clnt_res; CLIENT * clnt; struct sockaddr_in Sockaddr; static struct timeval TIMEOUT = {5, 0}; int sock = RPC_ANYSOCK ; memset ((char *) & Sockaddr, 0, sizeof (Sockaddr)); memcpy (& (Sockaddr.sin_addr.s_addr), packetInfoPtr-> receiverHostID, sizeof (u_long)); Sockaddr.sin_family = AF_INET; / * Get * / / * The second argument of clnttcp_create () is * the program number, and the third argument is the version number.

* Here, CMIPROG * (defined in the header file as a value of 0x2211d1ae) which is the application execution system ID as the second argument * packetInfoPtr-> which is the process ID of the receiving process as the third argument * Specify recei verPID.

* / If ((clnt = clnttcp_create (& Sockaddr, CMIPROG, packetInfoPtr-> receiver PID, & sock, 0, 0)) == NULL) {clnt_pcreateerror ("clnttcp_create"); return -1;} / * remote procedure Call * / if (clnt_call (clnt, CMISVC, (xdrproc_t) xdr_packetInfo, (caddr_t) packetInfoPtr, (xdrproc_t) xdr_int, (caddr_t) & clnt_res, TIMEOUT)! = RPC_SUCCESS) {clnt_perror (clnt, "call failed"); return 1;} return (clnt_res);}

In this embodiment, as described above, the program number is assigned to the distributed application execution system I.
D is specified, and the process number is specified as the version number. That is, in the present embodiment,
A distributed application execution system ID is designated as the first identification means, and the application execution system I
A process ID is designated as second identification means for identifying one or more processes generated by the program identified by D. With this configuration, a program constituting the distributed application is distinguished from other programs running on the remote procedure calling system, and individual processes generated from the program constituting the distributed application are identified and messages between the processes are identified. Can be delivered.

For example, as shown in FIG. 8, a distributed application execution system includes a plurality of nodes N1 to N4,
A plurality of programs Pg0 to Pg4 having distributed application execution system functions arranged in those nodes
(Having the same distributed application execution system ID). According to the present embodiment, the process P0 generated from those programs
To P5 can be identified, and processes P0 to P5 can be identified.
5 can be configured as independent distributed applications 1 and 2.

Thus, a distributed application execution system capable of dynamically setting up a plurality of distributed applications can be provided. (Second Embodiment) Next, a second embodiment of the present invention will be described. In the first embodiment, an example of a system configuration in which message passing between a plurality of processes constituting an application managed by a distributed application execution system is realized by a remote procedure call (RPC) has been described. In the following, a description will be given of an example of a system configuration in which message passing between a plurality of processes constituting the application is realized by inter-process communication using a so-called socket interface.

FIG. 9 is a block diagram schematically showing a configuration in which message passing is performed between nodes (nodes A and B) separated via a network by inter-process communication using a socket interface. Both the process on the node A side and the process on the node B side are components of one application.
As shown in the figure, both processes of the node A and the node B have a transmission thread 500 for message passing using inter-process communication by a socket interface.
1 (5000) and receiving thread 8000 (800
1) and a message processing thread 4000 (9000) generated by the receiving thread.

The transmission thread 5001 is the transmission request unit 100
0 and a communication media interface unit 2000. Communication media interface unit 2000
Comprises a transmission procedure 2001, a port number management request procedure 2002, and a socket library routine 2003. Transmission thread 5000
Is configured similarly to the transmission thread 5001.

The reception thread 8001 includes a port number management request procedure 3001 and a reception procedure 300
2 and a communication media interface unit 3000 including a socket library routine 3003.
The message processing thread 4000 called from the reception procedure 3002 is the message dispatcher 4
Call 001. The message processing thread 4000 and the message dispatcher 4001 correspond to the message processing thread 6 described in the first embodiment.
00 and the message dispatcher 601.

The port number management process 6000 includes a port number table management procedure 6001 and a port number table 6
002 and a socket library routine 6003. The port management process 7000 has the same configuration as the port management process 6000.

FIG. 10 is a flowchart showing the operations of the transmission procedure 2001 and the port number management request procedure 2002. FIG. 10A is a flowchart showing the operation of the transmission procedure 2001. The transmission procedure 2001 is designated by the transmission destination host ID, the transmission destination process ID, and the message as parameters, and is called by the transmission requesting unit 1000. First, in step S70, the port number management process 600
Inquires about the port number for 0. That is, the port number management request procedure 2002 is called. Here, the application execution system ID and process I
Inquire about the port number corresponding to D.

Next, in step S71, a socket for transmitting a message is created. Here, a connection request is issued by designating the port number obtained by the inquiry processing in step S70. In a succeeding step S72, the message is transmitted. Here, first, message data having the data structure shown in FIG. 5 is transmitted. Then, the result is received in step S73. Here, a C language source list of the transmission procedure 2001 will be described as a more specific configuration example.

[0048] / ****************************** * Header file ************* ***************** / #include <stdlib.h> #include <errno.h> #include <sys / types.h> #include <sys / socket.h> #include <sys / uio.h> #include <netinet / in.h> struct portInfo {int flag; / * 0: Register port number 1: Query port number * / u_long progID; / * Application execution system ID * / u_long processID; / * process ID * / u_short portNo; / * port number * /}; #define CMIPROG ((unsigned long) (0x211d1ae3)) struct packetInfo {u_long senderHostID; u_long senderPID; u_long receiverHostID; u_long receiverPID; struct {u_int msg_len ; char * msg_val;} msg;}; / **************************** * Send procedure ******** ******************* / int cmisend (const struct packetInfo * packetInfoPtr) {struct sockaddr_in ports, socks; int Sock, addrlen, nByteRecv, nByteSend, result, portNo; struct portInfo PortInfo; / * Queries the port number management process for the port number. * / PortInfo.flag = 1; PortInfo.progID = CMIPROG; / * Defined in header file * / PortInfo.processID = packetInfoPtr-> receiverPID; portNo = cmiportreq (packetInfoPtr-> receiverHostID, &PortInfo); if (portNo == -1) {return -1;} / * Create a socket for sending messages * / Sock = socket (AF_INET, SOCK_STREAM, 0); socks.sin_addr.s_addr = packetInfoPtr-> receiverHostID; socks.sin_family = AF_INET; socks.sin_port = htons (portNo); / * Connect to the destination port number obtained by the query * / connect (Sock, (struct sockaddr *) & socks, sizeof (socks)); / * Send packetInfo * / nByteSend = send (Sock, (char *) packetInfoPtr, sizeof (struct packetInfo), 0); / * Send message body * / nByteSend = send (Sock, (char *) packetInfoPtr-> msg.msg_val, packetInfoPtr-> msg.msg_len, 0); / * Receive result * / nByteRecv = recv (Sock, (char *) & result, sizeof (result), 0); close (Sock); return result;}

FIG. 10B is a flowchart showing the operation of the port number management request procedure 2002. This procedure is called from the transmission procedure 2001 with the following parameters specified.

Designated parameters: • Host ID • Request content (registration or inquiry) • Application execution system ID • Process ID • Port number

First, in step S80, a socket for request transmission is created. Here, a connection request is issued by designating a port number reserved for the port number table management procedure 6001 (“8888” is reserved as described later). Next, a request is transmitted in step S81, a result is received in step S82, and a step S83 is performed.
In the transmission procedure 2001 which is the caller,
Returns the reception result for. Here, as a more specific configuration example of the port number management request procedure 2002, a C language source list of the procedure will be described.

/ ************************************* * Port number management request procedure *** ********************************** / int cmiportreq (u_long HostID, struct portInfo * portInfoPtr) {struct sockaddr_in ports ; int portSock, addrlen, nByteRecv, nByteSend, result; / * Create socket for sending request * / memset ((char *) & ports, 0, sizeof (ports)); portSock = socket (AF_INET, SOCK_STREAM, 0); ports.sin_addr.s_addr = HostID; ports.sin_family = AF_INET; ports.sin_port = htons (8888); / * Connect to the port of the port number management process * / connect (portSock, (struct sockaddr *) & ports, sizeof (ports)); / * Send request * / nByteSend = send (portSock, (char *) portInfoPtr, sizeof (* portInfoPtr), 0); / * Receive result * / nByteRecv = recv (portSock, (char *) & result, sizeof (result), 0); close (portSock); if (result <0) {printf ("portreq error:% d \ n", result); return -1;} return result;}

FIG. 11 is a flowchart showing the operation of the port number table management procedure 6001 and the reception procedure 3002. FIG. 11A is a flowchart showing the operation of the port number table management procedure 6001. This procedure performs port number registration processing or port number inquiry processing in response to a request from the port number management request procedure 2002 of the transmission thread.
First, in step S50, a socket for receiving a request is created. Here, the port number management process 6000
Port number reserved here ("8888" here)
To create a socket.

Next, in step S51, a request reception is waited, and if a management request is received here, step S5 is performed.
Move to 2. In step S52, the request is determined from the parameters specified by the port number management request procedure 2002, and the process is performed. That is, when the request content is “port number registration request”, the process proceeds to step S53, and the application execution system ID, the process ID and the port number are stored in the port number table 6002. If the request is a "port number inquiry request", the process proceeds to step S54, and the port number table 6002 is searched for a port corresponding to the application execution system ID and the process ID of the designated parameter. If the corresponding port is found, return the port number.

Then, in step S55, after transmitting the result to the port number management request procedure 2002 which is the calling source, the flow shifts to step S51 to wait for the reception of the request again. Here, as a more specific configuration example of the port number table management procedure 6001, a C language source list of the procedure will be described.

#Include "port.h" / *************************************** ***************** * Port number table management procedure * ************************** ****************************** / #define PORTTABLE_MAX 256 void main () {struct sockaddr_in listens, news; int i, listenSock , newSock, addrlen, opt, nByteRecv, nByteSend, result; struct portInfo PortInfo; struct portTable {/ * Port number table * / u_long progID; u_long processID; u_short portNo;} PortTable [PORTTABLE_MAX]; int portTable_tail = -1; / * Create socket for receiving request * / listenSock = socket (AF_INET, SOCK_STREAM, 0); opt = 1; setsockopt (listenSock, SOL_SOCKET, SO_REUSEADDR, (char *) & opt, sizeof (int)); memset ((char *) & listens , 0, sizeof (listens)); listens.sin_addr.s_addr = htonl (INADDR_ANY); listens.sin_family = AF_INET; listens.sin_port = htons (8888); / * Specify the port for the port number management process * / bind (listenSock, (struct sockaddr *) & listens, sizeof (listens)); listen (listenSock, 5); a ddrlen = sizeof (struct sockaddr_in); while (1) {/ * Waiting to receive request * / newSock = accept (listenSock, (struct sockaddr *) & news, &addrlen); / * Receive request * / nByteRecv = recv (newSock, (char *) & PortInfo, sizeof (PortInfo), 0); switch (PortInfo.flag) {case 0: / * Port number registration request: Store application execution system ID, process ID, and port number in port number table * / if (portTable_tail == PORTTABLE_MAX-1) {result = -1; break;} for (i = 0; i <= portTable_tail; i ++) {if (PortTable [i] .progID == PortInfo.progID && PortTable [i] .processID == PortInfo.processID) {break;}} if (i <= portTable_tail) {/ * already exists: overwrite * / PortTable [i] .portNo = PortInfo.portNo;} else {/ * not: new registration * / PortTable [++ portTable_tail] .processID = PortInfo.processID; PortTable [portTable_tail] .progID = PortInfo.progID; PortTable [portTable_tail] .portNo = PortInfo.portNo;} result = 0; break; case 1: / * Port number Inquiry request: port number table Is retrieved by application execution system ID and process ID, and the corresponding port number is returned. * / Result = -1; for (i = 0; i <= portTable_tail; i ++) {if (PortTable [i] .progID == PortInfo .progID && PortTable [i] .processID == PortInfo.processID) {result = PortTable [i] .portNo; break;}} break; default: result = -1; break;} / * Send result * / nByteSend = send (newSock, (char *) & result, sizeof (result), 0); close (newSock);} / * while * /}

FIG. 11B shows a reception procedure 300.
6 is a flowchart showing the operation of No. 2. For this procedure, its own process ID and its own host ID are specified as parameters.

First, in step S60, a socket for receiving a message is created. Next, in step S61, the port number management process 6000 is requested to register a port number. That is, the port number assigned for message reception is checked, and the port number, application execution system ID, and process ID are requested to be registered to the port number management process of the host.
This processing is performed by the reception procedure 3002 calling the port number management request procedure 3001. Next, in step S62, the process waits for message reception. Here, when a message is received, a memory area for storing the message is secured, and the message body is written in the area.

Next, in step S63, a message processing thread 4001 is generated, and an argument (ie, message) is passed. Here, message processing is performed by the message dispatcher 4001 as described above. Then, the process shifts to step S64 to transmit the result to the transmission thread side. Here, as a more specific configuration example of the reception procedure 3002, a C language source list of the procedure will be described.

[0060] / **************************** * Receive procedure * ************** ************* / void cmilisten (u_long selfProcessID, u_long selfHostID) {struct sockaddr_in listens, news; int i, listenSock, newSock, addrlen, nByteRecv, nByteSend, result; struct packetInfo * packetInfoPtr; struct portInfo PortInfo; u_long tid; / * Create socket for receiving messages * / memset ((char *) & listens, 0, sizeof (listens)); listenSock = socket (AF_INET, SOCK_STREAM, 0); listens.sin_addr.s_addr = htonl (INADDR_ANY); listens.sin_family = AF_INET; listens.sin_port = htons (0); bind (listenSock, (struct sockaddr *) & listens, sizeof (listens)); / * Check the assigned port number * / addrlen = sizeof (struct sockaddr_in); getsockname (listenSock, (struct sockaddr *) & listens, &addrlen); / * Request registration to port number management process * / PortInfo.flag = 0; PortInfo.progID = CMIPROG; / * In header file Defined * / PortInfo.processID = selfProcessID ; PortInfo.portNo = listens.sin_port; if (cmiportreq (selfHostID, & PortInfo) == -1) {exit (1);} listen (listenSock, 5); while (1) {/ * Wait for message reception * / newSock = accept (listenSock, (struct sockaddr *) & news, &addrlen); / * Read packetInfo and get message body length * / packetInfoPtr = (struct packetInfo *) malloc (sizeof (struct packetInfo)); nByteRecv = recv (newSock, (char *) packetInfoPtr, sizeof (struct packetInfo), 0); / * Read message body * / packetInfoPtr-> msg.msg_val = (char *) malloc (packetInfoPtr-> msg.msg_l en); nByteRecv = recv (newSock , (char *) packetInfoPtr-> msg.msg_val, packetInfoPtr-> msg.msg_len, 0); / * Create a message processing thread and pass the argument (message) * / result = thr_create (0,0, (void * (*) (void *)) MessageDistributer, packetInfoPtr, 0, &tid); / * Send result * / nByteSend = send (newSock, (char *) & result, sizeof (result), 0); close (newSock);} / * while * /}

As described above, according to the second embodiment in which message passing between a plurality of processes is realized by inter-process communication using a so-called socket interface,
Since the message transmission destination is specified by specifying the application execution system ID and the process ID, logically, compared with the case where the message is physically specified using the address and port number of the host by the normal method of the socket interface, And it can be done flexibly. The present invention is not limited to the above-described embodiment, and can be implemented with various modifications.

[0062]

As described above, according to the present invention, a distributed application execution system capable of dynamically setting up a distributed application space composed of a plurality of applications can be provided.

[Brief description of the drawings]

FIG. 1 is a logical configuration diagram of a distributed application execution system according to a first embodiment of the present invention.

FIG. 2 is a software configuration diagram for realizing a message passing function between applications according to the first embodiment.

FIG. 3 is a block diagram showing a more specific configuration example for realizing message passing according to the first embodiment.

FIG. 4 is a block diagram schematically showing a configuration in a case where message passing between processes is performed by a remote procedure call between nodes (nodes A and B) separated via a network according to the first embodiment. FIG.

FIG. 5 is a diagram schematically showing a data structure of a procedure call request message processed by the message processing thread 600 according to the first embodiment.

FIG. 6 is a flowchart showing operations of a reception preparation procedure 501, a dispatch procedure 502, and an actual processing procedure 503 according to the first embodiment.

FIG. 7 is a transmission procedure 20 according to the first embodiment.
3 is a flowchart showing the operation of FIG.

FIG. 8 is a schematic diagram showing a configuration example of a distributed application according to the first embodiment.

FIG. 9 is a block diagram showing a more specific configuration example for implementing message passing according to the second embodiment of the present invention.

FIG. 10 is a flowchart showing operations of a transmission procedure 2001 and a port number management request procedure 2002.

FIG. 11 is a flowchart showing operations of a port number table management procedure 6001 and a reception procedure 3002.

[Explanation of symbols]

 L: Distributed application execution system Ap1, Ap2: (Distributed) application M1, M2: Message passing operator unit C1, C2: Communication media interface unit 10: Distributed evaluation unit 11: Development tool 12: System initializer 13: Message delivery interface unit 20 ... Message evaluation scheduler 30 ... Message passing operator unit 31 ... Message dispatcher 32 ... Message transmission request unit 60 ... Communication media interface unit 61 ... Network interface 70 ... Communication media 100 ... Transmission request unit 200,500 ... Communication media interface unit 201 ... Transmission Procedures 202, 504: RPC 203, 505: Port 300, 600 ... Message processing thread 400 900 ... reception thread 501 ... reception preparation procedure 502 ... Dispatch procedure 503 ... actual processing procedure 601 ... message dispatcher 700, 800 ... send thread

Claims (3)

[Claims] 1. A distributed application execution system for executing an application for transferring a message between processes existing on a distributed processing system in which a plurality of computer nodes are connected via a network, wherein the application is configured. First identification means for identifying a program that is a generation source of a process to be performed, and second identification means for identifying at least one process generated by the program identified by the first identification means, The distributed application execution is characterized in that the message transfer between the processes is performed by specifying the destination of the message by the identification of the program by the first identification means and the identification of the process by the second identification means. system. 2. The method according to claim 1, wherein the message transfer is performed by a remote procedure call, and a communication port is allocated to the remote procedure call by identifying the program by the first identification means and identifying the process by the second identification means. The distributed application execution system according to claim 1, wherein the message is sent to the communication port. 3. The message passing is performed by inter-process communication using a socket interface, and the assignment of a communication port to the socket interface is performed by identifying the program by the first identification unit and by using the process identification by the second identification unit. 2. The distributed application execution system according to claim 1, wherein the identification is performed.