GridRPC

1. GridRPC Sources / Credits: IRISA/IFSIC IRISA/INRIA Thierry Priol et. al papers

2. GridRPC Introduction • Grid RPC (Remote Procedure Call) allows users to make simple sequential function calls to invoke remote applications • Ease-of-use for users and high performance for applications • E.g. CORBA, JavaRMI, NetSolve, Ninf • A RPC system contains mechanisms for • application developers (producers) to integrate their applications • RPC clients to invoke those applications at remote resources

3. 3. Client contacts specificserver for services. 4. Server runs computationand returns results to client. 2. Agent returns sortedlist of capable servers. 1. Client makes requestto agent. Example - NetSolve Server Resources

4. Working of NetSolve • Server side • Application developer writes Interface Definition Language (IDL) for the application • Contains application specification • Used for: 1. error checking, 2. compiling and linking other parts of middleware code with the problem • Provides his application as a function call • IDL is compiled; a main driver routine that calls the application function is automatically generated • The main driver routine along with the function is compiled to form service executable • The problem specification is also added to a database

5. More about IDL • Contains problem name • Path for its include files • The library files (lib*.a) containing functions referred to by the problem • Language in which the function was written • Input and output arguments

6. Steps during remote procedure execution • Client side Invokes the function call • Behind the scenes: the invocation causes the client to contact the agent • The agent checks the database to find the problem and a list of servers containing the problem • The servers also convey their current load and speed • Agent passes this information to the client • Client matches the user arguments with the problem specifications; throws error if arguments don’t match with problem specifications (IDL use)

7. Steps during remote procedure execution • contacts a server that it is able to connect to • Passes the arguments to the server • Server writes the input data to a file • Spawn the application service process • Application service process’ main driver reads data from file, calls the application function, gets output, returns output back to client.

8. CORBA review • Supports distributed object-oriented applications • Middleware providing set of services for distributing objects to multiple resources connected by network • Disadvantages • Supports only sequential objects • Not suitable for HPC due to stub and skeleton complexities

9. CORBA Architecture

10. Architecture • ORB – communication infrastructure standard • Transfer syntax • Message formats • ORB accessed by • Dynamic interface • Dynamic Invocation Interface (DII) at client for dynamic creation and invocation of requests to objects • Dynamic Skeleton Interface (DSI) at server for accepting such requests through ORB and invoking objects that have not yet been compiled and no information is available • Static interfaces • Through IDL – provides operations, data types • IDL compiled to stubs at client and skeletons at server • Portable Object Adapter (POA) • Interface for miscellaneous duties – interfacing distributed objects with different access policies etc. • Also loads and executes the process implementing the object when called from the client

11. IDL Example

12. Encapsulation of Parallel codes in CORBA Objects • What should be the interface between ORB and parallel codes? • How should the IDL be changed? • What should happen at the client stubs? • What should be the data distribution model? • What should happen to the result of the parallel object invocation?

13. Common Approach

14. PaCO (Parallel CORBA Object) • Collection of Standard CORBA Objects • Separate object for each SPMD process. Objects combine to form collection. • During remote invocation, method is executed concurrently in all objects.

15. PaCO Project • Thus stubs modified to issue multiple simultaneous requests • Hence IDL modified to extended IDL to generate the modified stubs • Extended IDL specifies • Number of objects in the collection • Data distribution of the parameters • Collective operation on the results

16. Extended IDL Example

17. CORBA Overheads • Client sending a header to notify remote object to invoke a method, t1 • Marshal and send the inputs • Remote method is executed • Marshal and send the outputs • Notify the client, t2

18. Results on Pentium II Cluster

19. SOAP/WSDL for GridRPC(Ninf system)

20. Ninf on SOAP Performance

21. Bottlenecks – serialization and deserialization

22. Bottlenecks • Serialization, wire transfer, deserialization done in sequence • Remedy: eliminate the need of content length in HTTP-Post. The server can interpret message by counting and matching XML tags • Significant space complexity of XML elements to array elements • Remedy: Use Base-64 encoding

23. Results due to Optimizations

24. References / Credits • Alexandre Denis, Christian Pérez, and Thierry Priol. Achieving Portable and Efficient Parallel CORBA Objects. Concurrency and Computation: Practice and Experience, 15(10):891--909, August 2003. • Christophe René and Thierry Priol. MPI code encapsulating using parallel CORBA object. Cluster Computing, 3(4):255--263, 2000. • Denis, A., Pérez, C., and Priol, T., 2001b. Towards high performance CORBA and MPI middlewares for Grid computing . In Craig A. Lee, editor, Proceedings of the 2nd International Workshop on Grid Computing, Lecture Notes in Computer Science Vol. 2242, Denver, CO, November, Springer-Verlag, Berlin, pp. 14–25 . • Evaluating Web Services Based Implementations of GridRPC Satoshi Shirasuna, Hidemoto Nakada, Satoshi Matsuoka and Satoshi Sekiguchi Proceeding of HPDC11, July, 2002.