Chapter 4 a interprocess communication

Distributed Systems - Interprocess Communication
 4. Topics
 4.1 Intro
4.2 API for Internet Protocols
 4.3 External data representation
 4.4 Client-Server Communication
 4.5 Group communication
 4.6 Unix – An example
1

Interprocess Communication – 4.1 Introduction
 Focus:
– Characteristics of protocols for communication between processes to
model distributed computing architecture
 Effective means for communicating objects among processes at language
level
– Java API
 Provides both datagram and stream communication primitives/interfaces –
building blocks for communication protocols
– Representation of objects
 providing a common interface for object references
– Protocol construction
 Two communication patterns for distributed programming: C-S using
RMI/RPC and Group communication using ‘broadcasting’
– Unix RPC
2

Interprocess Communication – 4.1 Introduction
 In Chapter 3, we covered Internet transport (TCP/UDP) and network (IP)
protocols – without emphasizing how they are used at programming level
 In Chapter 5, we cover RMI facilities for accessing remote objects’ methods AND
the use of RPC for accessing the procedures in a remote server
 Chapter 4 is on how TCP and UDP are used in a program to effect
communication via socket (e.g., Java sockets) – the Middle Layers – for object
request/reply invocation and parameter marshalling/representation, including
specialized protocols that avoid redundant messaging (e.g., using piggybacked
ACKs)
3

Interprocess Communication – 4.2 API for Internet
 Characteristics of IPC – message passing using send/receive facilities for sync
and addressing in distributed programs
 Use of sockets as API for UDP and TCP implementation – much more
specification can be found at java.net
 Synchronous
– Queues at remote sites are established for message placement by clients (sender). The
local process (at remote site) dequeues the message on arrival
– If synchronous, both the sender and receiver must ‘rendezvous’ on each message, i.e.,
both send and receive invocations are blocking-until
 Asynchronous communication
– Send from client is non-blocking and proceeds in parallel with local operations
– Receive could be non-blocking (requiring a background buffer for when message finally
arrives, with notification – using interrupts or polling) AND if blocking, perhaps, remote
process needs the message, then the process must wait on it
– Having both sync/async is advantageous, e.g., one thread of a process can do blocked-receive
while other thread of same process perform non-block receive or are active –
simplifies synchronization. In general non-blocking-receive is simple but complex to
implement due to messages arriving out-of-order in the background buffer
4

 Message destinations
– Typically: send(IP, port#, buffer) – a many-to-one (many senders to a single
receiving port), except multicast, which is many-to-group.
– Possibility: receiving process can have many ports for different message types
– Server processes usually publish their service-ports for clients
– Clients can use static IP to access service-ports on servers (limiting,
sometimes), but could use location-independent IP by
 using name server or binder to bind names to servers at run-time – for relocation
 Mapping location-independent identifiers onto lower-level address to deliver/send
messages – supporting service migration and relocation
– IPC can also use ‘processes’ in lieu of ‘ports’ for services but ports are flexible
and also (a better) support for multicast or delivery to groups of destinations
5

6
 Reliability
– Validity: transmission is reliable if packets are delivered despite some
drops/losses, and unreliable even if there is a single drop/loss
– Integrity: message must be delivered uncorrupted and no duplicates
 Ordering
– Message packets, even if sent out-of-order, must be reordered and delivered
otherwise it is a failure of protocol

7
 Sockets
– Provide an abstraction of endpoints for both TCP and UDP communication
– Sockets are bound to ports on given computers (via the computer’s IP
address)
– Each computer has 216 possible ports available to local processes for receiving
messages
– Each process can designate multiple ports for different message types (but
such designated ports can’t be shared with other processes on the same
computer – unless using IP multicast)
– Many processes in the same computer can deliver to the same port (many-to-one),
however
– Sockets are typed/associated with either TCP or UDP

8

 Java API for IPs
– For either TCP or UDP, Java provides an InetAddress class, which contains a
method: getByName(DNS) for obtaining IP addresses, irrespectively of the
number of address bits (32 bits for IPv4 or 128 bits for IPv6) by simply passing
the DNS hostname. For example, a user Java code invokes:
InetAddress aComputer = InetAddress.getByName(“nsfcopire.spsu.edu”);
– The class encapsulates the details of representing the IP address
9

 UDP Datagram communication
10
– Steps:
 Client finds an available port for UPD connection
 Client binds the port to local IP (obtained from InetAddress.getByName(DNS) )
 Server finds a designated port, publicizes it to clients, and binds it to local IP
 Sever process issues a receive methods and gets the IP and port # of sender
(client) along with the message
– Issues
 Message size – set to 8KByte for most, general protocol support 216 bytes,
possible truncation if receiver buffer is smaller than message size
 Blocking – send is non-blocking and op returns if message gets pass the UDP and
IP layers; receive is blocking (with discard if no socket is bound or no thread is
waiting at destination port)
 Timeouts – reasonably large time interval set on receiver sockets to avoid
indefinite blocking
 Receive from any – no specification of sources (senders), typically many-to-one,
but one-to-one is possible by a designated send-receive socket (know by both C/S)

 UDP Failure Models:
– Due to Omission of send or receive (either checksum error or no buffer space
at source or destination)
– Due to out-of-order delivery
– UDP lacks built in checks, but failure can be modeled by implementing an
ACK mechanism
11

 Use of UDP – Client/Sender code
12

Use of UDP – Server/Receiver code
13

 TCP Stream Communication
– Grounded in the ‘piping’ architecture of Unix systems using BSD Unix
sockets for streaming bytes
– Characteristics:
 Message sizes – user application has option to set IP packet size, small or
large
 Lost messages – Sliding window protocol with ACKs and retransmission is
used
 Flow control – Blocking or throttling is used
 Message duplication and ordering – Seq #s with discard of dups &
reordering
 Message destinations – a connection is established first, using connection-accept
methods for rendezvous, and no IP addresses in packets. [Each
connection socket is bidirectional – using two streams: output/write and
input/read]. A client closes a socket to sign off, and last stream of bytes are
sent to receiver with ‘broken-pipe’ or empty-queue indicator
14

 TCP Stream Communication
– Other Issues
 Matching of data items – both client/sender and server/receiver must agree on
data types and order in the stream
 Blocking – data is streamed and kept in server queue: empty server queue
causes a block AND full server queue causes a blocking of sender
 Threads – used by servers (in the background) to service clients, allowing
asynchronous blocking. [Systems without threads, e.g., Unix, use select]
– Failure Model
 Integrity: uses checksums for detection/rejection of corrupt data and seq #s for
rejecting duplicates
 Validity: uses timeout with retransmission techniques (takes care of packet
losses or drops)
 Pathological: excessive drops/timeouts signal broken sockets and TCP throws
in the towel (no one knows if pending packets were exchanged) – unreliable
– Uses – TCP sockets used for such services as: HTTP, FTP, Telnet, SMTP
15

Use of TCP – Client/Sender code
16

Use of TCP – Server/Receiver code
17

Use of TCP – Server/Receiver code (cont’d)
18

Interprocess Communication – 4.3 External data
representation
19
 Issues
– At language-level data (for comm) are stored in data structures
– At TCP/UDP-level data are communicated as ‘messages’ or streams
of bytes – hence, conversion/flattening is needed
– Problem? Different machines have different primitive data reps, e.g.,
big-endian and little-endian order of integers, float-type, char codes
– Marshalling (before trans) and unmarshalling (restored to original on
arrival)
– Either both machines agree on a format type (included in parameter
list) or an intermediate external standard (external data rep) is used,
e.g., CORBA Common Data Rep (CDR)/IDL for many languages;
Java object serialization for Java code only, Sun XDR standard for
Sun NFSs

representation
 This masks the differences due to different computer
hardware.
 CORBA CDR
– only defined in CORBA 2.0 in 1998, before that, each implementation of
CORBA had an external data representation, but they could not generally work
with one another. That is:
 the heterogeneity of hardware was masked
 but not the heterogeneity due to different programmers (until CORBA 2)
– CORBA CDR represents simple and constructed data types (sequence, string,
array, struct, enum and union)
 note that it does not deal with objects (only Java does: objects and tree of objects)
– it requires an IDL specification of data to be serialised
 Java object serialisation
– represents both objects and primitive data values
– it uses reflection to serialise and deserialise objects– it does not need an IDL
specification of the objects. (Reflection: inquiring about class properties, e.g.,
names, types of methods and variables, of objects]
20

representation
 Example of Java serialized message
public class Person implements Serializable {
private String name;
private String place;
private int year;
public Person(String aName, String aPlace, int aYear) {
name = aName;
place = aPlace;
year = aYear;
} // followed by methods for accessing the instance variables
}
– Consider the following object:
Person p = new Person(“Smith”, “London”, 1934);
21

CORBA IDL example
struct Person {
CORBA has a struct
22
string name;
string place;
long year;
} ;
interface PersonList {
remote interface
readonly attribute string listname;
void addPerson(in Person p) ;
void getPerson(in string name, out Person
p);
long number();
};
 Remote interface:
remote interface defines
methods for RMI
parameters are in, out or inout
– specifies the methods of an object available for remote invocation
– an interface definition language (or IDL) is used to specify remote interfaces.
E.g. the above in CORBA IDL.
– Java RMI would have a class for Person, but CORBA has a struct

representation
23
remote
invocation invocation
remote
invocation
local
local
invocation
local
invocation
A B
C
D
E
F
 each process contains objects, some of which can receive remote
invocations, others only local invocations
 those that can receive remote invocations are called remote objects
 objects need to know the remote object reference of an object in another
process in order to invoke its methods. How do they get it?
 the remote interface specifies which methods can be invoked remotely
 Remote object references are passed as arguments and compared to
ensure uniqueness over time and space in Distributed Computing system

Representation of a remote object reference
Figure 4.10
Internet address port number time object number interface of
24
remote object
32 bits 32 bits 32 bits 32 bits
 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
•

The architecture of remote method invocation
object A skeleton object B
carries out Request-reply
protocol
translates between local and remote object
references and creates remote object
references. Uses remote object table
Skeleton - implements methods in remote interface.
Unmarshals requests and marshals results. Invokes
method in remote object. •
25
Request
proxy for B
Reply
& dispatcher
for B’s class
Remote Communication Communication Remote reference
reference module module module module
remote
client server
RMI software - between
application level objects
and communication and
remote reference modules
Proxy - makes RMI transparent to client. Class implements
remote interface. Marshals requests and unmarshals
results. Forwards request.
Dispatcher - gets request from communication module and
invokes method in skeleton (using methodID in message).

Interprocess Communication – 4.4 Client-Server
Communication
26
 Modes:
– Request-reply: client process blocks until and ACK is received from
server (Synchronous)
– Use send/receive operations in Java API for UDP (or TCP streams –
typically with much overhead for the ‘guarantees’)
– Protocol over UDP, e.g., piggybacked ACKs,

Communication
Request-Reply Protocol
MessageIDs: requestID + IP.portnumber // IP.portnumber from packet if UDP
27

Communication
 Failure Model of Request-Reply Protocol
– For doOperation, getRequest, sendReply over UDP, the possible problems include:
 Omission failure (link failures, drops/losses, missed/corrupt addresses)
 Out-of-order delivery
 Node/process down
28
– Solved by
 Timeouts with retrans or retries until reply is received/confirmed
 Discards of repeated requests (by server process)
 On lost reply messages, servers repeats idempotent operations
 Maintain history (reqid, message, client-id) or buffer replies and retrans – memory intensive

Communication
 Failure handling –
 RPC exchange protocols (for handling failures)
• Request (R) Protocol – for remote procedures with return results or need for ACK
• Request-Reply Protocol – converse of R protocol, with reply message as piggybacked
ACK
• Request-Reply-ACK-reply (RRA) – request and ACK reply message (with id of specific
range of requests being ACKed – Go-back/Selective Repeat protocols) – avoids keeping
histories
29

Interprocess Communication – 4.5 Group Communication
 Limitations of peer-to-peer (point-to-point)
 Support for (concurrent) multiple services from a single
clients requires a different communication paradigm
 Multicast – message from a single client to group of server
processes (useful for distributed processing)
 Characteristics
– Fault tolerance based on replicated services (redundancy of same service)
– Finding discovery servers (with registry of new service interfaces)
– Better performance via data replication (updates are multicast for currency)
– Propagation of event notification (inform affected servers of new events, e.g.,
new routing tables, new servers or clients)
30

 IP Multicast
– Built on top of the IP layer (using IP addresses) [ports for TCP and UDP]
– Thus, multicast packets are sent to computers using an IP-addressing scheme
– Client/sender is unaware of individual computers in a group
– A multicast-group address is specified using class D Internet address
– Membership of a group is dynamic
– Multicasting is through UDP protocol only (at programming level) via multicast
addresses and ordinary port numbers
– A receiver joins a group by adding its socket to the group
– At IP level, adding process’s socket #s to a group makes the computer a
member of the group – allowing all such sockets to receive incoming packets
at specified port #s.
– How? Via local multicast capability Or via multicast routers @ Internet level
– Membership? Permanent (designated addresses) or temporary
31

IP Multicast – Example @ Application level
32

33

Interprocess Communication – 4.6 UNIX Example
34

Interprocess Communication – 4.6 UNIX Example
35

Chapter 4 a interprocess communication

More Related Content

What's hot

Viewers also liked

Similar to Chapter 4 a interprocess communication

More from AbDul ThaYyal

Chapter 4 a interprocess communication

Editor's Notes