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

1. Overview of GridRPC: A Remote Procedure Call API for Grid Computing Keith Seymour Hidemoto Nakada Satoshi Matsuoka Jack Dongarra Craig Lee Henri Casanova http://www.eece.unm.edu/~apm/

2. 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 http://www.eece.unm.edu/~apm/

3. 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 http://www.eece.unm.edu/~apm/

4. 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 http://www.eece.unm.edu/~apm/

5. 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 http://www.eece.unm.edu/~apm/

6. 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 http://www.eece.unm.edu/~apm/

7. 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 http://www.eece.unm.edu/~apm/

8. 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 http://www.eece.unm.edu/~apm/

9. 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 http://www.eece.unm.edu/~apm/

10. 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 http://www.eece.unm.edu/~apm/

11. 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. http://www.eece.unm.edu/~apm/

12. 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(&handle, "ddot"); status = grpc_call(&handle, &n, dx, &incx, dy, &incy, &ns_result); ... http://www.eece.unm.edu/~apm/

13. 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 http://www.eece.unm.edu/~apm/

14. 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 http://www.eece.unm.edu/~apm/

15. 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” http://www.eece.unm.edu/~apm/

16. 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 http://www.eece.unm.edu/~apm/