Transcript Interprocess Communication

CS 843 - Distributed Computing Systems
Chapter 4: Interprocess Communication
Chin-Chih Chang, [email protected]
From Coulouris, Dollimore and Kindberg
Distributed Systems:
Concepts and Design
Edition 3, © Addison-Wesley 2001
Introduction
• The characteristics of protocols for communication
between processes in a distributed system are
discussed in this chapter as shown in Figure 4.1.
• The application program interface to UDP provides a
message passing abstraction.
• The application program interface to TCP provides
the abstraction of a two-way stream between pairs
of processes.
• The Java UDP and TCP APIs are discussed in the
second section.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.1
Middleware layers
Applic ations, services
RMI and RPC
This
c hapter
reques t-reply protocol
marshalling and ex ternal data representation
UDP and TCP
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Middlew are
lay ers
Introduction
• The third section is concerned with how the objects
and data structures used in application programs
can be translated into a form suitable for sending in
messages over the network.
• Request-reply protocols are designed to support
client-server communication in the form of either
RMI or RPC. These are topics of the fourth section.
• Group multicast protocols are designed to support
group communication. They are presented in fifth
section.
• Interprocess communication in UNIX is a case study.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The Characteristics of Interprocess
Communication
• Message passing between a pair of processes can
be supported by two message communication
operations: send and receive.
• In the synchronous form of communication, both
send and receive are blocking operations.
• In the asynchronous form of communication, the
send operation is non-blocking and the receive
operation can be blocking and non-blocking.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The Characteristics of Interprocess
Communication
• Non-blocking receive is more efficient but more
complex. So current systems do not generally
provide the non-blocking form of receive.
• In the Internet protocols, messages are sent to
(Internet address, local port) pairs. Any process that
knows the number of a port can send a message to
it.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The Characteristics of Interprocess
Communication
• Using a fixed Internet address can be avoided by
one of the following approaches to provide location
transparency:
 Client program refer to services by name. This allows
services to be relocated but not to migrate (be moved
while running).
 The operating system, for example, Mach, provides
location-independent identifiers for message destinations.
• Messages can be addressed to processes in the V
system. However, ports provide several alternative
points of entry to a receiving process. Chorus
provides the ability to send messages to groups of
destination.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The Characteristics of Interprocess
Communication
• A reliable communication ensures validity and
integrity:
 For validity, a point-to-point message service can be
described as reliable if messages are guaranteed to be
delivered.
 For integrity, messages must arrive uncorrupted and
without duplication.
• Some applications require that messages be
delivered in send order.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Sockets
• A socket provides endpoints for communication
between processes as shown in Figure 4.2.
• A socket must be bound to a local port.
• A socket pair (local IP address, local port, foreign IP
address, foreign port) uniquely identifies a
communication.
• Processes using IP multicast share ports.
• Java provides a class, InetAddress, that represents
Internet Addresses. For example,
InetAddress wsu =
InetAddress.getByName(“kirk.cs.twsu.edu”);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.2
Sockets and ports
any port
socket
agreed port
socket
message
client
server
other ports
Internet address = 138.37.94.248
Internet address = 138.37.88.249
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UDP Datagram Communication
• A datagram sent by UDP is transmitted from a
sending process to a receiving process without
acknowledgement or retries.
• A server will bind its socket to a known server port. A
client binds its socket to any free local port.
• The receive method returns the Internet address
and port of the sender, in addition to the message.
• The receiving process needs to specify an array of
bytes of a particular size in which to receive a
message. The most size restriction is 8 kilobytes.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UDP Datagram Communication
• Sockets normally provide non-blocking sends and
blocking receives for datagram communication.
• The send operation returns once the message has
been sent to the underlying UDP and IP protocols.
• The method receive blocks until a datagram is
received, unless a timeout has been set on the
socket.
• If the process that invokes the receive method has
other work to do while waiting for the message, it
should arrange to use a separate thread.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UDP Datagram Communication
• In some programs, timeouts can be set on sockets.
It should be large in comparison with the time
required to transmit a message.
• It is possible to specify a specific Internet address
and port for a socket to send and receive only from
that address.
• UDP datagrams suffer from the following failures:
 Omission failures: Message may be dropped occasionally.
 Ordering: Messages can sometimes be delivered out of
sender order.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UDP Datagram Communication
•
•
•
A reliable delivery service may be constructed by
the use of acknowledge.
UDP can be used in applications which accept
occasional omission failures. For example, DNS.
UDP is preferred because they do not suffer from
the overheads associated with guaranteed
message delivery:
1. the need to store state information at source and
destination
2. the transmission of extra messages
3. latency for the sender
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet Applications that use
UDP
•
•
•
traceroute - print the route packets take to network
host. Try /usr/sbin/traceroute www.microsoft.com.
RIP (Routing Information Protocol) is a widely-used
protocol for managing router information
BOOTP (Bootstrap Protocol) is a protocol that lets
a network user be automatically configured (receive
an IP address) and have an operating system boot
or initiated without user involvement. BOOTP is the
basis for a more advanced network manager
protocol, the Dynamic Host Configuration Protocol
(DHCP).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet Applications that use
UDP
•
•
•
Dynamic Host Configuration Protocol (DHCP) is a
communications protocol that lets network
administrators manage centrally and automate the
assignment of Internet Protocol (IP) addresses in
an organization's network.)
Network Time Protocol (NTP) is a protocol that is
used to synchronize computer clock times in a
network of computers.
Trivial File Transfer Protocol (TFTP) is an Internet
software utility for transferring files where user
authentication and directory visibility are not
required.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet Applications that use
UDP
•
•
•
Simple Network Management Protocol (SNMP) is
the protocol governing network management and
the monitoring of network devices and their
functions.
The domain name system (DNS) is the way that
Internet domain names are located and translated
into Internet Protocol addresses.
The Network File System (NFS) is a client/server
application that lets a computer user view and
optionally store and update file on a remote
computer as though they were on the user's own
computer. UDP is used with the early version of
NFS.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet Applications that use
UDP
•
•
•
Remote Procedure Call (RPC) is a protocol that
one program can use to request a service from a
program located in another computer in a network
without having to understand network details.
There are several RPC models and
implementations. A popular model and
implementation is the Open Software Foundation's
Distributed Computing Environment (DCE).
Open Network Computing (ONC) RPC, sometimes
referred to as Sun RPC, was one of the first
commercial implementations of RPC.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UDP Protocol
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API for UDP Datagrams
•
The Java API provides datagram communication by
means of two classes:


•
DatagramPacket - Datagram packets are used to
implement a connectionless packet delivery service.
DatagramSocket - A datagram socket is the sending or
receiving point for a packet delivery service.
DatagramPacket:



getData - Returns the data buffer.
getPort - Returns the port number on the remote host.
getAddress - Returns the IP address.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API for UDP Datagrams
•
DatagramSocket:




•
send - Sends a datagram packet from this socket.
receive - Receives a datagram packet from this socket.
setSoTimeout - Enable/disable the specified timeout, in
milliseconds.
connect - Connects the socket to a remote address for
this socket.
Figure 4.3 shows a client program. Figure 4.4
shows the program for the corresponding server.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.3
UDP client sends a message to the server and gets a reply
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
DatagramSocket aSocket = null;
try {
aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
}
Figure 4.4
UDP server repeatedly receives a request and sends it back to the client
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
DatagramSocket aSocket = null;
try{
aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Stream Communication
•
•
The API to the TCP protocol, which originates from
BSD 4.x UNIX, provides the abstraction of a stream
of bytes.
The following characteristics of the network are
hidden by the stream abstraction:


Message sizes – The application can choose how much
data it writes to a stream or reads from it.
Lost messages – The TCP protocol uses an
acknowledge scheme. If the acknowledgement is not
received within a timeout, it will be resent.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Stream Communication



Flow control – The TCP protocol attempts to match the
speeds of the sending and receiving process.
Message duplication and ordering – Messages identifiers
are associated with each IP packet. It enables the
recipient to detect and reject duplicates, or to reorder
messages.
Message destinations – Once the connection between a
pair of processes is established, the processes simply
read from and write to the stream.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Abstractions
• The data is the abstraction of a stream of bytes.
• A connection is established before messages are
sent.
• It assumes one process is the client and one is the
server in establishing a connection.
• The client create a socket bound to any local port
and then makes a connect request for connecting
the server at its server port.
• The server creates a listening socket bound to a
server port and wait for (accept) the incoming
requests.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Abstractions
• Messages are sent using handles (sockets) rather
than source-destination addresses.
• An application closes a socket once it is done with
the transmission.
• The issues related to stream communication are:
 Matching of data items: Two communicating processes
need to agree on the contents of the transmitted data.
 Blocking: When a process tries to read data from an input
channel (stream), it will get the data or block until the data
is available.
 Thread: When a sever accepts a connection, it generally
creates a new thread for the new client.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Failure Model
• TCP uses three mechanism to create a reliable
communication:
 Checksums and sequence numbers for integrity: TCP
streams use checksums to detect and reject corrupt
packets and sequence numbers to detect and reject
duplicate packets.
 Timeouts and retransmission for validity: TCP streams use
timeouts and retransmissions to deal with lost packets.
• The problem is if the network becomes congested,
no acknowledge is received and then the connection
is broken. Thus TCP does not provide reliable
communication.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Failure Model
• When a connection is broken, it will has the following
effects:
 The processes using the connection cannot distinguish
between network failure and failure of the process.
 The communication process cannot tell whether their
recent messages have been received or not.
• The programmers need to deal with this situation in
the program.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet applications that use
TCP
• HTTP (HyperText Transfer Protocol) is used for
communication between web browsers and web
servers.
• FTP (file transfer) – File Transfer Protocl
• Telnet provides access by means of a terminal
session to a remote computer.
• SMTP (Simple Mail Transfer Protocol) is used send
mail between computers.
• POP (Post Office Protocol) is a standard protocol for
receiving e-mail.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet applications that use
TCP
• BGP (Border Gateway Protocol) is a protocol for
exchanging routing information between gateway
hosts (each with its own router) in a network of
autonomous systems.
• The domain name system (DNS) is the way that
Internet domain names are located and translated
into Internet Protocol addresses.
• NNTP (Network News Transfer Protocol) is the
predominant protocol used by computer clients and
servers for managing the notes posted on Usenet
newsgroups.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Internet Applications that use
TCP
• The Network File System (NFS) is a client/server
application that lets a computer user view and
optionally store and update file on a remote
computer as though they were on the user's own
computer.
• Open Network Computing (ONC) RPC, sometimes
referred to as Sun RPC, was one of the first
commercial implementations of RPC.
• The Open Software Foundation's Distributed
Computing Environment (DCE) is a popular model
and implementation of RPC.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
TCP Protocol
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API for TCP Streams
•
The Java API provides TCP streams by means of
two classes:


•
ServerSocket - This class implements server sockets. A
server socket waits for requests to come in over the
network.
Socket - This class implements client sockets.
ServerSocket:

accept - Listens for a connection to be made to this
socket and accepts it. The result of executing accept is
an instance of Socket.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API for TCP Streams
•
Socket:



•
Socket (InetAddress address, int port) - Creates a
stream socket and connects it to the specified port
number at the specified IP address. It will throws
UnknownHostException or an IOException.
getInputStream - Returns an input stream for this
socket.
getOutputStream - Returns an output stream for this
socket.
Figure 4.5 shows a client program. Figure 4.6
shows the corresponding server program.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.5
TCP client makes connection to server, sends request and receives reply
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
// arguments supply message and hostname of destination
Socket s = null;
try{
int serverPort = 7896;
s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream( s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]);
// UTF is a string encoding see Sn 4.3
String data = in.readUTF();
System.out.println("Received: "+ data) ;
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){System.out.println("EOF:"+e.getMessage());
}catch (IOException e){System.out.println("IO:"+e.getMessage());}
}finally {if(s!=null) try {s.close();}catch (IOException e){System.out.println("close:"+e.getMessage());}}
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.6 TCP server makes a connection for each client and then echoes
the client’s request
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket);
}
} catch(IOException e) {System.out.println("Listen :"+e.getMessage());}
}
}
// this figure continues on the next slide
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.6 continued
class Connection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e) {System.out.println("Connection:"+e.getMessage());}
}
public void run(){
try {
// an echo server
String data = in.readUTF();
out.writeUTF(data);
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
} finally{ try {clientSocket.close();}catch (IOException e){/*close failed*/}}
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Protocol Usages by Common Internet
Applications
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
External Data Representation and
Marshalling
•
Not all computers store primitive values such as
integers in the same order. There are two variants:


•
Big-endian – the most significant byte comes first
Little-endian – the most significant byte comes last
The set of codes used to represent characters:


ASCII – one byte per character
Unicode – two bytes per character to present texts in
different languages
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
External Data Representation and
Marshalling
•
One of the following methods can be used to
enable any two computers to exchange data
values:


•
The values are converted to a agreed external format.
The values are transmitted in the sender’s format,
together with an indication of the format used, and the
recipient converts the values if necessary.
An agreed standard for the representation of data
structures and primitive values is called an
external data representation.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
External Data Representation and
Marshalling
•
Marshalling:


•
It is the process of taking a collection of data items and
assembling them into a form suitable for transmission in
a message.
It involves data translation to an external data
representation.
Unmarshalling:


It is the process of disassembling them on arrival to
produce an equivalent data items at the destination.
It involves generation of primitive values from their
external data representation.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
External Data Representation and
Marshalling
•
Two alternative approaches to external data
representation and marshalling are discussed:


•
CORBA’s (Common Object Request Broker Architecture
– a distributed computing environment) common data
representation is used to pass arguments and results of
remote method invocation.
Java’s object serialization is used to flatten objects that
are transmitted in a message or stored on a disk. It is for
use only by Java.
Two approaches can be used to marshal the
primitive data types:


Binary form
ASCII text – used by HTTP
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Data Representation (CDR)
•
•
•
CORBA CDR is the external data representation
defined with CORBA 2.0 (OMG).
CDR can represent all the data types that can be
used as arguments and return values in remote
invocations in CORBA.
CORBA CDR data types:


Primitive types: char, boolean, octet (1 byte), short,
unsigned short, wchar (2 byte), long, unsigned long, float
(4 byte), long long, unsigned long long,double,long
double (8 byte), any
Constructed types: sequence, string, array, struct,
enumerated , union as shown in Figure 4.7
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.7
CORBA CDR for constructed types
Type
sequence
string
array
struct
enumerated
union
Representation
length (unsigned long) followed by elements in order
length (unsigned long) followed by characters in order (can also
can have wide characters)
array elements in order (no length specified because it is fixed)
in the order of declaration of the components
unsigned long (the values are specified by the order declared)
type tag followed by the selected member
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Data Representation (CDR)
•
Figure 4.8 shows a message in CORBA CDR:



•
The representation of each string consists of an
unsigned long representing its length followed by the
characters in the string.
Variable length data is padded with zeros.
Each unsigned long occupying four bytes starts at an
index that is a multiple of four.
Sun XDR (eXternal Data Representation) is
another example of data exchange standard. It is
developed by Sun for use in messages exchanged
between clients and servers in Sun NFS.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.8
CORBA CDR message
index in
sequence of bytes
0–3
4–7
8–11
12–15
16–19
20-23
24–27
4 bytes
5
"Smit"
"h___"
6
"Lond"
"on__"
1934
notes
on representation
length of string
‘Smith’
length of string
‘London’
unsigned long
The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Common Data Representation (CDR)
•
Marshalling in CORBA is generated automatically
from the specification of the data to be transmitted.
This standard data item can be specified in CORBA
IDL (Interface Definition Language) as follows:
struct Person {
string name;
string place;
long year;
};
•
The CORBA interface compiler generates
appropriate marshalling and umarshalling
operations for the arguments and results of remote
method.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Object Serialization
• In Java RMI, both objects and primitive data values may be
passed as arguments and results of method invocations. An
object is an instance of a Java class.
• The Java class equivalent to the Person struct defined in
CORBA IDL might be:
public class Person implements Serializable {
private String name;
private String place;
private int year;
public Person (String n, String pl, int yr) {
name = n;
place = pl;
year = yr;
} // followed by methods for accessing the instance variables.
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Object Serialization
• In Java, the term serialization refers to the activity
of flattening an object or a connected set of objects
into a serial form for storing or transmission.
• Deserialization consists of restoring the state of an
object or a set of objects from their serialized form.
• The information about a class consists of the name
of the class and a version number, which is changed
when major changes are made to the class.
• Java objects can contain references to other objects.
These referred objects are serialized with the
referring object.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Object Serialization
• References are serialized as handles. The
serialization must ensure 1-1 correspondence
between object references and handles.
• To serialize an object is done as follows:
 Its class name and version are written out, followed by its
instance variables.
 If the instance variables belong to new classes, their class
information are also written out.
 This recursive procedure continues until all necessary
classes have been written out.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Object Serialization
• The contents of primitive types are written in a
portable binary format using methods of the
ObjectOutputStream class.
• Strings and characters are written by its writeUTF
method using Universal Transfer Format (UTF):
 It enables ASCII characters to be represented unchanged
(in one byte).
 Unicode characters are represented by multiple bytes.
 Strings are preceded by the number of bytes they occupy
in the stream.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Object Serialization
• The serialized form of Person p = new
Person(“Smith”, “London”, 1934) is illustrated in
Figure 4.9.
• To make use of Java serialization, for example to
serialize the Person object, create an instance of the
class ObjectOutputStream and invoke its
writeObject method, passing the Person object as
argument.
• To deserialize an object from a stream of data, open
an ObjectInputStream on the stream and use its
readObject method to rebuild the original object.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.9
Indication of Java serialized form
Explanation
Serialized values
Person
8-byte version number
h0
class name, version number
3
int year
java.lang.String java.lang.String number, type and name of
name:
place:
instance variables
1934
5 Smith
6 London
h1
values of instance variables
The true serialized form contains additional type markers; h0 and h1 are handles
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java Reflection
• The Java language supports reflection – the ability
to enquire about the properties of a class, such as
the names and types of its instance variables and
methods.
• Reflection makes it no need to generate special
marshalling functions for each type of object.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Remote Object References
• A remote object reference is an identifier for a
remote object that is valid throughout a distributed
system.
• Remote object references must be unique and are
not reused.
• A remote object can be constructed by
concatenating the Internet address of its computer
and port number of the process with the creation
time and a local object number as shown in Figure
4.10.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Representation of a remote object reference
32 bits
32 bits
Internet address
port number
32 bits
time
32 bits
object number
Figure 4.10
interface of
remote object
• a remote object reference must be unique in the distributed system and
over time. It should not be reused after the object is deleted. Why not?
• the first two fields locate the object unless migration or re-activation in
a new process can happen
• the fourth field identifies the object within the process
• its interface tells the receiver what methods it has (e.g. class Method)
• a remote object reference is created by a remote reference module
when a reference is passed as argument or result to another process
 it will be stored in the corresponding proxy
 it will be passed in request messages to identify the remote object
whose method is to be invoked
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Client-Server Communication
•
•
The request-reply communication is designed to
support the roles and message exchange in clientserver interactions.
A request-reply protocol built over datagrams
avoids unnecessary overheads associates with the
TCP stream protocol:



Acknowledgements are redundant, because requests are
followed by replies;
Establishing a connection involves extra pairs of
message exchange;
Flow control is redundant for the majority of invocations,
which pass only small arguments and results.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
•
Figure 4.11 shows a request-reply communication
based on three communication primitives :
doOperation, getRequest, and sendReply.
This protocol is used in most RMI and RPC system:




The doOperation method is used by clients to invoke
remote operations.
After sending the request message, doOperation invokes
receive to wait for a reply message.
GetRequest is used by a server process to acquire
service requests .
When the server has invoked the method in the specified
object, it then uses sendReply to send the reply to the
client.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.11
Request-reply communication
Client
doOperation
Server
Request
message
(wait)
Reply
message
getRequest
select object
execute
method
sendReply
(continuation)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.12
Operations of the request-reply protocol
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)
sends a request message to the remote object and returns the reply.
The arguments specify the remote object, the method to be invoked and the arguments of
that method.
public byte[] getRequest ();
acquires a client request via the server port.
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);
sends the reply message reply to the client at its Internet address and port.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
This protocol is used in most RMI and RPC system:
(continued)

•
When the reply is received by the client, the original
doOperation is unblocked.
The information to be transmitted in a request
message or a reply message is shown in Figure
4.13:





messageType – 0 = Request, 1 = Reply
requestID – message identifier
objectReference – remote object reference
methodID – the method to be invoked
arguments – arguments to be transmitted.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.13
Request-reply message structure
messageType
int (0=Request, 1= Reply)
requestId
int
objectReference
RemoteObjectRef
methodId
int or Method
arguments
array of bytes
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
A message identifier consists of two parts:


•
A requestID, which is taken from an increasing sequence
of integers by the sending process (unique to the
sender);
An identifier for the sender process, for example its port
and IP address (unique in the distributed system).
If the three primitives are implemented over UDP
datagrams, they suffer from following failures:



They suffer from omission failures;
Messages are not guaranteed to be delivered in sender
order;
They suffer from the failure of processes.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
Methods to prevent failures:
 Timeouts - doOperation sends the request repeatedly
until it gets a reply or it is sure that the delay is due to
lack of the server response rather than lost messages.
 Discarding duplicate request messages - The protocol is
designed to recognize successive messages and filter
out duplicates.
 Lost reply messages – The server will re-execute the
same operation if it receives a duplicate request. Then an
idempotent operation that can be performed repeatedly
with the same effect will be required..
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
Methods to prevent failures (continued):

•
Three RPC protocols are implemented in the
presence of communication failures:



•
History – For servers that require retransmission of
replies without re-execution of operations, a history may
be used. A problem associated with the use of a history is
its memory cost.
The request (R) protocol;
The request-reply (RR) protocol;
The request-reply-acknowledge reply (RRA) protocol.
The messages passed in these protocols are
summarized in Figure 4.14.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.14
RPC exchange protocols
Name
Client
Messages sent by
Server
Client
R
Request
RR
Request
Reply
RRA
Request
Reply
Acknowledge reply
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
The R protocol may be used when:


•
•
There is no returned value.
The client needs no confirmation from the server.
The RR protocol is useful for most client-server
exchange because it is based on the request-reply
protocol.
The PRA protocol is used to enable the server to
discard entries from its history.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Client-Server Communication
•
•
The datagram is limited to 8 kilobytes and may not
be adequate for use in RMI. The TCP can be used.
The TCP protocol has the following advantages:



•
It makes it possible to transmit objects of any size.
There is no need to deal with retransmission.
The flow control mechanism allows large arguments and
results.
Thus, the TCP protocol is chose for implementing
request-reply protocols.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
Web servers manage resources implemented in
different ways:


•
as data – text, image, applet
as a program – cgi program, servlets
The HTTP protocol allows:



Method invocation
Content negotiation – Client can specify the data
representation.
Authentication – Credentials and challenges are used to
support password-style authentication.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
HTTP is implemented over TCP and has the
following interactions:




•
The client requests and server accepts a connection at
the default server port or at a port specified in the URL. A
persistent connection is built.
The client sends a request to the server;
The server sends a reply to the client;
The connection can be closed by client or server.
The HTTP protocol use ASCII text for the message
exchange.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
•
Resources implemented as data are supplied as
MIME-like structures.
Multipurpose Internet Mail Extension (MIME) is a
standard for send multipart data containing, text,
images, and sound in e-mail messages.


Data is prefixed with its Mime type so that the recipient
will know how to handle it.
A Mime type specifies a type and a subtype, for example,
text/plain, text/html, image/gif, image/jpeg.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
The HTTP methods include:


GET – requests the resource whose URL is given as
argument.
o GET can be used to send the contents of a form to a
cgi program as an argument.
o The GET operation can be made conditional on the
date a resource was last modified.
o GET can also be configured to obtain parts of the data.
HEAD – the request is identical to GET, but it does not
return any data.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
The HTTP methods include: (continued)


POST – specifies the URL of resource that can deal with
the data supplied with the request. This method is
designed to deal with:
o Providing a block of data to a data-handling process
such as servlet or a cgi program;
o Posting a message to a bulletin board, mailing list or
newsgroup;
o Extending a database with an append operation.
PUT – requests that the data supplied in the request is
stored with the given URL as identifier.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
The HTTP methods include: (continued)



•
DELETE – the server deletes the resource identified by
the given URL.
OPTIONS – the server supplies the client with a list of
methods it allows to be applied to the given URL and its
special requirements.
TRACE – the server sends back the request message.
Used for diagnostic purposes.
The requests described above may be intercepted
by a proxy server.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
Figure 4.15 shows the contents of an HTTP
request message:





The method is GET.
URL specifies a data resource.
The protocol version is HTTP 1.1.
The header fields contain request modifiers and client
information.
An authorization field can be used to provide the client’s
credentials.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.15
HTTP request message
method
URL or pathname
GET
//www.dcs.qmw.ac.uk/index.html
HTTP version
headers message body
HTTP/ 1.1
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
HTTP: Request-Reply Protocol
•
Figure 4.16 shows the contents of an HTTP reply
message:





The protocol version is HTTP 1.1.
The status code reporting the transmission status is a
three-digital integer for interpretation by a program.
The reason shows the transmission status understood by
a person.
The header fields are used to pass additional information
about the server or concerning access to the resource.
The message body contain the requested data in Mime
format.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.16
HTTP reply message
HTTP version
HTTP/1.1
status code reason headers message body
200
OK
resource data
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Group Communication
•
•
•
A multicast operation is an operation to send a
single message from one process to a group of
processes.
This operation suits the service that is implemented
as a number of different processes in different
computers.
Multicast messages provide a useful infrastructure
for constructing distributed systems with the
following characteristics:
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Group Communication
•
Multicast characteristics: (continued)




Fault tolerance based on replicated services – Client
requests are multicast to a group of servers. Even when
some members fail, clients can still be served.
Finding the discovery servers in spontaneous
networking – Multicast messages can be used by
servers and clients to locate discovery services.
Better performance through replicated data – data are
replicated to increase the performance of a service.
Propagation of event notifications – Multicast to a
group may be used to notify processes when something
happens. For example, a news system and the Jini
system.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast
•
•
•
•
•
IP multicast built on top of the Internet Protocol
allows the sender to transmit a single IP packet to a
set of computers.
A multicast group is specified by a class D
Internet address – an address whose first 4 bits are
1110 in IPv4 (Figure 3.15).
The membership of multicast groups is dynamic.
At the application programming level, IP multicast
is available via UDP.
At the IP level, a computer belongs to a multicast
group when sockets belong to that group.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast
•
The following details are specific to IPv4:


Multicast routers – IP packets can be multicast on a
local network and on the Internet.
o Local multicasts use the multicast capability of the
local network such as an Ethernet.
o Multicast in the Internet make use of multicast
routers. The distance of propagation is specified in
the Time To Live or TTL.
Multicast address allocation – Multicast address can
be permanent or temporary.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast

•
Multicast address allocation (continued):
o 224.0.0.1 to 244.0.0.255 are assigned to be
permanent multicast addresses.
o A temporary multicast group requires a free multicast
address to avoid accidental participation in an existing
group before use and cease after use.
o For local multicast, TTL can be set to a small value.
o For multicast on the Internet, the session directory
(sd) program can be used. It allows people to browse
advertised sessions and advertise their own sessions.
Datagrams multicast over IP multicast suffer from
omission failures. This is a unreliable multicast.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API to IP Multicast
•
The Java API provides a datagram interface to IP
multicast through the class MulticastSocket, which
is a (UDP) DatagramSocket, with additional
capabilities for joining groups of other multicast
hosts on the internet.




MulticastSocket - Create a multicast socket.
joinGroup - Joins a multicast group.
leaveGroup - Leave a multicast group.
setTimeToLive - Set the default time-to-live for multicast
packets sent out on this MulticastSocket in order to
control the scope of the multicasts.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Java API to IP Multicast
•
•
•
A multicast peer program shown in Figure 4.17
specify the message and the multicast address in
the arguments to the main method.
An application implemented over IP multicast may
use more that one port.
For example, the MultiTalk [mbone] application,
which allows groups of users to hold text-based
conversations, has one port for sending and
receiving data and another for exchanging control
data.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.17
Multicast peer joins a group and sends and receives datagrams
import java.net.*;
import java.io.*;
public class MulticastPeer{
public static void main(String args[]){
// args give message contents & destination multicast group (e.g. "228.5.6.7")
MulticastSocket s =null;
try {
InetAddress group = InetAddress.getByName(args[1]);
s = new MulticastSocket(6789);
s.joinGroup(group);
byte [] m = args[0].getBytes();
DatagramPacket messageOut =
new DatagramPacket(m, m.length, group, 6789);
s.send(messageOut);
// this figure continued on the next slide
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.17
continued
// get messages from others in group
byte[] buffer = new byte[1000];
for(int i=0; i< 3; i++) {
DatagramPacket messageIn =
new DatagramPacket(buffer, buffer.length);
s.receive(messageIn);
System.out.println("Received:" + new String(messageIn.getData()));
}
s.leaveGroup(group);
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(s != null) s.close();}
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast
•
The following situations could occur:



Omission failure – A recipient could drop a message
because its buffer is full. A datagram sent from on
multicast router to another might be lost.
Process failure – If a multicast router fails, the group
members beyond that router won’t receive the message.
Ordering issue – The packets could arrive in a different
order.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast
•
Examples of the effects of reliability and ordering:




Fault tolerance based on replicated services – In
replicated servers, multicast requires that either all or
none should receive the request to perform an operation
to remain consistent.
Finding the discovery servers in spontaneous
networking – An occasional lost request is not an issue
when locating a discovery server.
Better performance through replicated data – The
effect of lost messages and inconsistent ordering
depends on the method of replication.
Propagation of event notifications – The particular
application determines the qualities required of multicast.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
IP Multicast
•
These examples suggest that some applications
require a more reliable multicast.


Reliable multicast – Any message transmitted is either
received by all members of a group or by none of them.
Totally ordered multicast – All of the messages
transmitted to a group reach all of the members in the
same order.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Interprocess Communication in UNIX
•
•
•
•
The IPC primitives in BSD 4.x UNIX are
implemented as a layer over the Internet TCP and
UDP protocols.
Message destinations are specified as socket
addresses (Internet address + local port number),
on which the interprocess communication
operations are based.
Before a pair of processes can communicate, the
recipient must bind its socket descriptor to a socket
address.
The socket lasts until it is closed or until every
process with the descriptor exits.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Datagram Communication
•
•
The datagram communication is illustrated as in
Figure 4.18.
socket - create a socket and get a descriptor (file
handle) for it.




int socket(int domain, int type, int protocol)
The domain parameter specifies a communication
domain.
The socket has the indicated type, which specifies the
communication semantics.
The protocol specifies a particular protocol to be used
with the socket. Zero causes the system to select the
suitable protocol.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.18
Sockets used for datagrams
Sending a message
Receiving a message
s = socket(AF_INET, SOCK_DGRAM, 0)
s = socket(AF_INET, SOCK_DGRAM, 0)
bind(s, ClientAddress)
bind(s, ServerAddress)
sendto(s, "message", ServerAddress)
amount = recvfrom(s, buffer, from)
ServerAddress and ClientAddress are socket addresses
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Datagram Communication
•
bind – specify the local endpoint address for a
socket.




•
int bind(int sockfd, struct sockaddr *my_addr,
socklen_t addrlen);
sockfd – a socket descriptor created by the socket call.
my_addr – The address structure specifies an IP
address and protocol port number.
addrlen – The size of the address structure in bytes.
send, sendto, sendmsg - send a message from a
socket.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Datagram Communication
•
•
•
recv, recvfrom, recvmsg - receive a message
from a socket
close - close a file descriptor
UDP is not able to transfer a message more than
8KB.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Stream Communication
•
•
•
•
In order to use the stream protocol, two processes
must first establish a connection between their pair
of sockets.
For communication between clients and servers,
clients request connections and a listening server
accepts them.
A connected pair of stream sockets can be used
until the connection is closed.
The stream communication is illustrated in Figure
4.19.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 4.19
Sockets used for streams
Requesting a connection
Listening and accepting a connection
s = socket(AF_INET, SOCK_STREAM,0)
connect(s, ServerAddress)
s = socket(AF_INET, SOCK_STREAM,0)
bind(s, ServerAddress);
listen(s,5);
sNew = accept(s, ClientAddress);
write(s, "message", length)
n = read(sNew, buffer, amount)
ServerAddress and ClientAddress are socket addresses
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Stream Communication
•
•
•
Normally, a server would first listen and accept a
connection and then fork a new process to
communicate with the client.
The server or listening process first uses the
socket operation to create a stream socket and the
bind operation to bind its socket to the server’s
socket address.
It uses the listen operation to listen for connections
on a socket.

int listen (int sockfd, int backlog) : The backlog
parameter defines the maximum length the queue of
pending connections may grow to.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
UNIX Stream Communication
•
•
The server uses the accept system call to accept
connection requested by a client.
After a connection has been established, both
processes may then use the write (send) and read
(recv) operations to send and receive messages.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Example - Programming Client
Initialization:
• gethostbyname - look up server
• socket - create socket
• connect - connect to server port
Transmission:
• send – send message to server
• recv - receive message from server
Termination:
• close - close socket
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Example - Programming Server
Initialization:
• socket - create socket
• bind – bind socket to the local address
• listen - associate socket with incoming requests
Loop:
• accept - accept incoming connection
• recv - receive message from client
• send - send message to client
Termination:
• close - close connection socket
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000