Figure 1: Clients and servers
Ninf-G uses the Globus Toolkit to provide a running environment for GridRPC.
GridRPC is middleware that provides a model for access to remote libraries and parallel programming for tasks on a grid. Typical GridRPC middleware includes Ninf and Netsolve.
GridRPC is considered effective for use in the following cases.
Commercial programs or libraries that use resources which are on particular computers on the grid are sometimes provided only in binary format and cannot be executed on particular computers. There are also problems concerning licensing and source code compatibility. Furthermore, when using resources that can only be used with particular machines, such as video cameras, electron microscopes, telescopes and sensors, processing for the use of those resources on those machines is necessary.
In such cases, an environment that allows the resources (including software) to be used on a particular computer is needed.
When there are many programs that execute routines that do a large amount of computation on broadband servers on the grid, it takes much time just to run parts of the program.
The time required to run the program can be shortened by off-loading such parts to a broadband server.
In cases when there are strong demands on memory and disk space on the client machine so that broadband computation cannot be done, it is desirable to be able to do easily understood offloading with no consideration given to argument marshalling.
Execution of Parameter Sweep by multiple servers on the grid
Parameter Sweep is execution of computation on multiple servers in parallel using some subset of the parameters. The respective servers run independently using different parameters, with virtually no dependence on other servers.
There are surprisingly many programs like Parameter Sweep.
The Monte Carlo method is one of them.
Although Parameter Sweep can also be implemented with a Message Passing Interface (MPI), programming is rather simple with GridRPC and it can be executed to match the (dynamically changing) scale of the grid (execution by multiple clusters, taking resource management, security, etc. into account).
Ordinary or large-scale task parallel programs on a grid
Task arrangement programs are easy to write with GridRPC. An API that supports the synchronization of various task arrangements with mixed exchange among multiple clients and servers can be used.
GridRPC not only provides an interface for easy mathematical computation and scheduling of tasks for parallel execution, but the execution of processing that matches the (dynamically changing) scale of the grid is possible, as in the case of Parameter Sweep.
Ninf-G is a set of library functions that provide an RPC capability in a Grid environment based on theGridRPC API specifications.
Ninf-G and the application programs that use Ninf-G consist of Ninf-G Executables that execute computation on server machines and Ninf-G Clients that issue requests for computation to the Ninf-G Executables from client machines.
The Ninf-G Executables consist of functions that perform calculations (calculation functions) and a Ninf-G stub program that calls the calculation functions. Communication between clients and servers is accomplished by TCP/IP using a proprietary Ninf-G protocol.
The relationships between clients and servers is illustrated in Fig. 1.
Figure 1: Clients and servers
Ninf-G employs the capabilities provided by the Globus Toolkit (http://www.globus.org/) for server machine authentication, information search, job start-up, communication and file transfer. The relations among applications, the Ninf-G, Globus Toolkit and the OS are illustrated in Fig. 2.
Figure 2: Program hierarchy
Ninf-G Clients comprise the following elements.
Ninf-G Executables comprise the following elements.
Ninf-G is supplied to the user as a source package, which includes the library functions (API) and utility commands. The operating conditions for the library functions and utility commands are shown in Table 1.
| Globus Toolkit | 2.2 or later |
| - | - |
| Target machine | SPARC |
| Operating system | Solaris 5.9 |
| Compiler | Sun Compiler or gcc-2.95 |
| Globus Toolkit Flavor | vendorcc32dbg, vendorcc32dbgpthr, gcc32dbg, gcc32dbgpthr |
| - | - |
| Target machine | PC-AT compatible (x86, IA64, Opteron) |
| Operating system | Linux(*1) |
| Compiler | gcc-2.95, gcc-3.x(*2) |
| Globus Toolkit Flavor | gcc32dbg, gcc32dbgpthr, gcc64dbg, gcc64dbgpthr |
| - | - |
| Target machine | SGI Origin 2000 (MIPS) |
| Operating system | IRIX64 6.5 |
| Compiler | SGI Compiler |
| Globus Toolkit Flavor | vendorcc64dbg or vendorcc64dbgpthr |
| - | - |
| Target machine | HP Alpha |
| Operating system | Tru64 UNIX(OSF1 V5.1) |
| Compiler | Compaq C or gcc 3.x |
| Globus Toolkit Flavor | vendorcc64dbg or gcc64dbg |
| - | - |
| Target machine | IBM Power4 |
| Operating system | AIX 5.2 |
| Compiler | gcc 2.9 |
| Globus Toolkit Flavor | gcc32dbg |
(*1) We are checking operating by the following distributions.
(*2) There are problems with gcc-2.96, so we recommend you to use gcc-2.95.x or gcc3.x.
Ninf-G allows the definition of a single computation function (1) or multiple computation functions (2) for a Ninf-G Executable running on a server machine. The execution schemes for these are shown in Fig. 3. In either case, it is possible to execute, just one computation function at a time on the Ninf-G Executable. To execute multiple computation functions at the same time, it is necessary to run multiple Ninf-G Executables. This is illustrated in Fig. 4.
In Ninf-G, the second scheme (2) is referred to as "Ninf-G Executable objectification" and the calling of the computation is referred to as a "method call".
Figure 3: Overview of operation
Figure 4: Parallel execution
Ninf-G provides handles for manipulating a Ninf-G Executable. Different handles are used for two schemes, (1) and (2), described above. As shown in Table 2, two types of handles are provided, function handles and object handles.
| Function handle | Used for manipulation of a Ninf-G Executable for which a single function is defined |
| Object handle | Used for manipulation of a Ninf-G Executable for which a multiple functions are defined |
Ninf-G Executables that run on server machines are started up from Ninf-G clients, which run on client machines. A Ninf-G Executable is started up by performing the following procedure using the job control method provided by the Globus Toolkit.
When running a Ninf-G Client program, however, there is no particular need for the user to be aware of this mechanism.
This process is shown in Fig. 5.
Figure 5: Starting up a Ninf-G Executable
Starting up a Ninf-G Executable requires path information that specifies the location of the Ninf-G Executable on that server machine. Information on the functions that are called by the Ninf-G Executable is also required. That information is collectively referred to as the Ninf-G Executable information. Ninf-G provides the following methods of registering and accessing Ninf-G Executable information.
When running a Ninf-G Client program, however, there is no particular need for the user to be aware of this mechanism.
Figure 6: Local LDIF file
Figure 7: Ninf-G Executable
(*) The information search function provided by the Globus Toolkit.
Figure 8: MDS
This is a program written by a user for the purpose of controlling the execution of computation. It is obtained by linking a user-written application program to the Ninf-G Client Library (and Globus Toolkit).
The Ninf-G Client Library puts together the API used by application programs that run on client machines (Ninf-G Client API).
This is a program written for the execution of user requests for computation to be performed on a remote computer. It is obtained by linking a user-written computation function to stub code and the Ninf-G Executable Library (and Globus Toolkit). The stub code is produced by the stub generator according to the interface specifications of the user-defined computation function. The interface specifications are written in the Ninf-G IDL (Interface Description Language) specified by Ninf-G.
The Ninf-G Executable Library puts together the API (Ninf-G Executable API) used by Ninf-G Executable.
A machine that is running a Ninf-G Client.
A machine that is running a Ninf-G Executable.
A function handle is a data whose type is grpc_function_handle_t. The function handle represents a mapping from a function name to an instance of that function on a particular server.
A object handle is a data whose type is grpc_object_handle_t_np. The object handle represents a mapping from a class name to an instance of that class on a particular server. The instance is called Ninf-G remote object which is able to contain multiple methods.
A computational function written by the user. (It might be only a single computation function for a Ninf-G Executable)
A computational function written by the user. (It might be multiple computation functions for a Ninf-G Executable)
A session extends from the time an RPC is made to the time its execution is completed.
In Ninf-G, a session extends
This is the standard API that systems implementing GridRPC should have. Concerning the GridRPC C language API, standardization by the GGF WG is proceeding.
IDL is the acronym for Interface Definition Language. It is a language for writing interfaces for the remote functions and remote methods defined by Ninf-G Executables.
This is the identifier for Ninf-G Executables. The user may specify any character string in the Ninf-G IDL.
Previously, only one remote method could be defined for one Ninf-G Executable, but it is now possible to implement multiple remote methods. Furthermore, a mechanism for preserving state has been added to Ninf-G Executable, and it is now possible for multiple remote methods to share variable values, etc. within a Ninf-G Executable.
The settings and the description format are completely new and allow more detailed settings. Also, considering execution that makes use of multiple servers, the format allows for the description of information on multiple servers.
This function can obtain information on a Ninf-G Executable without querying the MDS by either saving a file on the client machine that contains information on the Ninf-G Executable to be run and reading that file, or by using the path information to start up the Ninf-G Executable on the server and obtaining the information from the Ninf-G Executable.
A function for creating multiple handles by calling GRAM just one time is provided. (The cost of calling GRAM is high, so reducing the number of times it is called should reduce start-up time.)
A function for preserving the execution form of a Ninf-G Executable on a client machine, transferring that format to the server when GRAM is called, and running the executable is provided.
A function for executing a function on a Ninf-G Client from a Ninf-G Executable is provided. The status of the Ninf-G Executable on the Ninf-G Client can be obtained and the states of variables can be input and output.
A session can be terminated in progress by requesting cancellation of the session. (Ninf-G v1 only provides a means of killing a Ninf-G Executable with a signal to stop processing; it is not possible to end a session.)
Ninf-G Executables send a heart-beat signal to Ninf-G Clients at fixed time intervals, thus making it possible for clients to detect when execution is halted for any reason.
The versions are source code compatible. Client-side application programs and server-side remote function programs that are used with Ninf-G v1 can be used without modification.
However, those programs must be recompiled with Ninf-G v2 to generate the executable file, etc. so they will run under Ninf-G v2.
The names of environment variables have been changed from NS_DIR to NG_DIR. Also, in addition to setting the environment variables, it is necessary to read in the environment settings file ${NG_DIR}/etc/ninfg-user-env.{sh,csh}.
Note: The environment variable NG_PATH in the setting file is internally defined and used by Ninf-G system. Users must not explicitly define and use the environment variable NG_PATH.
The prefix has been changed from "ns_" to "ng_". The names of the utility commands are listed below.
| Ninf-G v1 | - | Ninf-G v2 |
|---|---|---|
| ns_client_gen | -> | ng_cc |
| ns_gen | -> | ng_gen |
| ns_delete_functions | -> | ng_delete_functions |
| ns_dump_functions | -> | ng_dump_functions |