2

The Plan: Applied Stuff

 Introduction to distributed systems
– Overview, definitions, characteristics, issues,
ICS 2403 Distributed Systems
challenges
 A practical developer’s overview of
networking
– Characteristics of IP, TCP, UDP
– Writing networked applications: UDP vs. TCP vs.
higher level approaches
Principles of Distributed Systems
 Then on to more theoretical aspects of
1 distributed computing

3 4
The Plan: Theoretical Stuff Distributed Systems: Intro
 Theoretical Foundations  Distributed System:
– Autonomous Computers + Network distributed
– Fundamental Limitations computing
– Communication via message-passing
– Causality – No shared memory mobile
– Logical clocks (logical, vector, matrix clocks) computing
– No global clock
– Global states – Range:
• Two PC’s connected by $25 worth of networking
 Algorithms for distributed mutual exclusion hardware
 Distributed Shared Memory (DSM) • Beowulf clusters: racks (or stacks) of PCs
connected by high-speed networking
 Topics in fault tolerance and reliability • Millions of computers, connected by diverse
networking technologies ranging from modems to
gigabit connections (the Internet)
 5 6
Network Operating Systems
 Network operating systems extend
sequential operating systems to provide:
– Resource sharing (files, devices, …)
– Interoperability (email, remote command
execution, remote login…)
 User is generally aware of machine
boundaries (do “this” on “that” machine)
7 8
Unix/”Distributed Unix”
 Unix: pervasive when cheap network
technologies became available (1970’s),
so a logical choice for building
“distributed systems”
 Extensions to Unix which provided
interprocess communication were a
principal building block of early
distributed systems
 Unix sockets API
DOS vs. NOS
 (Virtual) Transparency: The ability to see
what you want to see, and not see what
you consider to be of no interest
 An exaggeration:
lim NetworkOS  DistributedOS
transparency  
 DOS’s allow you to “slide” toward a “one
large machine” view of the network of
computers
Distributed Unix, Cont.
 Problems with distributed Unix, though:
– Monolithic kernels
– Scattered process information
– Progress migration, checkpointing difficult
 These problems stem from taking a tool in
wide use and “molding” it to fit a new need
 Why not “kill” Unix and use a modern, “this
is what I do well” distributed OS?
 Commercial pressures.
 Too much code already in use.
 9 10
Desirable Characteristics
 These are the “selling points” for distributed
systems, answers to the question “What can
they provide for me?”
 Scalability
– Want to be able to pile on more hardware as
needed to tackle bigger problems without rewriting
applications
– E.g., in Parallel Virtual Machine (PVM), add more
processors to share workload of smaller pieces of
a large computation
11
Desirable: Transparency
 (Virtual) Transparency
– Want distributed system to appear to be one big,
seamless machine, however...
– ‘A distributed system is a system on which I
cannot get any work done because a machine I’ve
never heard of is down.’
-- L. Lamport
– Fault tolerance/transparency must be considered
together
– Don’t want “transparent” components failing and
preventing work from getting done
Desirable: Fault Tolerance
 Fault Tolerance
– Higher availability and more resilience to faults
than uniprocessor/shared memory multiprocessor
solutions
– Redundancy is the key—it’s present in all fault
tolerance schemes, e.g.,
• replicated servers (e.g., for file or database
storage)
• snapshots of application state for recovery
12
Desirable: Concurrency
 Concurrency
– Distributed systems can bring a lot of hardware to
bear on difficult or time-consuming applications
– MIMD situations (e.g. file server, compute server,
web server machines)
• (Multiple Instruction, Multiple Data—means distributed
software components are different)
– SIMD situations (e.g. parallel rendering
applications for computer graphics)
• (Single Instruction, Single Data—means lots of instances
of a software component that performs a specific
operation)
 13
Desirable: Resource Sharing
 Resource Sharing
– Resource: display, printer, disk, CD-ROM,
applications
– “One Cadillac instead of 12 Yugos”
– Distributed systems allow resources to be
shared freely (or not), regardless of their
location in the system
– Can drastically reduce cost, improve utilization
of resources, reduce administration nightmare
– Security issues must be considered; security
issues arise in distributed systems which don’t
exist in isolated systems
15
Advantages in Brief
 The potential for building large, scalable,
fault-tolerant “computers” with huge
resources from commodity machines
 Commodity “supercomputers”
 In many circumstances, individual machines
can still be used for traditional tasks
– E.g., no reason individual users couldn’t read mail
on one node of the Beowulf cluster…
 Web-based supercomputing
14
Desirable: “Openness”
 “Openness”
– Heterogeneous hardware and software can be used to
build systems and solve complicated problems
– Published protocols and interfaces make putting
together the diverse pieces possible
• Which protocols are spoken?
• What data formats are used?
• Where are you?
– Example: WWW. Diverse machines “speak” a
standard protocol: HTTP. “Open” extensions include
CGI (Common Gateway Interface)
– Example: Universal Plug and Play (UPnP), Service
Location Protocol (SLP) for building highly dynamic
client/server systems
16
A Few of the Challenges
 No shared memory =>
– an unfamiliar programming model
– application state is spread around
– existing algorithms may be inappropriate
– object-based distributed computing helps
 No perfectly synchronized time source =>
– difficult to order events
– difficult to say “do something NOW” to the entire
system
 We’re stuck with the speed of light (?)
 More complicated failure modes than single
machines!
 Much easier for things to be “half broken”
 17
“Failure” has Many Meanings
 Halting failure: component simply stops
 Fail-stop: halting failures with ability to detect
failures
 Omission failure: failure to send/recv message
 Network failure: network link breaks
 Network partition: network fragments into two or
more disjoint subnetworks
 Timing failure: action early/late; clock fails, etc.
 Byzantine failure: arbitrary “malicious” behavior
– This one models random, worst-case behavior
19
Topic Switch: Networking Basics
 Network programming
 Goal: be able to implement
networked/distributed software rather
than just talk about it
– solve real problems
– design client/server protocols
– evaluate proposed solutions experimentally
18
Models of Distributed Systems
 An asynchronous distributed system is a
theoretical model of a network with no notion
of time
– no bound on message transmission time
– no bound on computation time
 A synchronous distributed system, in contrast,
has bounds, algorithms operate in “rounds”
 Our model (most of the time) will be close to
the asynchronous model
20
Network Protocols
 Protocol: Set of rules and data formats
which make communication possible
 A “language” for communication
 Protocols are typically constructed using
layers, with more abstract services
provided by higher-level layers
 Bottom layer(s) are the actual network
hardware
Networking Performance 21 22

Parameters
 Latency - time to transfer “empty” message
 Bandwidth or data transfer rate - how many
bits/sec can be transferred (how thick the “pipe” is)
message_transfer_time = latency +
msg_length / data_transfer_rate
 Consider: a modem connection vs. a van of
magnetic tapes traveling an interstate highway
 QoS: Quality of Service (bandwidth/latency
guarantees for particular connections)
OSI Protocol Stack
 OSI - Open Systems Interconnect
 Application - application interfaces (httpd, ftp)
 Presentation - network representation for
data
 Session - connections, encryption
 Transport - message  packets
 Network - network-specific packets, routing
 Data Link - transmission of packets between
“directly” connected machines + error issues
 Physical - hardware (“I can touch it”)

23 24
Communication Through Layers TCP/IP Protocol Stack
Application Application  ISO stack is good as a model for understanding networks
 Layers in “real” network stacks aren’t so differentiated
Presentation Presentation  TCP/IP stack has won primarily because of the free
implementation shipped in early versions of BSD Unix
Session Session  Addresses above IP are (port, address) combinations

Transport Transport
Application Application
Network Network
Transport UDP TCP
Data Link Data Link Network IP
Physical Physical Physical
 25
Transport Protocols
 UDP (User Datagram Protocol)
– Connectionless
– Fast setup
– Easy one-to-many communication
– Datagram-oriented (fixed size chunks of data)
– Packet reordering
– Packet loss (no flow control, bad packets dropped)
– Packet duplication
– (Absolute) maximum datagram length: 64K
– Usable maximum is more complicated
– 8K is generally safe for modern systems
27
Unix Sockets: TCP and UDP from a
Programming Perspective
 First the standard Unix system calls for C, then from
a Java perspective
 Unix C Server:
– int socket(PF_INET | PF_UNIX,
SOCK_STREAM | SOCK_DGRAM,
…)
– int bind(socket, localaddr …)
– int listen(socket, queuelength)
– int accept(socket, remoteaddr)
– select( … ) allows a set of sockets to be
checked to determine if input is available
– Allows service of multiple clients without
multithreading
26
Transport Protocols, Cont.
 TCP (Transmission Control Protocol)
– Connection-oriented
– Byte stream-oriented
– Slower setup
– Consumes file handles: one per connection
– Flow control, automatic retransmission
• No packet reordering (delivery is FIFO)
• No packet loss
• No duplication
– Theoretically “no” limit on size of objects that
can be dumped into a TCP stream
– In practice, limits exist
28
Unix Sockets, Cont.
 Unix C Client:
– int socket(PF_INET | PF_UNIX,
SOCK_STREAM | SOCK_DGRAM,
…)
– int connect(socket, remoteaddr)
 Unlike the server, the client typically doesn’t
care which port; the system selects one
 Then data is transmitted and received (for
both client and server) with:
– write(socket, message, len, …)
– read(socket, buffer, len, …)
 29 30
void ServeEchoClients(int port) { SERVER listen(sock, 15);
highest = sock;
// 15 is queue length for incoming connections
int i, found;
int alive; // client still around after read? memset((char *) &connected, 0, sizeof(connected));
int sock; // socket for listening printf("echo_server: Listening...\n");
int newconn; // socket for new client while (1) {
int highest; // highest handle in use; needed for select() FD_ZERO(&socks); // initialize set of sockets to monitor
int ready; // number of ready sockets (from select() call) FD_SET(sock,&socks); // always care about listening socket
int connected[100]; // handle only 100 simultaneous clients. // also care about sockets for connected clients
fd_set socks; // sockets ready for reading, for select() call for (i=0; i < 100; i++) {
struct sockaddr_in server_address; // structure for bind() call if (connected[i] != 0) {
int reuse=1; // avoid port in use problems FD_SET(connected[i],&socks);
if (connected[i] > highest) {
// initialize sockets stuff highest = connected[i];
sock = socket(AF_INET, SOCK_STREAM, 0); }
if (sock < 0) { }
Shutdown("echo_server: socket() call failed. Can't continue."); }
} ready = select(highest+1, &socks, NULL, NULL, NULL);
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)); if (ready < 0) {
memset((char *) &server_address, 0, sizeof(server_address)); Shutdown("echo_server: select() call failed. Can't continue.");
server_address.sin_family = AF_INET; }
server_address.sin_addr.s_addr = htonl(INADDR_ANY);
server_address.sin_port = htons(port);
if (bind(sock, (struct sockaddr *)&server_address,
sizeof(server_address)) < 0 ) {
Shutdown("echo_server: bind() call failed. Can't continue.");
}

31 32
// see who's knocking at our (socket) door...
// check connected clients, deal with one line for each ready client
if (FD_ISSET(sock,&socks)) { for (i=0; i < 100; i++) {
// new client if (FD_ISSET(connected[i],&socks)) {
newconn = accept(sock, NULL, NULL); alive = ReadAndEcho(connected[i]);
if (newconn < 0) { if (! alive) {
printf("** FAILED TO CONNECT TO NEW CLIENT **\n"); close(connected[i]);
} connected[i] = 0; // client hung up
else { }
// find a home for new client socket }
found=0; }
for (i=0; i < 100 && ! found; i++) { }
if (connected[i] == 0) { }
printf("echo_server: Connected to new client.\n");
connected[i] = newconn;
found=1;
}
}
if (! found) {
printf("echo_server: OVERLOADED.\n");
close(newconn);
}
}
}
 33 34
void EchoClient(char *ip, int port) { CLIENT
int ReadAndEcho(int handle) {
struct sockaddr_in them; // address of server
char c=-1; int sock; // socket for communication w/ server
int count=1; int err;
int ret=1; int len;
char buf[512];
printf("echo_server: Reading, hoping for \\n...\n"); char c;
count = read(handle, &c, 1); // read one char int count;
while (c != '\n' && count > 0) { struct hostent *remip; // will use this one...
count = write(handle, &c, 1); // echo it unsigned long remip2; // or this one as the binary remote addr
if (count) {
bzero((char *)&them, sizeof(them));
putchar(c); them.sin_family = AF_INET;
count=read(handle, &c, 1); // read one char them.sin_port = htons(port); // hton*() convert integer byte order
}
} // try inet_addr() call first; some unixes freak if we provide a
if (count == 0) { // dotted numeric IP address to gethostbyname()
printf("echo_server: Client hung up.\n"); remip2=inet_addr(ip);
ret=0; if (remip2 <= 0) {
} remip=gethostbyname(ip);
else { // echo final \n if (remip == NULL) {
herror(NULL);
count = write(handle, &c, 1); Shutdown("Couldn't initialize connection parameters.");
putchar('\n'); }
} }
printf("echo_server: Returning to listening state.\n");
return ret;

35 36
printf("echo_client: \".\" on a line by itself disconnects.\n");
if (remip2 <= 0) { gets(buf);
memcpy(&(them.sin_addr.s_addr), remip->h_addr, remip->h_length); while (buf[0] != '.') {
} len=strlen(buf);
else { buf[len++]='\n'; // add newline
them.sin_addr.s_addr = remip2; buf[len]=0;
} write(sock, buf, strlen(buf)); // transmit
if ((sock=socket(AF_INET, SOCK_STREAM, 0)) < 0) {
printf("echo_client: socket() failed with error %d.\n", sock); // get response one char at a time
Shutdown("Can't continue."); printf("echo_client: Service response:\"");
} count = read(sock, &c, 1);
while (c != '\n' && count > 0) {
if ((err = connect(sock, (struct sockaddr*)&them, putchar(c);
sizeof(struct sockaddr_in)))) { count=read(sock, &c, 1); // read one char
printf("echo_client: connect() failed with error %d.\n", err); }
Shutdown("Can't continue."); printf("\"\n");
} if (count == 0) {
printf("echo_client: Server hung up. How rude!\n");
buf[0]='.';
}
gets(buf);
}
close(sock);
} // end of EchoClient
 37 38
Java IPC Simple TCP Client in Java
 TCP and UDP socket protocols have
try {
separate interfaces in Java s=new Socket(servhostname, port);
 More abstract than standard Unix out=new DataOutputStream(s.getOutputStream());
in=new DataInputStream(s.getInputStream());
interface, but interoperable and almost as }
powerful catch (Exception e) {
/* error */
 Far more portable }
 Simple Java TCP Client // do standard I/O operations on ‘in’ and ‘out’

 Simple Java TCP Server

 Simple Java UDP datagram send/receive

39 40
Simple TCP Server in Java Limitations
try {
servsock=new ServerSocket(listenport);  Simple client/server are single threaded
}
catch (Exception e) { /* error */ }
...  Affects server most, since it can only
while ( … ) {
try { service only client at a time
cl=servsock.accept()
out=new DataOutputStream(cl.getOutputStream());
in=new DataInputStream(cl.getInputStream());  Other clients are blocked while server is
// do standard I/O operations on ‘in’ and ‘out’
… busy
cl.close();
}
catch (Exception e) {
 “Bad” client can tie up server forever
/* error for this client connection */

}
}  Java does NOT support select() for
sockets
 41 42
Simple UDP Client/Server in Java Multithreading for the TCP Server
byte[] buf = new byte[MAXDGRAMSIZE]; public class MTServer {
sock=new DatagramSocket(myport); public static void main(String[] args) {
while (...) { int port=2345;
try { final int MaxClients = 35;
// incoming datagram ...
DatagramPacket ingram = new ServerSocket serversocket = null;
DatagramPacket(buf, buf.length);
try {
sock.receive(ingram);
…
serversocket = new ServerSocket(port,
// outgoing datagram MaxClients);
DatagramPacket outgram = new DatagramPacket(buf, buf.length, while (true) {
theiraddr, theirport); Socket sock = serversocket.accept();
sock.send(outgram); ServerThread thr = new ServerThread(sock ...);
} thr.start();
catch (UnknownHostException uhe) { … } }
catch (IOException ioe) { } }
} catch (Exception e) { /* server must die */ }
}

43 44
Multithreading, Cont. Multithreading, Cont.
public class ServerThread extends Thread { public void run() {
private Socket sock; boolean bye=false;
try {
private DataInputStream in=null; while (!bye) {
private DataOutputStream out=null; String command = in.readUTF();
public ServerThread(Socket sock, ... ) { if (command.equals(“BYE”) {
this.sock = sock; bye = true; …
... }
try { else if (…) {
…
in=new DataInputStream(this.sock. }
getInputStream()); }
out=new DataOutputStream(this.sock. catch (Exception e) {
getOutputStream()); /* death for this client connection */
} }
catch (Exception e) { /* oops */ } finally {
/* cleanup for this client */
} out.close(); in.close();
}
}
 45 46
Robust TCP Java, TCP, and Robust Client/Server

 Want to detect broken connections, avoid client

and/or server “hangs”  The following read can hang indefinitely
 Timeouts (simple) if the server dies
 Unix “keepalive” timers (SO_KEEPALIVE)
– Evil!
try {
– Default is generally several hours! s = input.readUTF();
– Timeout period generally global, hard to configure // ...
 “Connection exercises” }
 Heartbeats catch (Exception e) {
Computer
ALIVE!
Computer
System.out.println(”Broken
ALIVE!
connection”);
ALIVE!
}
Computer Computer

47 48
TCP: Maintaining Control with Timeouts Server Side “Probing”
try { // Always detects broken connection
gotstr = false; try {
while (! gotstr) { gotstr = false;
try { while (! gotsr) {
sock.setSoTimeout(90000); // 90s timeout try {
sock.setSoTimeout(90000);
s = input.readUTF(); s = input.readUTF();
gotstr=true; gotstr=true;
} }
catch (InterruptedIOException ie) { catch (InterruptedIOException ie) {
// at least I’m not stuck! // timeout...tempt fate by writing
// can do other processing here System.out.println(”Connection check”);
} // client must ignore
} output.writeUTF("$!$");
System.out.println("Connection OK");
} }
catch (Exception e) { }
System.out.println(”Broken connection”); }
} catch (Exception e) {
System.out.println(”Broken connection”);
}
 49 50
Client Side “Probing” Higher-level Communication
// Clients wants to to read a string...
// Assumes that a response is expected w/in 30s  MOM (Message-oriented Middleware)
boolean significant=false;  Message-passing libraries
while (! significant) {
socket.setSoTimeout(30000); // 30s timeout – PVM
try {
s = input.readUTF(); – MPI
significant = (! s.equals("$!$"));
}  Spaces
catch (InterruptedIOException ie) {
// assume connection is broken – Linda
throw new IOException("Server is down?");
}  Object-based approaches
}
– RMI
– CORBA

51 52
Message Oriented Middleware MOM: Guts
 Weakens link between the client and  MOM system implements a queue
server… between clients and servers
 Client sees an asynchronous interface
 Each sends to other by enqueuing
 Request is sent independent of reply messages on one or more queues
 Reply must be dequeued from a reply
 Queues can have names, for
queue later
“subject” of the queue
 Client and server do not need to be
running at the same time.  Simple API
 53 54
MOM: Guts, Cont. Other MOM Issues?
 Administrative overhead

MOM API
client MOM – Management of the queues
request queue – Replication
– Load Balancing
reply  Handling runaway applications that
MOM API flood queue with requests or fail to
collect responses
server
 Cleanup after crashes
 Performance

55 56
PVM/MPI: Message Passing Libraries PVM Schematic pvmd

 Libraries which provide

– dynamic process creation
– message passing primitives
pvmd
– synchronization primitives
 Automatic assignment of new processes to
“master” pvmd
machines (currently round robin for PVM?)
 Primitive marshalling (“packing”) facilities, for
basic C/Fortran types only
pvmd
 User-installable resource managers for load
balancing, checkpointing (NO!!!!!!), etc.
Slave pvmd’s are
started via rsh…
 57 58
Simple PVM C Example, First Process Simple PVM C Example, Second Process

#include <stdio.h> #include "pvm3.h"

#include "pvm3.h"
int main(){
int main(){
int cc, tid; int ptid;
char buf[100]; char buf[100];
printf("i'm t%x\n", pvm_mytid()); ptid = pvm_parent();
cc = pvm_spawn("hello_other", (char**)0, 0, "", 1, &tid);
if (cc == 1) { strcpy(buf, "hello, world from ");
cc = pvm_recv(-1, -1); gethostname(buf + strlen(buf), 64);
pvm_bufinfo(cc, (int*)0, (int*)0, &tid); pvm_initsend(PvmDataDefault);
pvm_upkstr(buf);
printf("from t%x: %s\n", tid, buf); { pvm_pkstr(buf);
} pvm_send(ptid, 1);
else { pvm_exit();
printf("can't start hello_other\n"); exit(0);
}
pvm_exit(); }
exit(0);
}

59
Linda: Tuple Spaces
 Linda is a small “coordination” language
for distributed systems development with a
few simple operations
 Extends a traditional language like C or
FORTRAN or Java
 Easy for programmers since it isn’t
necessary to learn an entire language from
scratch
 Appropriate for “bag of tasks” problems
– e.g., many rendering algorithms in computer
graphics
60
Linda Operations
 out(t) puts a tuple t into the “bag”
 in(t) to get a tuple t from the bag
 rd(t) to read (w/o removing) a tuple t
 eval(t) to create a process to evaluate the
tuple t
 Predicate primitives (newer):
– inp, rdp test for presence, behave like
blocking versions if they return true
 61 62
Simple Linda Example Java is a Natural for Linda-ness
int main(int argc, char *argv[]) {
 Instead of tuple spaces, object spaces…bags
int nworker, j, hello();
nworker=atoi (argv[1]); of objects
for (j=0; j < nworker; j++)  Operations insert and remove arbitrary
eval ("worker", hello(j));
for(j=0; j < nworker; j++)
objects from the space
in("done" /* , could read other values here */);  Retrieve by “name” or by class
printf(“Got responses from all slaves.\n”);
}
 Fairly easy to implement because of object
serialization facility
int hello(int i) {
 Threaded implementations make powerful
printf("Slave %d reporting.\n",i);
out("done" /* , could return other values here */); extensions like transactions fairly easy
return(0);  JavaSpaces…
}

63
Java: RMI
 RMI: Remote Method Invocation
 Java’s OO facility provides a superset of RPC
(Remote Procedure Call) functionality
 RMI provides distributed objects for Java
– Objects can reside on different machines, and other objects
can invoke their methods
 When searching for objects on a remote host:
– rmi://host:port/name
 Port defaults to 1099 if omitted
64
RMI Compilation/Deployment
 Write interface for server
 Write server implementation
 Compile service interface, implementation
 Run rmic on server implementation
– Generates server_stub, server_skel
 Client needs only server interface
 Server needs server_stub
 rmiregistry runs on server machine
 Server provides location of server_stub to rmiregistry
 (Client will automatically download server_stub upon
a lookup, if necessary)
 65 66
RMI Schematic RMI-in-action Schematic
O.a(..)
Client Server_stub Server_skel Client Server_stub

O = (server_type)lookup() rmiregistry
RMIC

Server_skel bind(this)
Server
public interface server
Server_Interface Server
a(..)

67 68
Simple RMI Server Interface Simple RMI Client
// Meaning of life server interface. // Meaning of life client

import java.lang.*;
import java.lang.*; import java.io.*;
import java.rmi.*;
import java.io.*; public class RMI_MOLClient {
import java.rmi.*; public static void main (String args[]) throws Exception {
if (args.length != 1) {
throw new RuntimeException("Usage: java RMIMOLClient <host>");
}
public interface RMI_MOLServerInterface extends Remote { System.setSecurityManager(new RMISecurityManager());
RMI_MOLServerInterface mol = null;
try {
// reveal the meaning of life mol = (RMI_MOLServerInterface)Naming.lookup("rmi://"+ args[0] +
public String reveal() throws java.rmi.RemoteException; "/MOL");
}
} catch (java.rmi.NotBoundException e1) {
System.out.println("No MOL service object bound on that host.");
}
catch (java.rmi.ConnectException e2) {
System.out.println("Either the RMI registry or the MOL service is dead on
that host.");
}
if (mol != null) {
System.out.println(mol.reveal());
}
}
}
 69 70
Simple RMI Server Implementation Compile…
// Meaning of life server implementation.
 javac RMI_MOLServerInterface.java
import java.lang.*;
import
import
java.io.*;
java.rmi.*;  javac RMI_MOLServer.java
import java.rmi.server.UnicastRemoteObject;

public class RMI_MOLServer extends UnicastRemoteObject

 javac RMI_MOLClient.java
implements RMI_MOLServerInterface {
public RMI_MOLServer(String mol) throws RemoteException {  rmic RMI_MOLServer
System.setSecurityManager(new RMISecurityManager());

}
this.mol = mol;
– generates RMI_MOLServer_stub.class and
public String reveal() throws java.rmi.RemoteException {
return mol; RMI_MOLServer_skel.class
}
public static void main (String args[]) throws Exception {
if (args.length != 1) {  Run rmiregistry on server end
throw new RuntimeException("Usage: java RMI_MOLServer <string>");
}
RMI_MOLServer us = new RMI_MOLServer(args[0]);
 To run client and server…
Naming.rebind("MOL", us); java -Djava.security.policy="policy.all“ -Djava.rmi.server.codebase=
}
"file://c:/rmi/mol/" RMI_MOLServer "Life ain’t no box of chocolates.”
// shhhhhhhh!
private String mol;
}
java -Djava.security.policy="policy.all" RMI_MOLClient localhost

Un/reliable Communication 71
RPC Design 72

 Reliable Communication  Structure

– Virtual circuit: one path between sender & receiver. All – Caller: local call + stub
packets sent through the path.
– Callee: stub + actual procedure
– Data received in the same order as it is sent.
 Binding
– TCP (Transmission Control Protocol) provides reliable
communication. – Where to execute? Name/address of the server that offers
a service
 Unreliable communication
– Name server with inputs from service specifications of a
– Datagrams: Different packets are sent through different task.
paths.
 Parameter & results
– Data might be lost or out of sequence.
– Packing: Convert to remote machine format
– UDP (User datagram Protocol) provides unreliable
communication. – Unpacking: Convert to local machine format
 73 74
RPC Execution RPC Semantics
Binding  At least once
Server Register – A RPC results in zero or more invocation.
Receive Services – Partial call, i.e., unsuccessful call: zero, partial, one or
Local Proc. Stub Query Stub Remote Proc.
more executions.
Local Query
call Return Execute  Exactly once
binding Unpack
Server Address procedure
server – Only one call maximum
Params – Unsuccessful? : zero, partial, or one execution
Local
packing call  At most once
Wait – Zero or one. No partial executions.
Unpack Pack
Return results Return
result

Caller Callee

RPC Implementation 75
RPC Execution
76

 Sending/receiving parameters: Binding

– Use reliable communication? : Server Register
– Use datagrams/unreliable? Receive Services
Local Proc. Stub Query Stub Remote Proc.
– Implies the choice of semantics: how many times a RPC
Local Query
may be invoked. Return Execute
call binding Unpack
Server Address procedure
server

Params Local
packing call
Wait
Pack
Return Unpack
results Return
result

Caller Callee
 Sun RPC Specification 77
Sun RPC: Server Side 78

Server Side: server.c:

#include “unpipc.h” /* local headers */
square.x: /* file name */
#include “square.h” /* generated by RPCgen */
struct square_in { /* input argument */
long arg1;
square_out * squareproc_1_svc (square_in *inp, struct svc_reg *rqstp) {
}
static square_out out;
struct square_out { /* output argument */
long res2;
out.res1 = inp->arg1 * inp->arg1;
}
return(&out);
program SQUARE_PROG {
}
version SQUARE_VERS {
square_out SQUAREPROC(square_in) = 1; /* procedure no. = 1 */ Compilation Procedures:
cc –c server.c –o server.o
} = 1; /* version number */ cc –c square_svc.c –o square_svc.o /* contains “main” */
} = 0x3123 0000; /* program number */ cc –o server server.o square_svc.o square.xdr.o libunpipc.a -lnsl
Notes:
Compilation Procedure: libunpipc.a: library used in Stevens book; lnsl: Solaris system library
rpcgen –C square.x /* -C: generate C prototypes in square.h */ Including RPC and XDR runtime functions

Client Side 79
Client Compilation 80

client.c :
Compilation:
#include “unpipc.h” /* local headers */
#include “square.h” /* generated by rpcgen */ cc –c client.c –o client.o
cc –c square_clnt.c –o square_clnt.o
main(int argc, char **argv) { cc –c square_xdr.c –o square_xdr.o
CLIENT *cl; /* defined in rpc.h */ cc –o client client.o square_client.o square_xdr.o libunpipc.a -lnsl
square_in in; Notes:
square_out *outp; Rpcgen: generates square_xdr.c -> XDR data conversions
square_clnt.c -> client stub
if (argc != 3) err_quit(“usage: client <hostname> <integer_value>”); Execution:
cl = Clnt_create(argv[1], SQUARE_PROG, SQUARE_VERS, “tcp”);
in.arg1 = atol(argv[2]); client bsdi 11 -> result: 121
if ((outp = squareproc_1(&in, cl) == NULL) client 209.76.87.90 22 -> result: 484
err_quit(“%s”, clnt_sperror(cl, argv[1])); client nosuchhost 11 -> nosuchhost:RPC:Unknownhost….
printf(“result: %d\n”, outp->res1); Client localhost 11 -> localhost: RPC: Program not registered
exit(0);
}
 RPC Client-Server 81
RPC Implementation 82

RPC Specification File  Sending/receiving parameters:

square.x – Use reliable communication? :
– Use datagrams/unreliable?
rpcgen
– Implies the choice of semantics: how many times a RPC
#include may be invoked.
square.h

Reference Book:
client.c square_clnt.c square_xdr.c square_svc.c server.c Unix Network Programming by Richard Stevens, Prentice-Hall.

Runtime
cc library cc

client server