grid 02keith

Overview of GridRPC: A Remote Procedure Call API for Grid Computing: 

Overview of GridRPC: A Remote Procedure Call API for Grid Computing Keith Seymour Hidemoto Nakada Satoshi Matsuoka Jack Dongarra Craig Lee Henri Casanova

Collaborators: 

Collaborators Hidemoto Nakada National Institute of Advanced Industrial Science and Technology (AIST) Tokyo Institute of Technology Satoshi Matsuoka Tokyo Institute of Technology National Institute of Informatics Craig Lee The Aerospace Corporation Henri Casanova San Diego Supercomputer Center UCSD

Introduction: 

Introduction Provide standardized, portable, and simple programming interface for Remote Procedure Call Attempt to unify client access to existing grid computing systems (such as NetSolve and Ninf-G) Working towards standardization through GGF WG Initially standardize API; later deal with protocol Standardize only minimal set of features; higher-level features can be built on top Provide several reference implementations Not attempting to dictate any implementation details

Features: 

Features Medium to coarse-grained calls (due to communication overhead) Asynchronous task-parallel programming Dynamic resource discovery and scheduling Manage IDLs on server side only

The GridRPC API - Fundamentals: 

The GridRPC API - Fundamentals Function handle Represents a mapping from a function name to an instance of that function on a particular server Once created, calls using a function handle always go to that server Session ID Identifier representing a previously issued non-blocking call Allows checking status, canceling, waiting for, or getting the error code of a non-blocking call

Initializing and Finalizing: 

Initializing and Finalizing grpc_initialize Reads config file and initializes the system Must be called before any other GridRPC calls grpc_finalize Releases any resources being used by GridRPC

Function Handle Management: 

Function Handle Management grpc_function_handle_default Get a function handle using the default server Server selection implementation-dependent grpc_function_handle_init Allows explicitly specifying the server grpc_function_handle_destruct Release the memory allocated for this handle grpc_get_handle Get the function handle corresponding to a given Session ID

GridRPC Call Functions: 

GridRPC Call Functions grpc_call Blocking remote procedure call grpc_call_async Non-blocking remote procedure call grpc_call_argstack Blocking call using argument stack grpc_call_argstack_async Non-blocking call using argument stack

Asynchronous Control/Wait Functions: 

Asynchronous Control/Wait Functions grpc_probe Checks whether a call has completed grpc_cancel Cancels a previous call grpc_wait Wait for a specific call to complete grpc_wait_and Wait for all calls in a specified set to complete grpc_wait_or Wait for any call in a specified set to complete grpc_wait_all Wait for all calls to complete grpc_wait_any Wait for any call to complete

Error Reporting Functions: 

Error Reporting Functions grpc_perror Prints the error string of the last call grpc_error_string Gets the error string given a numeric error code grpc_get_error Get the error code for a specified non-blocking call grpc_get_last_error Get the error code for the last call

Argument Stack Functions: 

Argument Stack Functions grpc_arg_stack_new Creates a new argument stack grpc_arg_stack_push_arg Pushes the specified argument onto the stack grpc_arg_stack_pop_arg Gets the top element of the stack grpc_arg_stack_destruct Frees resources associated with the argument stack Arguments are passed in the order they were pushed onto the stack.

Example Program Segment: 

Example Program Segment int n=5, incx=1, incy=1, status; double ns_result = 0.0; double dx[] = {10.0, 20.0, 30.0, 40.0, 50.0}; double dy[] = {60.0, 70.0, 80.0, 90.0, 100.0}; grpc_function_handle_t handle; grpc_initialize(NULL); grpc_function_handle_default(andamp;handle, 'ddot'); status = grpc_call(andamp;handle, andamp;n, dx, andamp;incx, dy, andamp;incy, andamp;ns_result); ...

Reference Implementations: 

Reference Implementations Currently two complete reference implementations exist NetSolve (UTK) Ninf-G (AIST) Systems are largely similar in operation except that: Ninf-G is built on top of Globus NetSolve performs its own scheduling, load balancing, etc, but can also interact with other systems Therefore, the protocols and IDLs differ

Issues/Challenges: 

Issues/Challenges Service Name Collisions Different systems may have different calling sequences for the same function So, in some sense a GridRPC program may be bound to a particular implementation Function handle binding Function handle represents a persistent function-to-server mapping Binding a function handle a long time before the actual calls may result in less satisfactory resource selection because of changing server workloads and network conditions

Issues/Challenges (cont.): 

Issues/Challenges (cont.) Implementability Does the specification of the API preclude implementation on any systems? Persistent Data Security Thread Safety At least not thread 'hostile'

Conclusions: 

Conclusions Attempting to provide: Simple API upon which higher-level services could be implemented Low burden on programmer attempting to transition code to the Grid Future work: Charter for GridRPC Working Group still under development Consider the many challenges from previous slides as we standardize the API Next GridRPC Working Group Meeting March ‘03, GGF7