Java RPC project:Final presentation

By:

Anat Hashavit

Sigal Ishay

Vladimir Lazebny

Agenda

Project Objectives Abstract Misc aspects of implementation

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: 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 DispatcherThread)

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: 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

Dynamic registration (cont.)

All services are registered in a ServiceRegistry according to their “service ID’s”

ServiceRegistry is shared between multiple threadsProtected by “multiple readers/single

writer” lock in order to reduce synchronization to minimum

* Dynamic reg. demo

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 maximumAs little overhead as possibleNot obligatory to use – often

developer does not care about exceptions

* 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

Functionrequest(Service IDand func ID)

Can/can’tserve

Inputparameters

Outputparameters

Exc

eptio

n st

atus

Exc

eptio

n st

atus

. . .

Client

ServerDispatching Calculation

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 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

Service Packages (cont.)

Specific Agent ServerExtends Specific AgentStatic dispatcher for the agent’s

servicesImplements the interface functions

which perform actual computations Specific Agent Client

Extends Specific AgentSimple 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

List Agent: an example agent that handles various list operations

Tree Agent : an example agent that handles various tree operations

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)

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 calculationresult = doUnion(tw);

// does nothing in server, in client may throw exceptioncomAgent.checkException();comAgent.output(tw.getRes());comAgent.endOfOutput();return result;

}

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

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 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 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

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

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

0

200

400

600

800

1000

1200

avg execution time

RPC Vs RMI: List Agent

RPC

RMI

RPC 677.55 892.05 306.36

RMI 1012.28 1108.41 32.77

List:FirstNAvg List:IsPrefix List:ReverseList

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

0

500

1000

1500

2000

2500

RPC 2461.29 1270.81 221.55

RMI 804.88 652.61 412.4

Tree:Union Tree:Intersection Tree:SumToLevel

avg execution

time (ms)

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