A Multicast RPC Implementation for Java

8/7/2019 A Multicast RPC Implementation for Java

1/7

1

A Multicast RPC Implementation for JavaPhilip Russell and Chase Covello

Computer Science DepartmentUniversity of California, Los Angeles

{prussell,chase}@cs.ucla.eduhttp://code.google.com/p/multicast-rpc/

Abstract

We propose an extension of RemoteProcedure Call (RPC) semantics to a

multicast environment and discuss aJava implementation thereof. The

implementation consists of a reliable,FIFO multicast provider, five

interchangeable Total Order Broadcastalgorithms, and an RPC client and server

that make use of these technologies. Wedemonstrate that the implementation

works correctly. Throughout the paper,we discuss future work that could be

done on this project.

Introduction

Remote Procedure Calls (RPC) [1] are aconvenient paradigm to use when

programming a distributed system. Awell-designed RPC implementation like

Javas RMI is transparent to theprogrammer that is, remote procedure

calls are made with identical syntax tolocal procedure calls [4]. This brings the

ease of programming of shared memorymultiprocessing systems to inexpensive

multicomputer clusters built withcommercial off-the-shelf components.

Instead of explicitly passing messagesbetween processes, the programmer

simply sets the RPC mechanism up andperforms method calls on objects.

Threads can thus be moved to othercomputers without affecting method

invocation semantics. This allows theprogrammer to focus on the higher level

task of writing a correct program rather

than worry about the explicit memory

management required in distributedmemory multiprocessors.

Point-to-point RPC between a client anda server system is mostly a solved

problem [1], but RPC in a multicastenvironment is still an active field of

research. RPC has been criticized forbeing inherently point-to-point [3], but

we believe that the ability of a clientsystem to execute an RPC call on many

servers in parallel would be useful inmany situations. For example, a master

processor could send software updates orremote administration commands to a

network of mobile devices with littleeffort on the part of the programmer.

Thinking bigger, a network of mobiledevices could be treated as a grid,

bringing massively parallel computingpower to any client within wireless

range. Such a network could be scaledup or down without requiring any

changes to client programs of the grid.

This paper demonstrates an

implementation of multicast RPC inJava. Because it is written entirely insoftware without any modification to the

language or compiler, our

implementation does not have thetransparency of Java RMI. However, itwould be straightforward to integrate

this code into the Java runtime system asan extension to RMI, providing more

transparency. This project, then, is aproof of concept.


2/7

2

Multicast Implementation

Correct RPC semantics require both thesender and receiver to agree on the order

in which procedures are executed.Multicast RPC is no different in fact,

all receivers should agree on the sameordering for procedure calls. This

property, called Total Order Broadcast[2], is not provided in the Java standard

library. Javas network library supportsthe core transport-layer protocols of the

Internet: TCP, UDP, and multicast UDP.

Since multicast UDP does not provide

any guarantee of reliable or in-orderdelivery, it is not a total order broadcast

algorithm, and is thus unsuitable for usewith RPC. Furthermore, we were unableto correctly route multicast packets on

any of the networks we tested. Given thelimited amount of time available for this

project, we chose to implement a totalorder broadcast protocol in software atop

TCP connections. This is not truly amulticast protocol, and in fact it is

inefficient for production-qualitymulticast RPC, but we believe that the

modular nature of the code lends itself tobeing replaced with a better

implementation in the future, perhapstaking advantage of advanced multicast

services in the operating system ornetwork hardware.

Our total order broadcastimplementation consists of the following

modules:

The multicast simulator. This is areliable, FIFO multicast transport

layer. It has a set of message senderand receiver classes, along with a

multicast manager that tracksmembership in the multicast group

and relays the information to groupmembers.

The total order broadcastmodules. These use the multicastsimulator for their transport layer

and add a total ordering guarantee tomessage transport. They are based on

the pseudocode in [2]. Fiveimplementations are available, which

allows the RPC user to chooseamong the performance and

reliability tradeoffs inherent in thealgorithms.

Note that all the packages mentioned arerelative to edu.ucla.cs.rpc.multicast.

Multicast Simulator

Our multicast code is located in the

network package. Messages are sentusing instances of multicast sender,

found in MulticastMessage-Sender.java. A message sender

maintains a set of message receiveraddresses. It sends a message by opening

a TCP connection to each receiver in theset, serializing the message, and sending

the serialized byte stream over theconnection. The set of receiver addresses

is kept up to date with the help of a

separate thread that listens on a socketfor broadcast updates.

Unicast messages are received with

instances of MessageReceiver.java.This class runs a thread that listens on a

socket for incoming messages. Themessages are passed to the receivers

message handler, a type of extensibleevent handler that the user provides. A

handler might print the message to the

console, queue it, or hand it off to awaiting processing thread, for example.

Multicast messages arrive at instances of

MulticastMessageReceiver.java. Thisclass extends MessageReceiver.java to

maintain membership in the multicastgroup, including sets of the sender and

receiver unique identifiers. Updates to


3/7

3

these sets are accomplished in the sameway as for multicast senders.

A core concept in our multicastsimulator is that of the multicast

manager. It is implemented in

MulticastManager.java. The multicastmanager listens on a TCP socket for Joinand Leave messages from the senders

and receivers. Upon receiving such amessage, it updates its internal

membership sets and sends updates tomembers of the group. Multicast senders

need to know the addresses of thegroups receivers, so those are broadcast

to the senders whenever a receiver joinsor leaves the group. Similarly, sender

and receiver membership changes arebroadcast to all receivers in the group.

The combination of these four classes,along with Message objects, provides a

reliable, FIFO multicast transport layer.Any single sender will observe a

consistent ordering of its own messagesamong all the receivers in the group. For

total ordering of all messages, however,one of the five total order broadcast

algorithms is needed.

Fixed Sequencer

The simplest total ordering algorithm

uses a single process through which allbroadcast messages must be routed. This

process, called a sequencer [2], receivesone message at a time, so a total order is

imposed automatically. The sequenceradds a sequence number to each

incoming message, then broadcasts themto all receivers in the multicast group.

Our fixed sequencer resides in thesequencer.fixed package, in Fixed-

Sequencer.java. It uses a messagereceiver to accept incoming messages

and broadcasts them with a multicastmessage sender. We have a test program

in test.FixedTester.java.

Moving Sequencer

The Fixed Sequencer scheme relies on asingle, fixed intermediary process to act

as a relay between the group of senders(S) and the group of destinations (D).

The main advantage of FS is that it isrelatively simple, but suffers from a

single point of failure. If the FS processever crashes, then the entire system stops

processing messages. No message can besent from S, and no member of D can

receive a message. Instead of a singleintermediary process, we can use a

group of processes to relay messages.This is the Moving Sequencer scheme. It

distributes both the responsibility of

relaying messages between S and D andbalances the load of sending messagesamongst its members.

As outlined in [2], the MSimplementation relies on a token ring. A

Token is an object that records asequence number and keeps a list of

messages that have been relayedbetween S and D. The algorithm

proceeds thus:

1.

Each Sender in S broadcasts to everymember of MS.

2. Each sequencer waits for both amessage and the token. As soon as itholds both, of these objects, it

attempts to add the message to thelist of already relayed messages. If

this operation fails, then thesequencer knows that the message

has already been relayed, and shouldbe dropped. Otherwise, it stamps the

message with a sequence numberand sends the message to D.

The token ring is implemented in theutil.token package. The primary files

are Token.java and NetworkToken-Manager.java. A token manager is an

object that is responsible for both


4/7

4

initializing the token, receiving it fromthe previous node, and sending it to the

subsequent node in the ring when eithera timeout occurs or it has been signaled

to do so by another process.

The Moving Sequencer algorithm isimplemented in the sequencer.movingpackage, in the file Moving-

Sequencer.java. This class is tested bythe file MovingTest.java, found in test.

The current implementation successfullyconstructs the token ring and relays only

one copy of a message between S and D.There are no provisions for dealing with

the possibility of a member of the ringfailing. The current implementation can

be extended towards this functionalityby maintaining an on line registry of

token ring members. In the case ofmember failure, each member of the

token ring is notified by the registry,which then calculates a new token ring

by randomly assigning new previous andadjacent nodes to each member.

Privilege-Based

The Privilege based scheme, likeMoving Sequencer, is based on creating

a token ring of processes. Instead ofsequencers forming the ring, the

members of S do so. The algorithmgiven in [2] is:

1. For each members in S, wait for botha message from the upper layer and

the token.

2. When both of these objects are held,assign the message a sequencenumber and multi-cast it to D.

PB is a relatively simple scheme thatdistributes the load of sending messages

from the upper level amongst themembers of S. The token ring is

implemented in the same files mentionedin Moving Sequencer. The algorithm

implementation is in Privileged-Sender.java, package privilege. It is

tested in PrivilegeTest.java, found inthe testing package. The purpose of the

test is to create the token ring amongst S,

and to send messages from S to adestination.

Communications History

In contrast to the Fixed/Moving

Sequencer and Privilege-based scheme,the Communications History class of

algorithms do not differentiate betweenS and D. Instead, all processes in the

system belong to the same group P. Ofthe class of Communications History

algorithms, we implemented the causalhistory algorithm, which proceeds as

follows [2]:

1. Every member p of P has an array oflogical clocks that record thatmaximum clock value of process q

of P, as known by p. Initially, allvalue are zero. An update occurs

when p receives a message from qwith a new clock value.

2.

To broadcast, p update its ownlogical clock, time-stamps the

message, and sends it across someFIFO channel (a TCP stream in our

implementation).

3. When a process p receives a messagefrom q, p updates its array of logicalclocks to be the maximum of the

current logical clock value for q andthe value embedded in the message.

p then creates a set of deliverable

messages, defined as those that havebeen received but have not beendeliveredand the timestamp of each

message is less than the minimumclock value for each process in the

logical clock array.

4. Each deliverable message isdelivered to the layer above, and


5/7

5

added to the deliveredset.

The algorithm imposes an order on the

messages by restricting the conditionsunder which a message can be delivered

to the layer above. As described above

and detailed in [2], a message cannot beadded to the deliverable set unless theprocess p has received a message from

each other process q with a latertimestamp than the message's. A system-

wide total order is thus imposed byforcing logically earlier messages to be

delivered first.

The algorithm is implemented in the file

CausalProcess.java, in packagecommhistory.

Destinations Agreement

The class of destinations agreementalgorithms work on the principal that the

Senders broadcast to the Destinations,who re-circulate enhanced messages

amongst themselves to decide on thetotal order of message delivery.

Our implementation focuses ondestination agreements with agreed-upon

sequence numbers [2]. The algorithmproceeds as follows:

1. Each sender in S broadcasts themessage from the layer above in the

usual manner.

2. Each destination D records twomessage sets, stampedand received.As well, it initializes its logical clock

to be zero.

3. Upon receiving a non-timestampedmessage, the destination adds itreceived, timestamps the message,

and re-transmits the message to theother destinations.

4. Upon receiving a timestampedmessage, the checks to see if it has a

copy of the message from every

other destination. If not, it recordsthe sender id, keyed by the message.

If yes, then it finds the globallymaximum timestamp of the message,

stamps a copy of the message with

the global timestamp, and adds it tostamped.

5. For each message in stamped, thealgorithm checks to see if everymessage in received has a logically

later timestamp. If this is true, thenthe stamped message is delivered to

the layer above.

The algorithm enforces a total order on

the message delivery by finding thelogically latest copy of each message,

and ensuring that it cannot be deliveredunless all other received messages are

logically later [2]. Our implementation isfound in the file AgreementDest.java,

package destination.agreement.

The algorithm assumes that there is a

way to discover only the set D ofdestinations. We were not able to

implement this functionality in the giventime constraints. Possible extensions to

this project would be to use a differentMulticastManager to negotiate the

message channels amongst only D.

The RPC Layer

With a total order broadcast algorithmavailable, the actual RPC code becomes

very simple. A program that wishes tocall a remote method constructs a new

RPC client instance, initializing it with aSender implementation from one of the

fire total order broadcast algorithms. Therelevant code is in RPCClient.java. A

client then invokes the call method,which accepts an object or Class

instance, a method name, and a variablenumber of arguments. The call method

packages these arguments into an


6/7

6

RPCMessage and total order broadcastsit.

On the server side, an instance ofRPCServer.java receives the message,

unpacks its contents, and performs a

dynamic class and method lookup usingthe Java reflection API. It then invokesthe method using the provided

arguments and returns.

Our implementation does not currently

support return values. Any method maybe invoked, but return values are

discarded on the server side. We canthink of two ways to support return

values: either allow multicast messagesto aggregate responses from the

receivers and pass them back to thesender, or have the RPC client wait for

responses from all the servers. An earlierversion of the project tried the former

solution, but it didnt really work welland complicated much of the total order

broadcast code. Further work on thisproject might include having the RPC

client wait for response messages fromthe servers and aggregating their return

values.

Results

Our multicast RPC implementationworks for our test cases.

RPCClient.java contains a mainmethod that starts a multicast manager, a

fixed sequencer, a client, and severalservers. It then instantiates an RPCTest

class, which has an rpcTest method thatprints its string argument to the standard

output. The client calls this method withthe string Hello, world!, then shuts

down the servers, sequencer, andmulticast manager. Running the program

produces one Hello, world! on theconsole for each RPC server running.

We are thus confident that we have aworking RPC implementation.

Conclusion

In this paper we discussed the problemof making remote procedure calls to

multiple destinations as a multicastoperation. We outlined the architecture

to achieve this goal in Java. The twoprimary components of the architecture

are the multi-cast simulator and the totalorder algorithms. Together, these pieces

create a working implementation of RPCsemantics in a multicast environment. As

discussed throughout the paper, there isfuture work to be done, starting with

implementing a true multicast routinglayer that the message senders, receiver

and multicast managers communicate

through. Some of the total orderbroadcast modules, such as Moving

Sequencer, can be extended with furtherfunctionality, and entirely new modules

can be created. We envision performingexperiments to obtain performance

evaluation data for the differentalgorithms. We are confident that this

work forms the basis for a modular,transparent testing and implementation

suite for multicast remote procedure

calls.

References

[1] Birrell, Andrew and Nelson, BruceJay. Implementing Remote

Procedure Calls. ACM Trans.Computer Systems, Feb 1984.

[2] Dfago, Xavier, Schiper, Andr, etal. Total Order Broadcast andMulticast Algorithms: Taxonomy

and Survey. ACM ComputingSurveys, Dec 2004.

[3] Tanenbaum, Andrew S. and vanRenesse, Robbert. A Critique of the

Remote Procedure Call Paradigm.Proc. EUTECO 88, Apr 1988.

[4] Waldo, Jim. Remote procedure callsand Java Remote Method


7/7

7

Invocation. IEEE Concurrency, Jul1999.

A Multicast RPC Implementation for Java

Documents

Transcript of A Multicast RPC Implementation for Java