Remote Context Creation Using Globus GRAM

Introduction

We present a very simple example to illustrate how the Globus based HPC++ (called HPC++ in this example) can be used for remote context creation. HPC++ uses the Globus GRAM (Globus Resource Allocation Manager) service for creating remote contexts. The main component of GRAM is a server process, called the Gatekeeper which typically runs on the machine on which the user wants to create a context. The Gatekeeper has the responsibity to authenticate the user and then satisfy her request.

The example follows a very simple scenario where a client object invokes remote requests on a server object. (Although this example shows two objects communicating with each other, it is not necessary for contexts to create objects in order to communicate. Two contexts can communicate with each other simply by invoking each others' global functions.)

Building The Example

The example is divided into three directories:
  • Common: Contains classes that are required by both the client and server and are of a utility nature. They include implementation of the classes HPCxx_String and hpcxx_byte.
  • GramClient: The client side code.
  • GramServer: The server side code.
  • The Example can be compiled on three different architectures: SGI Irix 64 bit, SGI Irix 32 bit and Sun Solaris 2.6. In order to build the example for a specific architecture, you need to edit the file "Makefile.base" in the example's root directory, as specified in that file. The modifications are fairly simple and involve uncommenting a few lines depending on the architecture at hand, and specifying some standard paths for HPC++, Globus etc. The file contains sample paths that are applicable for the environment of the Extreme! Lab at Indiana University. Next, just type in "make" at the command prompt to build the client side and the server side code. "make" will go through all the three directories and build the client and the server executables. The executables are built in directories depending on the specific architectures. For example, for SGI 64 bit architecture, the client executable goes in "GramClient/sgi64" directory and the server executable goes in "GramServer/sgi64" directory. Similarly, Solaris and SGI 32 bit executables go in "Gram*/solaris" and "Gram*/sgi32" directories respectively.

    Running The Example

    Running the example consists of starting the client from the command line with three arguments: full name of the machine on which the Globus Gatekeeper is running, full name of the target machine on which the context is to be created, and the full path name for the executable on the target machine.

    For example, if a client running on a Solaris machine wants o create a context on an SGI 64 bit machine named "bread.extreme.indiana.edu", using the Gatekeeper on the machine "bread.extreme.indiana.edu", following will be the command:

    GramClient/solaris/GramClient bread.extreme.indiana.edu bread.extreme.indiana.edu \ /scratchB/sdiwan/NewGramExample/GramServer/sgi64/GramServer

    The file "Makefile" in the example's root directory provides several sample "run targets" that are used in the Extreme! Computing Lab at Indiana University.

    By default, the client's print statements appear in the command shell from which the client is started. The server's "standard out" print statements go to the file "~/GramServer.out", while the server's "standard error" print statements go to the file "~/GramServer.err". This is currently hard-coded in the function hpcxx_createContext, but users will be able to customize it later on.

    Source Code for The Example

    Client Side Code

    The client side code consists of the following tasks:
  • Initialize HPC++ by calling hpcxx_init. This function must be called exactly once by a context before doing any HPC++ related activity.
  • Parse the command line arguments to figure out the Gatekeeper's and the new context's machine, and also the new context's executable path.
  • Instantiate a client object to communicate with the server.
  • Initialize the client object. This function registers all the functions that will be called through remote method invocation. HPC++ requires that all remotely invoked functions be registered with the HPC++ run-time so that they can be properly delivered to the server context.

    This function also initializes Globus by calling gs_init. This function must be called exactly once by a context before using any Globus related services through HPC++.
  • Create a new context by calling the HPC++ function hpcxx_createContext. This function returns a context ID for the server context.
  • Use the context ID to make the remote function call returnServerGp on the server context. This function returns a global pointer to the server object.
  • Use the global pointer to invoke the method sayHello on the server object in the server context.
  • Call killMe on the server object to make the server context to exit.
  • Finally, the context exits by calling hpcxx_exit.
  • This client side code is divided among the following source files:
  • Main.C: This is the main client program
  • Client.h: Header file for the Client class
  • Client.C: Source file for the Client class
  • Server Side Code

    The server context is created by the client context. After creation, it performs the following tasks:
  • Initialize the context by calling hpcxx_initAgent. Every context created by another HPC++ context (through hpcxx_createContext ) must call this function exactly once to initialize HPC++ related services. Note that this function is different from hpcxx_init, which is called by any HPC++ context not created through hpcxx_createContext.
  • The server object is created as a global object and as such will be instantiated when the server context starts.
  • Parse the command line arguments to figure out the host on which the server has started running. HPC++ sends a standard set of command line arguments to the newly created context.
  • Register all the functions that will be invoked by remote clients.
  • Service remote requests from the client.
  • Exit this context (by calling hpcxx_exit) when the killme function is called.
  • This server side code is divided among the following source files:
  • Main.C: This is the main server program
  • Server.h: Header file for the Server class
  • Server.C: Source file for the Server class
  • Common Code

    The directory "Common" contains utility classes used by both the client and the server. It has two parts:
  • HPCxx_String class: This is used to send C++ strings among communicating contexts.
  • HPCxx_String.h: Header file for the class HPCxx_String
  • HPCxx_String.C: Source file for the class HPCxx_String
  • hpcxx_byte class: This is used internally by the HPC++ system for communication.
  • hpcxx_byte.h: Header file for the class hpcxx_byte
  • hpcxx_byte.C: Source file for the class hpcxx_byte
  • Later on, these classes may become a part of the standard HPC++ distribution, thus removing the need for the "Common" directory.

    Download the Complete Example

    This is a gzipped tar file.
    hpc++@extreme.indiana.edu

    Last modified: Fri Feb 12 11:03:04 EST 1999