Java RPC project: Final presentation

1. Java RPC project:Final presentation By: Anat Hashavit Sigal Ishay Vladimir Lazebny

2. Agenda • Project Objectives • Abstract • Misc aspects of implementation • Multithreading, dynamic registration, version control, exception management, server stability • UML Class Diagram • Testing and test results

3. Project Objectives • A design pattern describing possible implementation of RPC mechanism • First stated in “RPC-Based methodology for Client/Server application development in C++”, 1997 • Implement the above paradigm in Java • Compare performance versus Java built-in RMI mechanism in some specific application

4. Project Objectives (cont.) • Main differences from the example presented in the original article: • Multithreading • Multiple requests per connection • Multiple services • Dynamic service registration and dispatching • Exception handling • Version control • Server stability • Java instead of C++

5. Abstract • A client-server Remote Procedure Call (RPC) model • No explicit IDL file – client and server share the same generic code • We provide a strong and flexible server application, number of clients is only limited by HW • Special emphasis on the ability to develop and add new services easily

6. Server Parts • Server core – responsible for establishing and maintaining connections, administration console, thread pool, service management • Dispatching mechanism – the steps taken by the server to handle incoming requests • Specific services – implementation of different “classes of functions” available to clients • Communication – generic Input/Output primitives used to encapsulate actual media access

7. Multithreading • Main thread listens on a socket waiting for incoming connections • Once new connection is established client is authenticated. Notably, version control is also done here • New thread is assigned for every connection (class DispatcherThread) • Thread pool is used to allocate / manage threads. * multi-threading demo

8. Dynamic registration • Developer adds specific “classes of functions” (services) by writing certain Java classes and registering them in the server • Every service must obey certain rules: • Provide Agent, Client, Server, and ServiceFactory classes • Implement two interfaces (below) • Services can be loaded/unloaded dynamically without server restart • Server is configured by an .xml file that specifies services loaded on server start

9. Dynamic registration (cont.) • All services are registered in a ServiceRegistry according to their “service ID’s” • ServiceRegistry is shared between multiple threads • Protected by “multiple readers/single writer” lock in order to reduce synchronization to minimum * Dynamic reg. demo

10. Server stability • Extensive use of exceptions in any place anything can go wrong, especially around I/O • Number of clients is limited (configurable) • Special way to quickly reject a connection if server resources are nearing depletion (currently used only for thread limit) • Notably, while doing our tests, we have never observed a single server crash! • Even offers significant protection against errors in service code (exception forwarding)

11. Version control • Version is only checked once – on new incoming connection • Developer must advance server version number manually • No need to introduce per-service version system – better to add under a new service ID, allowing services of different versions to run simultaneously

12. Exception Management • Main objectives while designing: • Flexible to the maximum • As little overhead as possible • Not obligatory to use – often developer does not care about exceptions * Exception demo

13. Exceptions (cont.) • May forward any exception – not only some pre-defined one like RMI, but any exception at all – the Exception object itself is serialized and sent to the client • Developer may chose in what places the program is likely to have exceptions - or not at all • Protocol is very efficient (see protocol diagram)

14. Performance • Server is quite complex: dynamic dispatching, thread management etc. • Runs in Java VM – another drawback • Server overhead is O(1) regarding input • All the server complexity practically does not influence performance – tests with very small arguments make it to about 1 ms/call • Tests have shown that disabling exceptions gives no measurable increase in performance

15. Protocol diagram Client Input parameters Function request (Service ID and func ID) . . . Exception status Exception status Output parameters Can/can’t serve Dispatching Calculation Server

16. UML Class Diagram - Server

17. UML Class Diagram - Service

18. UML Class Diagram - Communication

19. Testing • Services used for testing • RMI application • Test results • Results analysis and conclusions

20. Service Packages • Service implementation is standard and uniform for all services • A side developer should be able to understand it at a glance • Consists of 4 standard classes: • AgentFactory • Implements the interface: ServiceFactory • Specific Agent • Base class of specific server and client classes • Defines the common code for client and server agents

21. Service Packages (cont.) • Specific Agent Server • Extends Specific Agent • Static dispatcher for the agent’s services • Implements the interface functions which perform actual computations • Specific Agent Client • Extends Specific Agent • Simple wrappers for remote calls

22. Agents Implementation • We implemented three RPC agents • General Agent: performs general purpose operations such as reloading from registry and connection shutdown • List Agent: an example agent that handles various list operations • Tree Agent : an example agent that handles various tree operations

23. Tree Package • Works with binary trees containing integers as keys (no data) • Includes the following functions: • unionRPC – calculate union of two received trees (result bigger than input) • intersectionRPC – calculate intersection of two received trees (result smaller than input) • sumToLevel – receives binary tree and a number (level) and computes the sum of all nodes to this level (no need to transfer entire tree)

24. Tree Package (cont.) • Example for common code: protected ReturnCode unionRPC(TreesWrap tw) throws Throwable { ReturnCode result = new ReturnCode(ReturnCode.SUCCESS); comAgent.input(tw.getParam1()); comAgent.input(tw.getParam2()); comAgent.endOfInput(); tw.getRes().clear(); // empty in client, in server does the actual calculation result = doUnion(tw); // does nothing in server, in client may throw exception comAgent.checkException(); comAgent.output(tw.getRes()); comAgent.endOfOutput(); return result; }

25. List Package • Includes the following functions: • FirstNavg – receives a list of integers (l) and a number (N) and calculates the average of the nodes L(0) to L(N) • IsPrefix - receives two lists and determines whether one is a prefix of another • ReverseList – The function receives a list and reverses it

26. RMI Application • Client-Server application written in the most straightforward way – no hand optimizations • Server - side function implementations are copy-pasted from RPC services • Clients of RPC and RMI differ only in a actual remote function call and opening/closing connection – rest of the code is the same

27. RMI Application (cont.) • However, we do expect some differences • Entire input parameters are serialized in RMI version, while in RPC we customize input depending on function • In RMI we have two separate applications – for Tree and List functions – no dynamic dispatching overhead • Also exception handling and version control mechanisms are different

28. Test ResultsList RMI Vs List RPC • We compared RMI to RPC for the list agent and the tree agent. • List • First N avg: we calculated the average of 5000 first nodes of a 50,000 nodes list – expecting RPC to outperform RMI • Is prefix : we sent a list of 50000 nodes and a list of 5000 nodes expecting RPC to outperform RMI • Reverse List : we sent a list with 1000 nodes: expecting RMI to outperform RPC

29. Test ResultsTree RMI Vs Tree RPC • Tree • Union: unite two trees of 15,000 nodes • Intersection: intersection between two trees of 15,000 nodes each, expected RPC to outperform RMI • Sum to level: up to level 10 of 25,000 node tree, expected RPC to outperform RMI

30. Results- List: first N avg

31. Results- List: Is Prefix

32. Results- List: Reverse List

34. Test Conclusions • RMI easily serializes more information then needed, control on the serializing process can improve performance • The ratio between the amount of information sent by RPC and the amount of information sent by RMI needs to be quite large in order too see significant difference in performance

35. Results –Tree: Union

36. Results –Tree: Intersection

37. Results –Tree: Sum to level

38. RPC vs. RMI: Tree agent

39. Test Conclusions • RPC is definitely worse in performance – meaning network transfer time • Sending same object by using serialize and write to socket takes many times more time than RMI function call

40. Final Conclusion • The initial assumption is correct : Controlling the amount of data transferred can result in better performance • However: Although RMI sends too much information it does so in a very efficient way • Optimizations on the serialization process used in RPC can bring to much better results