Overview of Grid RPC A Remote Procedure Call

Overview of Grid. RPC: 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/

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/

Introduction » Provide standardized, portable, and simple programming interface for Remote Procedure Call » Attempt to unify client access to existing grid computing systems (such as Net. Solve and Ninf-G) » Working towards standardization through GGF WG » Initially standardize API; later deal with protocol » Standardize only minimal set of features; higherlevel features can be built on top » Provide several reference implementations » Not attempting to dictate any implementation details http: //www. eece. unm. edu/~apm/

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/

The Grid. RPC 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 nonblocking call » Allows checking status, canceling, waiting for, or getting the error code of a non-blocking call http: //www. eece. unm. edu/~apm/

Initializing and Finalizing » grpc_initialize » Reads config file and initializes the system » Must be called before any other Grid. RPC calls » grpc_finalize » Releases any resources being used by Grid. RPC http: //www. eece. unm. edu/~apm/

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/

Grid. RPC 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/

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/

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/

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/

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/

Reference Implementations » Currently two complete reference implementations exist » Net. Solve (UTK) » Ninf-G (AIST) » Systems are largely similar in operation except that: » Ninf-G is built on top of Globus » Net. Solve 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/

Issues/Challenges » Service Name Collisions » Different systems may have different calling sequences for the same function » So, in some sense a Grid. RPC program may be bound to a particular implementation » Function handle binding » Function handle represents a persistent function-toserver 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/

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/

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 Grid. RPC Working Group still under development » Consider the many challenges from previous slides as we standardize the API » Next Grid. RPC Working Group Meeting March ‘ 03, GGF 7 http: //www. eece. unm. edu/~apm/