Java RPC project Final presentation By Anat Hashavit

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

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

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

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

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 ¢

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

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 Dispatcher. Thread) ¢ Thread pool is used to allocate / manage threads. ¢ * multi-threading demo

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: l l ¢ ¢ Provide Agent, Client, Server, and Service. Factory 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

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

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)

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 ¢

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

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)

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

Protocol diagram Can/can’t serve Dispatching Server Exce p Calculation tatus . . . tion s Function request (Service ID and func ID) Exce p Input parameters tatus Client Output parameters

UML Class Diagram - Server

UML Class Diagram - Service

UML Class Diagram Communication

Testing Services used for testing ¢ RMI application ¢ Test results ¢ Results analysis and conclusions ¢

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

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

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

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

Tree Package (cont. ) l Example for common code: protected Return. Code union. RPC(Trees. Wrap tw) throws Throwable { Return. Code result = new Return. Code(Return. Code. SUCCESS); com. Agent. input(tw. get. Param 1()); com. Agent. input(tw. get. Param 2()); com. Agent. end. Of. Input(); tw. get. Res(). clear(); // empty in client, in server does the actual calculation result = do. Union(tw); // does nothing in server, in client may throw exception com. Agent. check. Exception(); com. Agent. output(tw. get. Res()); com. Agent. end. Of. Output(); return result; }

List Package ¢ Includes the following functions: l l l First. Navg – receives a list of integers (l) and a number (N) and calculates the average of the nodes L(0) to L(N) Is. Prefix - receives two lists and determines whether one is a prefix of another Reverse. List – The function receives a list and reverses it

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 ¢

RMI Application (cont. ) ¢ However, we do expect some differences l l l 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

Test Results List 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 l Is prefix : we sent a list of 50000 nodes and a list of 5000 nodes expecting RPC to outperform RMI l Reverse List : we sent a list with 1000 nodes: expecting RMI to outperform RPC l

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

Results- List: first N avg RPC RMI Total time 13551. 0 101228. 0 Min time 600. 0 668. 0 Max time 980. 0 3481. 0 Average time 677. 55 1012. 28 Variance 81. 217 401. 247

Results- List: Is Prefix RPC RMI Total time 17841. 0 110841. 0 Min time 780. 0 832. 0 Max time 1310. 0 2933. 0 Average time 892. 05 1108. 41 Variance 122. 46 315. 23

Results- List: Reverse List RPC RMI Total time 30636. 0 3277. 0 Min time 251. 0 15. 0 Max time 959. 0 159. 0 Average time 306. 36 32. 77 Variance 123. 78 20. 7811

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

Results –Tree: Union RPC RMI Total time 246129. 0 80488. 0 Min time 1369. 0 377. 0 Max time 5055. 0 2303. 0 Average time 2461. 29 804. 88 Variance 857. 062 365. 303

Results –Tree: Intersection RPC RMI Total time 127081 65261. 0 Min time 901. 0 316. 0 Max time 2843. 0 1762. 0 Average time 1270. 81 652. 61 Variance 319. 209 234. 632

Results –Tree: Sum to level RPC RMI Total time 4431. 0 8248. 0 Min time 210. 0 166. 0 Max time 356. 0 1227. 0 Average time 221. 55 412. 4 Variance 31. 74 236. 75840

RPC vs. RMI: Tree agent

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

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