Distributed System Structures

1
(No Transcript)
2
Distributed System Structures

• Introduction
• Design Goals
• Distributed Operating Systems
• Network Operating Systems
• Middleware-Based Systems
• Client-Server Model
• Peer-to-Peer Computing Model
• Communication Protocols
• Sockets
• Remote Procedure/Method Calls

3
Distributed Systems

• A distributed system is a collection of loosely
  coupled processors interconnected by a
  communication network.
• Implications
• No shared physical memory
• Communication/coordination through message
  passing
• No global clock
• Difficulty of keeping track of global state with
  accuracy
• Independent failure considerations

4
A Distributed System
5
Example Distributed System Internet
intranet


ISP


backbone
satellite link
desktop computer
server
network link
6
Example Distributed System Intranet

• An intranet is a portion of the Internet that is
  separately administered and has a boundary that
  can be configured to enforce local security
  policies.

7
Why build Distributed Systems?

• Resource Sharing expensive/rarely used
  hardware, large databases
• Computation Speedup divide computation in to
  tasks that can execute concurrently, can include
  the ability to use idle cycles elsewhere
  (SETI_at_HOME)
• Reliability via redundancy
• Communication file transfer, mail, RPC

8
Design Goals in Distributed Systems

• Overcoming Heterogeneity
• Security
• Concurrency
• Transparency
• Failure Handling
• Scalability

9
Scalability

• A system is described as scalable if it will
  remain effective when there is significant
  increase in the number of users and the number of
  resources.
• Internet provides an illustration of a
  distributed system for a drastic increase of
  computers/services.

10
Scalability (Cont.)

• If more users or resources need to be supported
  we are often confronted with limitations of
• Centralized services (e.g. a single server for
  all users)
• Centralized data (e.g. a single on-line telephone
  book)
• Centralized algorithms (e.g. doing routing based
  on complete information)
• In decentralized (distributed) algorithms
• No machine has complete information about the
  system state.
• Machines make decisions based only on local
  information.
• Failure of one machine does not ruin the
  algorithm.
• There is no implicit assumption that a global
  clock exists.

11
Design Challenges for Scalability

• Avoiding performance bottleneck through
• Caching
• Replication
• Distribution
• Use of distributed algorithms

12
Case Study in Scalability Domain Name System
(DNS)

• The first component of network communication is
  the naming (i.e. the way components refer to each
  other) of the systems in the network.
• Identify processes on remote systems by
• lthost-name, identifiergt pair.
• Need to provide a mechanism to resolve the
  symbolic host name into a numerical host-id that
  describes the destination system to the
  networking hardware.
• In Internet, Domain Name System (DNS) specifies
  the naming structure of the hosts, as well as
  name-to-address resolution.

13
DNS and Name Resolution

• Generally, DNS resolves addresses by examining
  the host name components in reverse order.
• If the host name is flits.cs.vu.nl, then first
  the name server for the .nl domain will be
  contacted.
• Name resolution may proceed in either iterative
  fashion, or recursive fashion.
• Local caches are usually kept at each name server
  to enhance the performance.

14
DNS Scaling through distribution
15
OS Structures in Distributed Systems

• Operating systems for distributed systems can be
  roughly divided into two categories
• Distributed Operating Systems The OS
  essentially tries to maintain a single, global
  view of the resources it manages (Tightly-coupled
  operating system)
• Network Operating Systems Collection of
  independent operating systems augmented by
  network services (Loosely-coupled operating
  system)
• Modern distributed systems are mostly designed to
  provide a level of transparency between these two
  extremes, through the use of middleware.

16
Distributed Operating Systems

• Full transparency, users are not aware of the
  multiplicity of machines.
• Access to remote services similar to access to
  local resources.

17
Distributed Operating Systems (Cont.)

• Each node has its own kernel for managing local
  resources (memory, local CPU, disk, ).
• The only means of communication among nodes is
  through message passing.
• Above each kernel is a common layer of software
  that implements the OS supporting parallel and
  concurrent execution of various tasks.
• This layer may even provide a complete software
  implementation of shared memory (distributed
  shared memory)
• Additional facilities may include, task
  assignments to processors, masking hardware
  failures, transparent storage, general
  interprocess communication, or data/computation/pr
  ocess migration.

18
Network Operating Systems

• NOS does not try to provide a single view of the
  distributed system.
• Users are aware of the multiplicity of the
  machines.

19
Network Operating Systems (Cont.)

• NOS provide facilities to allow users to make use
  of services in other machines
• Remote login (telnet, rlogin)
• File transfer (ftp)
• Users need to explicitly log on into remote
  machines, or copy files from one machine to
  another.
• Need multiple passwords, multiple access
  permissions.
• In contrast, adding or removing a machine is
  relatively simple.

20
Middleware-Based Systems

• Achieving full and efficient transparency with
  distributed operated systems is a major task
• On the other hand, a higher level of abstraction
  is highly desired on top of network operating
  systems.

21
Middleware-Based Systems (Cont.)

• Each local system forming part of the underlying
  NOS provides local resource management in
  addition to simple communication.
• The concept of middleware was introduced due to
  the integration problems of various networked
  applications (distributed transactions and
  advanced communication facilities).
• Example middlewares Remote Procedure Calls,
  Remote Method Invocations, Distributed File
  Systems, Distributed Object Systems (CORBA)

22
Client-Server Model

• How to organize processes in a distributed
  environment?
• Thinking in terms of clients that request
  services from servers helps understanding and
  managing the complexity.

23
Client-Server Model (Cont.)

• Servers may in turn be clients of other servers
  vertical distribution (example web crawlers at
  a search engine)
• Services may be also implemented as several
  server processes in separate host computers
  interacting as necessary to provide a service to
  client processes horizontal distribution
• The servers may partition the set of objects on
  which the service is based and distribute them
  between themselves.
• Replication may be used to increase performance,
  availability and to improve fault tolerance.

24
Client-Server Model (Cont.)

• An example of horizontal distribution of a Web
  Service

25
Peer-to-peer (P2P) systems

• As an alternative to the client-server model,
  interacting processes may act cooperatively as
  peers to perform a distributed activity or
  computation
• Example distributed whiteboard application
  allowing users on several computers to view and
  interactively modify a picture that is shared
  between them
• Middleware layers will perform event notification
  and group communication.
• P2P networks gained popularity in the late 90s
  with file-sharing services (e.g. Napster,
  Gnutella)

26
P2P Systems (cont.)
Peer 2
Peer 1
Application
Application
Peer 3
Sharable
objects
Application
Peer 4
Application
Peers 5 .... N
27
Communication Structure
The design of a communication network must
address four basic issues

• Naming and name resolution - How do two
  processes locate each other to communicate?
• Routing strategies - How are messages sent
  through the network?
• Connection strategies - How do two processes
  send a sequence of messages?
• Contention - The network is a shared resource,
  so how do we resolve conflicting demands for its
  use?

28
Communication Protocols

• The systems on a network must agree on a
  concrete set of rules and formats before
  undertaking a communication session.
• The rules are formalized in what are called
  protocols. Ex FTP, HTTP, SMTP, telnet,
• The definition of a protocol contains
• A specification of the sequence of messages that
  must be exchanged
• A specification of the format in the data in the
  messages

29
OSI Protocol Model

• The International Standards Organization (ISO)
  developed a reference model identifying the
  various levels involved, and pointing out which
  level performs which task (Open Systems
  Interconnection Reference Model OSI model).

30
OSI Protocol Model

• Each layer provides service to the one above it
  through a well-defined interface.
• On the sending side, each layer adds a header to
  the message passed by the layer above and passes
  it down to the layer below.
• On the receiving side, the message is passed
  upward, with each layer stripping off and
  examining its own header.

31
Layers in OSI Protocol Model

• Physical Layer Mechanical and electrical
  network-interface connections implemented in
  the hardware
• Data Link LayerFraming, error detection and
  recovery
• Network LayerProviding host-to-host connections,
  routing packets (routers work at this layer)
• Transport LayerEnd-to-end connection management,
  message partitioning into packets, packet
  ordering, flow and error control

32
Layers in OSI Protocol Model (Cont.)

• Session LayerDialog and synchronization control
  for application entities (remote login, ftp, )
• Presentation LayerData representation
  transformations to accommodate heterogeneity,
  encryption/decryption
• Application Layer Protocols designed for
  specific requirements of different applications,
  often defining interfaces to services

33
TCP/IP Protocols

• Dominant Internetworking protocol suite used in
  Internet.
• Fewer layers than ISO model, combines multiple
  functions at each layer ? High efficiency (but
  more difficult to implement)
• Many application services and application-level
  protocols exist for TCP/IP, including the Web
  (HTTP), email (SMTP, POP), netnews (NNTP), file
  transfer (FTP) and Telnet.

34
ISO vs. TCP/IP Protocol Stacks
35
IP Layer

• Performs the routing function
• Provides datagram packet delivery service
• No set-up is required
• Packets belonging to the same message may follow
  different paths
• Packets can be lost, duplicated, delayed or
  delivered out of order
• The IP layer
• puts IP datagrams into network packets suitable
  for transmission in the underlying networks
• may need to break the datagram into smaller
  packets
• Every IP packet contains the full network address
  of the source and destination hosts.

36
IP Address Structure
37
TCP and UDP (Transport Layer)

• Whereas IP supports communication between pairs
  of computers (identified by their IP addresses),
  TCP and UDP, as transport protocols, provide
  process-to-process communication.
• Port numbers are used for addressing messages to
  processes within a particular computer.
• UDP is almost a transport-level replica of IP.
• A UDP datagram
• is encapsulated inside an IP packet
• includes a short header indicating the source and
  destination port numbers, a length field and a
  checksum

38
TCP and UDP (Transport Layer)

• UDP provides connectionless service
• no need for initial connection establishment
• no guarantee for reliable delivery is provided
• TCP is connection-oriented
• TCP layer software provides delivery guarantee
  for all the data presented by the sending
  process, in the correct order.
• Before any data is transmitted, the sending and
  receiving processes must co-operate to establish
  a bi-directional communication channel.

39
Sockets

• A socket is an endpoint for communication made up
  of an IP address concatenated with a port number.
  
• A pair of processes communicating over a network
  employ a pair of sockets.
• The server waits for incoming client requests by
  listening to a specified port. Once a request is
  received, the server accepts a connection from
  the client socket to complete the connection.

40
Socket programming
Goal learn how to build client/server
application that communicate using sockets

• Socket API
• introduced in BSD4.1 UNIX
• explicitly created, used, released by apps
• client/server paradigm
• two types of transport service via socket API
• unreliable datagram (UDP)
• reliable, byte stream-oriented (TCP)

41
Port Numbers

• Servers implementing specific services listen to
  well-known ports (All ports below 1024 are
  considered well-known).
• Telnet server port 23
• FTP server port 21
• HTTP server port 80
• When a client process initiates a request for a
  connection, it is assigned a port by the host
  computer.
• Berkeley Sockets Interface and X/Open Transport
  Interface are well-known socket implementations.

42
Trying out http (client side) for yourself

• 1. Telnet to your favorite Web server

Opens TCP connection to port 80 (default http
server port) at www.eurecom.fr. Anything typed in
sent to port 80 at www.eurecom.fr
telnet www.eurecom.fr 80
2. Type in a GET http request
By typing this in (hit carriage return twice),
you send this minimal (but complete) GET request
to http server
GET /ross/index.html HTTP/1.0
3. Look at response message sent by http server!
43
TCP/IP Sockets

• Sockets may use TCP or UDP protocol when
  connecting hosts in the Internet.
• TCP requires a connection establishment phase and
  provides guaranteed delivery.
• UDP does not require a connection set-up phase,
  however provides only a best-effort delivery
  service.
• Communication primitives are slightly different
  in two cases.

44
The programmer's conceptual view of a TCP/IP
Internet
45
Socket programming with TCP

• Client must contact server
• server process must first be running
• server must have created socket (door) that
  welcomes clients contact
• Client contacts server by
• creating client-local TCP socket
• specifying IP address, port number of server
  process

• When client creates socket client TCP
  establishes connection to server TCP
• When contacted by client, server TCP creates new
  socket for server process to communicate with
  client
• allows server to talk with multiple clients

46
Client-Server Communication with Sockets (TCP)
47
Berkeley Sockets API

• Socket primitives for TCP/IP.

48
C server (TCP)
/ A simple server in the internet domain using
TCP/ include ltstdio.hgt include ltsys/types.hgt
include ltsys/socket.hgt include
ltnetinet/in.hgt int main(int argc, char argv)
int sockfd, newsockfd, portno, clilen, n
char buffer256 struct sockaddr_in
serv_addr, cli_addr sockfd
socket(AF_INET, SOCK_STREAM, 0) if (sockfd
lt 0) error("ERROR opening socket")
bzero((char ) serv_addr, sizeof(serv_addr))
portno 6789 serv_addr.sin_family
AF_INET serv_addr.sin_addr.s_addr
INADDR_ANY serv_addr.sin_port
htons(portno) if (bind(sockfd, (struct
sockaddr ) serv_addr,sizeof(serv_addr)) lt 0)
error("ERROR on binding")
listen(sockfd,5) clilen
sizeof(cli_addr) newsockfd accept(sockfd,
(struct sockaddr ) cli_addr, clilen) if
(newsockfd lt 0) error("ERROR on accept")
bzero(buffer,256) n read(newsockfd,buffer,
255) if (n lt 0) error("ERROR reading from
socket") printf("Here is the message
s\n",buffer) n write(newsockfd,"I got
your message",18) if (n lt 0) error("ERROR
writing to socket") return 0

Create socket at port 6789
Wait, on welcoming socket for contact by client
Read/Write line from/to socket
49
Java server (TCP)
import java.io. import java.net. class
TCPServer public static void main(String
argv) throws Exception String
clientSentence String capitalizedSentence
ServerSocket welcomeSocket new
ServerSocket(6789) while(true)
Socket connectionSocket
welcomeSocket.accept()
BufferedReader inFromClient new
BufferedReader(new
InputStreamReader(connectionSocket.getInputStream(
))) DataOutputStream outToClient
new DataOutputStream(connectionSocket.g
etOutputStream()) clientSentence
inFromClient.readLine()
capitalizedSentence clientSentence.toUpperCase()
'\n'
outToClient.writeBytes(capitalizedSentence)

Create socket at port 6789
Wait, on welcoming socket for contact by client
Create input/output streams, attached to socket
Read/Write line from/to socket
50
C client (TCP)
include ltarpa/inet.hgt include ltnetdb.hgt int
main(int argc, char argv) int sockfd,
portno, n struct sockaddr_in serv_addr
struct hostent server char buffer256
portno atoi(argv2) sockfd
socket(AF_INET, SOCK_STREAM, 0) if (sockfd lt
0) error("ERROR opening socket") server
gethostbyname(argv1) if (server NULL)
fprintf(stderr,"ERROR, no such host\n")
exit(0) bzero((char ) serv_addr,
sizeof(serv_addr)) serv_addr.sin_family
AF_INET bcopy((char )server-gth_addr, (char
)serv_addr.sin_addr.s_addr,server-gth_length)
serv_addr.sin_port htons(portno) if
(connect(sockfd,serv_addr,sizeof(serv_addr)) lt
0) error("ERROR connecting") printf("Please
enter the message ") bzero(buffer,256)
fgets(buffer,255,stdin) n
write(sockfd,buffer,strlen(buffer)) if (n lt
0) error("ERROR writing to socket")
bzero(buffer,256) n read(sockfd,buffer,255)
if (n lt 0) error("ERROR reading from
socket") printf("s\n",buffer) return
0
Create client socket, connect to server
Send line to server
Read line from server
Read in line from socket
51
Java client (TCP)
import java.io. import java.net. class
TCPClient public static void main(String
argv) throws Exception String
sentence String modifiedSentence
BufferedReader inFromUser new
BufferedReader(new
InputStreamReader(System.in)) Socket
clientSocket new Socket("hostname", 6789)
DataOutputStream outToServer
new DataOutputStream(clientSocket.getOu
tputStream()) BufferedReader
inFromServer new BufferedReader(new
InputStreamReader(clientSocket.getInputSt
ream())) sentence inFromUser.readLine(
) outToServer.writeBytes(sentence
'\n') modifiedSentence
inFromServer.readLine()
System.out.println("FROM SERVER "
modifiedSentence)
clientSocket.close()

Create input stream
Create client socket, connect to server
Create output/input streams attached to socket
Send line to server
Read line from server
Read in line from socket
52
Socket programming with UDP

• UDP no connection between client and server
• no handshaking
• sender explicitly attaches IP address and port of
  destination
• server must extract IP address, port of sender
  from received datagram
• UDP transmitted data may be received out of
  order, or lost

53
Client/server socket interaction UDP
Server (running on hostid)
read request from server Socket
54
Example Java server (UDP)
import java.io. import java.net. class
UDPServer public static void main(String
args) throws Exception
DatagramSocket serverSocket new
DatagramSocket(9876) byte
receiveData new byte1024 byte
sendData new byte1024 while(true)
DatagramPacket
receivePacket new
DatagramPacket(receiveData,
receiveData.length)
serverSocket.receive(receivePacket)
Create datagram socket at port 9876
Create space for received datagram
Receive datagram
55
Example Java server (UDP), cont
String sentence new
String(receivePacket.getData())
InetAddress IPAddress receivePacket.getAddress()
int port receivePacket.getPort()
String
capitalizedSentence
sentence.toUpperCase() sendData
capitalizedSentence.getBytes()
DatagramPacket sendPacket new
DatagramPacket(sendData, sendData.length,
IPAddress, port)
serverSocket.send(sendPacket)

Get IP addr port , of sender
Create datagram to send to client
Write out datagram to socket
End of while loop, loop back and wait for another
datagram
56
Example Java client (UDP)
import java.io. import java.net. class
UDPClient public static void main(String
args) throws Exception
BufferedReader inFromUser new
BufferedReader(new InputStreamReader(System.in))
DatagramSocket clientSocket new
DatagramSocket() InetAddress IPAddress
InetAddress.getByName("hostname")
byte sendData new byte1024 byte
receiveData new byte1024 String
sentence inFromUser.readLine() sendData
sentence.getBytes()
Create input stream
Create client socket
Translate hostname to IP address using DNS
57
Example Java client (UDP), cont.
Create datagram with data-to-send, length, IP
addr, port
DatagramPacket sendPacket new
DatagramPacket(sendData, sendData.length,
IPAddress, 9876) clientSocket.send(send
Packet) DatagramPacket receivePacket
new DatagramPacket(receiveData,
receiveData.length) clientSocket.receiv
e(receivePacket) String
modifiedSentence new
String(receivePacket.getData())
System.out.println("FROM SERVER"
modifiedSentence) clientSocket.close()

Send datagram to server
Read datagram from server
58
Remote Procedure Calls

• A communication middleware solution.
• Idea Handle communication as transparently as a
  (local) procedure call.
• Allowing programs to call procedures located on
  other machines.

59
Remote Procedure Call

• When a process on the client machine A calls a
  procedure on the server machine B, the calling
  process on A is suspended.
• Information can be transported from the caller to
  the callee in the parameters and can come back in
  the procedure result.
• No message passing at all is visible to the
  programmer.

60
RPC Client and Server Stubs

• For the client and server sides, the library
  procedures will act between the caller/callee and
  the Operating System.
• When a remote procedure is called, the client
  stub will pack the parameters into a message and
  call OS (through send primitive). It will then
  block itself (through receive primitive).
• The server stub will unpack the parameters from
  the message and will call the local procedure in
  a usual way. When the procedure completes, the
  server stub will pack the result and return it to
  the client.

61
Remote Procedure Calls (1)

• A remote procedure call occurs in the following
  steps
• The client procedure calls the client stub in the
  normal way.
• The client stub builds a message (marshalling the
  parameters) and calls the local operating system.
• The clients OS sends the message across the
  network to the remote OS.
• The remote OS gives the message to the server
  stub.
• The server stub unpacks the parameters
• Calls the server implementing the function.
  Continued

62
Implementing RPC

• Client stub and server stub communicate over the
  network to perform RPC

Server Process
Client Machine
ServerMachine
Server Stub
Server OS
63
Remote Procedure Calls (2)

• A remote procedure call occurs in the following
  steps (continued)
• The server does the work and returns the result
  to the stub.
• The server stub packs it in a message and calls
  its local OS.
• The servers OS sends the message across the
  network to the clients OS.
• The clients OS gives the message to the client
  stub.
• The stub unpacks the result and returns to the
  client.

64
Implementing RPC

• Client stub and server stub communicate over the
  network to perform RPC

Server Process
Client Machine
ServerMachine
Server Stub
Server OS
65
Parameter Passing in RPC

• Packing parameters into a message is called
  parameter marshaling.
• Passing value parameters
• Poses no problems as long as both machines have
  the same representation for all data types
  (numbers, characters, etc.)
• May not be taken for granted
• Floating-point numbers and integers may be
  represented in different ways.
• Some architectures (e.g. Intel Pentium) numbers
  its bytes from right to left, while some others
  (e.g. Sun SPARC) numbers from left to right.

66
Parameter Passing in RPC (Cont.)

• Passing reference parameters
• Pointers, and in general, reference parameters
  are passed with considerable difficulty because a
  pointer is only meaningful in the address space
  of the process where it is used.
• Solutions
• Forbid reference parameters
• Copy the entire data structure (e.g. an entire
  array may be sent if the size is known).
• Straightforward for some parameter types (arrays
  for example) but not in general.
• How to handle complex data structures (e.g.
  general graphs) ?

67
Stub Generation

• Hiding a remote procedure call requires that the
  caller and callee agree on
• the format of the messages
• the representation of simple data structures
• the transport layer protocol
• Once the RPC protocol has been completely
  defined, the client and server stubs need to be
  implemented.
• Stubs for the same protocol but different
  procedures generally differ only in their
  interface to applications.
• Interfaces are often specified by means of an
  Interface Definition Language (IDL). After an
  interface is specified in such an IDL, it is
  then compiled into clientserver stubs.

68
Writing a Client and a Server (1)

• User generates client, server and an interface
  definition file. The code file must include the
  header file (to be generated).

69

• include ltstdio.hgt
• include ltrpc/rpc.hgt
• include "RPCTest.h"
• main(int argc, charargv)
• CLIENT clientHandle
• char serverName "cs1.gmu.edu"
• readargs a
• Data data
• clientHandle
• clnt_create(serverName,FILEREADWRITE,V
  ERSION,"udp")
• / creates a socket and a client
  handle /
• if (clientHandle NULL)
• clnt_pcreateerror(serverName) / unable to
  contact server /
• exit(1)
• a.val1 10
• a.val2 20
• data double_1(a,clientHandle) / call to
  remote procedure /
• printf("d\n",data)
• clnt_destroy(clientHandle)

Client Code
70

• include ltstdio.hgt
• include ltrpc/rpc.hgt
• include "RPCTest.h"
• Data double_1(readargs a)
• static Data result / must be static /
• result a-gtval1 a-gtval2
• return result
• typedef int Data
• struct readargs
• int val1 int val2
• / pack multiple arguments into struct /
• program FILEREADWRITE

Server Code
Remote function double
Interface Specification
71
Writing a Client and a Server (2)

• Four files output by the Sun RPC IDL compiler
  from the interface definition file
• A header file (e.g., interface.h, in C terms).
• XDR file describes data details
• The client stub.
• The server stub.

All must include header file
72
Writing a Client and a Server (1)
XDR code
C compiler
XDR obj file

• Figure 4-12. The steps in writing a client and a
  server in Sun RPC.

73

• /
• Please do not edit this file.
• It was generated using rpcgen.
• /
• ifndef _RPCTEST_H_RPCGEN
• define _RPCTEST_H_RPCGEN
• include ltrpc/rpc.hgt
• typedef int Data
• struct readargs int val1 int val2
• typedef struct readargs readargs
• define FILEREADWRITE 9999
• define VERSION 1
• define DOUBLE 1
• extern Data double_1()
• extern int filereadwrite_1_freeresult()
• / the xdr functions /
• extern bool_t xdr_Data()
• extern bool_t xdr_writeargs()
• extern bool_t xdr_readargs()

Header File
74

• /
• Please do not edit this file.
• It was generated using rpcgen.
• /
• include "RPCTest.h"
• ifndef _KERNEL
• include ltstdio.hgt
• include ltstdlib.hgt / getenv, exit /
• endif / !_KERNEL /
• / Default timeout can be changed using
  clnt_control() /
• static struct timeval TIMEOUT 25, 0
• Data double_1(argp, clnt)
• readargs argp
• CLIENT clnt
• static Data clnt_res
• memset((char )clnt_res, 0, sizeof
  (clnt_res))
• if (clnt_call(clnt, DOUBLE,
• (xdrproc_t) xdr_readargs,
  (caddr_t) argp,
• (xdrproc_t) xdr_Data, (caddr_t)
  clnt_res,

Client Stub
75

• /
• Please do not edit this file.
• It was generated using rpcgen.
• /
• include "RPCTest.h"
• static void
• closedown(sig)
• int sig
• static void filereadwrite_1(rqstp, transp)
• struct svc_req rqstp
• register SVCXPRT transp

Server Stub (lots of code omitted)
76
XDR file

• /
• Please do not edit this file.
• It was generated using rpcgen.
• /
• include "RPCTest.h"
• bool_t xdr_Data(xdrs, objp)
• register XDR xdrs
• Data objp
• if defined(_LP64) defined(_KERNEL)
• register int buf
• else
• register long buf
• endif
• if (!xdr_int(xdrs, objp)) return
  (FALSE)
• return (TRUE)

• bool_t xdr_readargs(xdrs, objp)
• register XDR xdrs
• readargs objp
• if defined(_LP64) defined(_KERNEL)
• register int buf
• else
• register long buf
• endif
• if (!xdr_int(xdrs, objp-gtval1)) return
  (FALSE)
• if (!xdr_int(xdrs, objp-gtval2)) return
  (FALSE)
• return (TRUE)

77
Binding a Client to a Server (1)

• Registration of a server makes it possible for a
  client to locate the server and bind to it.
• Server location is done in two steps
• Connect to the servers machine on known port.
• Locate the servers port on that machine.

78
Binding a Client to a Server (2)

• Figure 4-13. Client-to-server binding in DCE.
  SunRPC does not use directory server.

79
Asynchronous RPC (1)

• The interaction between client and server in a
  traditional RPC.

80
Asynchronous RPC (2)

• The interaction using asynchronous RPC.

81
Asynchronous RPC (3)

• A client and server interacting through two
  asynchronous RPCs.

82
Remote Method Invocation (RMI)

• RMI is a Java feature similar to RPC it allows a
  thread to invoke a method on a remote object.
• The main differences with RPC
• RPC supports procedural programming whereby only
  remote procedures or functions may be called.
  With RMI, it is possible to invoke methods on
  remote objects.
• In RMI, it is possible to pass objects as
  parameters to remote methods.

83
RMI

• RMI RPC Object-orientation
• Java RMI
• CORBA
• Middleware that is language-independent
• Microsoft DCOM/COM
• SOAP
• RMI on top of HTTP

84
Remote and local method invocations
85
Distributed Objects
2-16

• Common organization of a remote object with
  client-side proxy (loaded when the client binds
  to a remote object).

86
Binding a Client to an Object
Distr_object obj_ref //Declare a systemwide
object referenceobj_ref // Initialize the
reference to a distributed objectobj_ref-gt
do_something() // Implicitly bind and invoke a
method (a) Distr_object obj_ref //Declare a
systemwide object referenceLocal_object
obj_ptr //Declare a pointer to local
objectsobj_ref //Initialize the reference
to a distributed objectobj_ptr
bind(obj_ref) //Explicitly bind and obtain a
pointer to the local proxyobj_ptr -gt
do_something() //Invoke a method on the local
proxy (b)

• (a) Example with implicit binding using only
  global references
• (b) Example with explicit binding using global
  and local references

87
Distributed Objects

• Remote object references
• An identifier that can be used throughout a
  distributed system to refer to a particular
  remote object
• Remote interfaces
• CORBA provides an interface definition language
  (IDL) for specifying a remote interface
• JAVA RMI Java interface that extends Remote
  interface
• Actions remote invocations
• Remote Exceptions may arise for reasons such as
  partial failure or message loss
• Distributed Garbage Collection cooperation
  between local garbage collectors needed

88
RMI Programming

• RMI software
• Generated by IDL compiler
• Proxy (client side)
• Behaves like remote object to clients (invoker)
• Marshals arguments, forwards message to remote
  object, unmarshals results, returns results to
  client
• Skeleton (server side)
• Server side stub
• Unmarshals arguments, invokes method, marshals
  results and sends to sending proxys method
• Dispatcher (server side)
• Receives the request message from communication
  module, passes on the message to the appropriate
  method in the skeleton

89
RMI Programming

• Binder
• Client programs need a means of obtaining a
  remote object reference
• Binder is a service that maintains a mapping from
  textual names to remote object references
• Servers need to register the services they are
  exporting with the binder
• Java RMIregistry, CORBA Naming service
• Server threads
• Several choices thread per object, thread per
  invocation
• Remote method invocations must allow for
  concurrent execution

90
Java RMI

• Features
• Integrated with Java language libraries
• Security, write once run anywhere, multithreaded
• Object orientation
• Can pass behavior
• Mobile code
• Not possible in CORBA, traditional RPC systems
• Distributed Garbage Collection
• Remoteness of objects intentionally not
  transparent

91
Remote Interfaces, Objects, and Methods

• Objects become remote by implementing a remote
  interface
• A remote interface extends the interface
  java.rmi.Remote
• Each method of the interface declares
  java.rmi.RemoteException in its throws clause in
  addition to any application-specific clauses

92
Creating distributed applications using RMI

• Define the remote interfaces
• Implement the remote objects
• Implement the client (can be done anytime after
  remote interfaces have been defined)
• Register the remote object in the name server
  registry
• Generate the stub and client using rmic
• Start the registry
• Start the server
• Run the client

93
Java Client
import java.rmi. import java.rmi.registry. imp
ort java.net. public class RmiClient
static public void main(String args)
ReceiveMessageInterface rmiServer
Registry registry String
serverAddressargs0 String
serverPortargs1 String textargs2
System.out.println("sending "text" to
"serverAddress""serverPort) try
// get the registry
registryLocateRegistry.getRegistry(serverAddress,
(new Integer(serverPort)).intValue() )
// look up the remote object
rmiServer (ReceiveMessageInterface)(registry.
lookup("rmiServer")) // call the
remote method int i
rmiServer.receiveMessage(text)
System.out.println("received "i)
catch(RemoteException e) e.printStackTrace()
catch(NotBoundException e)
e.printStackTrace()
94
Java Server (1)
import java.rmi. import java.rmi.registry. imp
ort java.rmi.server. import java.net. public
class RmiServer extends java.rmi.server.UnicastRem
oteObject implements ReceiveMessageInterface
int thisPort String thisAddress
Registry registry // rmi registry for lookup
the remote objects. // This method is called
from the remote client by the RMI. // This is
the implementation of the ReceiveMessageInterface
. public int receiveMessage(String x) throws
RemoteException System.out.println(x
) return 42
95
Java Server (2)
public RmiServer() throws RemoteException
try // get the address of this host.
thisAddress (InetAddress.getLocalHost()).t
oString() catch(Exception e)
throw new RemoteException("can't get inet
address.") thisPort3232 //
this port(registrys port)
System.out.println("this address"thisAddress",p
ort"thisPort) try // create
the registry and bind the name and object.
registry LocateRegistry.createRegistry(
thisPort ) registry.rebind("rmiServer
", this) catch(RemoteException e)
throw e static public void
main(String args) try
RmiServer snew RmiServer() catch
(Exception e) e.printStackTrace()
System.exit(1)
96
Java Remote interface
import java.rmi. public interface
ReceiveMessageInterface extends Remote int
receiveMessage(String x) throws
RemoteException
97
The Naming class of Java RMIregistry
void rebind (String name, Remote obj) This
method is used by a server to register the
identifier of a remote object by name. void bind
(String name, Remote obj) This method can
alternatively be used by a server to register a
remote object by name, but if the name is already
bound to a remote object reference an exception
is thrown. void unbind (String name, Remote obj)
This method removes a binding. Remote
lookup(String name) This method is used by
clients to look up a remote object by name. A
remote object reference is returned. String
list() This method returns an array of Strings
containing the names bound in the registry.
98
Object References as Parameters
2-18

• The situation when passing an object by reference
  or by value. There is no analogous activity in
  RPC.

99
Classes supporting Java RMI