UNIT-II

COMMUNICATION IN DISTRIBUTED
SYSTEM
38System Outlin
models2.1 e
2 System models
1. Outline
What are the three basic ways to describe Distributed systems? –

• Physical models – consider DS in terms of hardware – computers and devices that constitute a
system and their interconnectivity, without details of specific technologies

• Architectural models – describe a system in terms of the computational and communication

tasks performed by its computational elements. Client-server and peer-to-peer most commonly
used

• Fundamental models – take an abstract Difficulties and threats for distributed systems:
perspective in order to describe solutions to
individual issues faced by most distributed • Widely varying modes of use
systems
• Wide range of system environments
– interaction models
• Internal problems
– failure models
– security models • External threats
39System models2.2 Physical
models
2.2 Physical models
•Baseline physical model – minimal physical model of a distributed system as
an extensible set of computer nodes interconnected by a computer network
for the required passing of messages.

Three generations of distributed

systems

•Early distributed systems

– 10 and 100 nodes interconnected by a local area network

– limited Internet connectivity
– supported a small range of services e.g.
* shared local printers
* file servers
40System Physical
models2.2 models
* file transfer across the Internet

•Internet-scale distributed systems

– extensible set of nodes interconnected by a network of networks (the

Internet)

•Contemporary DS with hundreds of thousands nodes + emergence of:

– mobile computing
* laptops or smart phones may move from location to location –
need for added capabilities (service discovery; support for
spontaneous interoperation)

– ubiquitous computing
* computers are embedded everywhere
– cloud computing
41System Physical
models2.2 models
* pools of nodes that together provide a given service

•Distributed systems of systems (ultra-large-scale (ULS) distributed

systems)
42System Physical
models2.2 models
•significant challenges associated with contemporary
DS:

Figure 2.1 Generations of distributed systems

43System models2.3 Architectural
Models
2.3 Architectural Models
Major concerns: make the system reliable, manageable, adaptable and cost-
effective

2.3.1 Architectural elements

•What are the entities that are communicating in the distributed system?

•How do they communicate, or, more specifically, what communication

paradigm is used?

•What (potentially changing) roles and responsibilities do they have in the

overall architecture?

•How are they mapped on to the physical distributed infrastructure (what is

their placement)?
44System Architectural
models2.3 Models
Communicating entities

•From system perspective: processes

– in some cases we can say that:

* nodes (sensors)
* threads (endpoints of communication)

•From programming perspective

– objects
* computation consists of a number of interacting objects
representing natural units of decomposition for the given problem
domain
* Objects are accessed via interfaces, with an associated interface
defi- nition language (or IDL)
45System models2.3 Architectural
Models

– components – emerged due to some weaknesses with distributed

objects
* offer problem-oriented abstractions for building distributed
systems
* accessed through interfaces
·+ assumptions to components/interfaces that must be present
(i.e. making all dependencies explicit and providing a more
complete contract for system construction.)

– web services
* closely related to objects and components
* intrinsically integrated into the World Wide Web
·using web standards to represent and discover services
46System Architectural
models2.3 Models
The World Wide Web consortium
(W3C):
Web service is a software application identified by a URI, whose interfaces
and bindings are capable of being defined, described and discovered as
XML artefacts. A Web service supports direct interactions with other
software agents using XML-based message exchanges via Internet-based
protocols.
•objects and components are often used within an organization to develop
tightly coupled applications

•web services are generally viewed as complete services in their own right
47System Architectural
models2.3 Models
Communication paradigms

What is:

•interprocess communication?

•remote invocation?

•indirect communication?

Interprocess communication – low-level support for communication between pro-

cesses in distributed systems, including message-passing primitives, direct access
to the API offered by Internet protocols (socket programming) and support for
multicast communication
Remote invocation – calling of a remote operation, procedure or method
Request-reply protocols – a pattern with message-passing service to
support client-server computing
48System Architectural
models2.3 Models
Remote procedure call (RPC)

•procedures in processes on remote computers can be called as if they are

proce- dures in the local address space

•supports client-server computing with servers offering a set of operations

through a service interface and clients calling these operations directly as if
they were available locally

– RPC systems offer (at a

m

Remote method invocation (RMI)

•strongly resemble RPC but in a world of distributed

objects

•tighter integration into object-orientation framework

49System Architectural
models2.3 Models
In RPC and RMI –

•senders-receivers of messages

– coexist at the same time

– are aware of each other’s identities

Indirect communication

•Senders do not need to know who they are sending to ( space uncoupling)

•Senders and receivers do not need to exist at the same time ( time
uncoupling)

Key techniques in indirect communication:

•Group communication

•Publish-subscribe systems:
50System models2.3 Architectural
Models

– (sometimes also called distributed event-based systems)

– publishers distribute information items of interest (events) to a
similarly large number of consumers (or subscribers)

•Message queues:

– (publish-subscribe systems offer a one-to-many style of

communication), message queues offer a point-to-point service
– producer processes can send messages to a specified queue
– consumer processes can
* receive messages from the queue or
* be notified

•Tuple spaces (also known as generative communication):

– processes can place arbitrary items of structured data, called tuples, in a

51System models2.3 Architectural
Models
– other processes can either read or remove such tuples from the tuple
space by specifying patterns of interest
– readers and writers do not need to exist at the same time (Since the
tuple space is persistent)

•Distributed shared memory (DSM):

– abstraction for sharing data between processes that do not share

physical memory
52System models2.3 Architectural

Models Figure 2.2 Communication entities and

communication paradigms
53System Architectural
models2.3 Models
Roles and responibilities

•Client-server
Figure 2.3 Clients invoke individual
servers
54System Architectural
models2.3 Models
•Peer-to-peer
Figure 2.4a Peer-to-peer
architecture

– same set of interfaces to each

55System Architectural
models2.3 Models
Placement
•crucial in terms of determining the DS
properties:
– performance
– reliability
– security
Possible placement strategies:
• mapping of services to Figure 2.4b A service provided by
multiple multi- ple servers
servers
– mapping distributed objects
between servers, or
– replicating copies on several
hosts
– more closely
coupled multiple-servers –
56System Architectural
models2.3 Models
• cachin
g
– A cache is a store of recently used data objects that is closer to one
client or a particular set of clients than the objects themselves

Figure 2.5 Web proxy

server
57System Architectural
models2.3 Models
• mobile code

– Applets are an example of mobile

code Figure 2.6 Web Applets

– yet another possibility – push model: server initiates interaction (e.g. on

information updates on it)
58System Architectural
models2.3 Models
• mobile
agents
– Mobile agent – running program (including both code and data) that
travels from one computer to another in a network carrying out a
task on someone’s behalf (e.g. collecting information), and
eventually re- turning with the results.

– could be used for

* software maintenance
* collecting information from different vendors’ databases of
prices

Possible security threats with mobile code and mobile agents...

59System Architectural
models2.3 Models
2.3.2 Architectural patterns

Layering

Layered approach – complex system partitioned into a number of layers:

•vertical organisation of services

•given layer making use of the services offered by the layer below

•software abstraction

•higher layers unaware of implementation details, or any other layers beneath

them
60System models2.3 Architectural
Models

Platform and Middleware

Figure 2.7 Software and hardware service layers in distributed systems

•A platform for distributed systems and applications consists of the

lowest-level hardware and software layers.
61System models2.3 Architectural
Models

•Middleware – a layer of software whose purpose is to mask hetero-

geneity and to provide a convenient programming model to
application programmers.
62System Architectural
models2.3 Models
Tiered architecture

Tiering is a technique to organize functionality of a given layer and place this

functionality into appropriate servers and, as a secondary consideration, on to
physical nodes

Example: two-tier and three-tier architecture

functional decomposition of a given application, as follows:

•presentation logic

•application logic

•data logic
 Architectural
Models
Figure 2.8 Two-tier and three-tier • three aspects par-
63System models2.3
architectures titioned into two
processes

• (+) low latency

• (-) splitting applica-
tion logic

• (+) one-to-one map-

ping from logical
elements to physical
servers

• (-) added complexity,

network traffic and la-
tency
64System models2.3 Architectural
Models

•extension to the standard client-server style of interaction in

AJAX
WWW(Asynchronous Javascript And XML) – a way to create
interactive, partially/selectively-updatable webpages
– Javascript forntend and server-based backend
Figure 2.9 AJAX example: soccer score
✞ ☎
updates
newAjax . Request ( ’s c o r e s.php?game=Arsenal:L i v e r p o o ,
l’
{ on Success : update Score }) ;
f u n c t i o nupdate Score ( re q u e s t ) {
. . .( . .r e q u e s tc o n t a i n sthes t a t eoftheAjaxr e q u e s ti n c l u d i n gthereturnedr e s u .
l t Ther e s u l ti sparsedtoo b t a i nsomet e x tg i v i n gthescore , whichi
sused toupdatether e l e v a n tp o r t i o nofthecurrentpage .)
.... .
}
✝
(two-tier
architecture)
65System Architectural
models2.3 Models
Thin clients

•enabling access to sophisticated networked services (e.g. cloud services)

with few assumptions to client device

•software layer that supports a window-based user interface (local) for

executing remote application programs or accessing services on remote
computer

Figure 2.10 Thin clients and computer servers

Concept led to Virtual Network Computing (VNC) – VNC clients accessing

VNC servers using VNC protocol
66System Architectural
models2.3 Models
Other commonly occurring patterns

• proxy pattern

– designed to support location transparency in RPC or RMI

– proxy created in local address space, with same interface as the remote
object

• brokerage in web services

– supporting interoperability in potentially complex

distributed infrastructures
– service provider, service requestor and service broker
– brokerage reflected e.g. in registry in Java RMI and naming service in
CORBA
67System Architectural
models2.3 Models
Figure 2.11 The web service architectural
pattern

• Reflection pattern

– a means of supporting both:

* introspection (the dynamic discovery of properties of the system)
* intercession (the ability to dynamically modify structure or
behaviour)
– used e.g. in Java RMI for generic dispatching
– ability to intercept incoming messages or invocations
68System Architectural
models2.3 Models
– dynamically discover interface offered by a given object
– discover and adapt the underlying architecture of the system

2.3.3 Associated middleware solutions

The task of middleware is to provide a
higher-l development of distributed systems and, through layering, to abstract over
heterogene- ity in the underlying infrastructure to promote interoperability and
portability.
69System Architectural
models2.3 Models
Categories of middleware

Figure 2.12 Categories of

middleware
70System Architectural
models2.3 Models
Limitations of middleware

Some communication-related functions can be completely and reliably imple-

mented only with the knowledge and help of the application standing at the end
points of the communication system.
Example: e-mail transfer need another layer of fault-tolerance that even TCP
can- not offer
71System Fundamental
models2.4 models
4. Fundamental models

What is:

•Interaction model?

•Failure model?

•Security model?

1. Interaction model

•processes interact by passing messages –

– communication (information flow) and

– coordination (synchronization and ordering of activities) between pro-
cesses
72System models2.4 Fundamental
models

•communication takes place with delays of considerable duration

– accuracy with which independent processes can be coordinated is

limited by these delays
– and by difficulty of maintaining the same notion of time across all the
computers in a distributed system

Behaviour and state of DS can be described by a distributed algorithm:

•steps to be taken by each interacting process

•+ transmission of messages between them

State belonging to each process is completely private

73System Fundamental
models2.4 models
Performance of communication channels

• latency – delay between the start of message’s transmission from one

process and the beginning of receipt by another

• bandwidth of a computer network – the total amount of information that can

be transmitted over it in a given time

• Jitter – the variation in the time taken to deliver a series of messages

Computer clocks and timing events

• clock drift rate – rate at which a computer clock deviates from a perfect
refer- ence clock
74System Fundamental
models2.4 models
Two variants of the interaction
model

Synchronous distributed Asynchronous distributed

systems: systems:
•The time to execute each step of a No bounds
on:
process has known lower and
•Process execution
upper bounds
speeds
•Each message transmitted over a •Message transmission
channel is received within a delays
known bounded time •Clock drift
rates
•Each process has a local clock
whose drift rate from real time has
a known bound
75System Fundamental
models2.4 models
Event ordering

Figure 2.13 Real-time ordering of

events

• Logical time – based on event

ordering
76System Fundamental
models2.4 models
2. Failure model
•faults occur in:

– any of the computers (including software faults)

– or in the network

•Failure model defines and classifies the faults

Omission failures

•process or communication channel fails to perform actions it is supposed to

do

Process omission failures

•cheaf omission failure of a process is to crash

– crash is called fail-stop if other processes can detect certainly that the
77System Fundamental
models2.4 models
Communication omission failures
•communication channel does not transport a message p’s outgoing
from message buffer to q’s incoming message buffer

– known as dropping messages

* send-omission failures
* receive-omission failures
* channel-omission
failures

Figure 2.14 Processes and channels

All failures so far: benigh

78System models2.4 Fundamental
models

Arbitrary failures
arbitrary or Byzantine failure is used to describe the worst possible failure
se-
mantics, in which any type of error may
occur Figure 2.15 Omission and
arbitrary failures
79System Fundamental
models2.4 models
Timing failures

•applicable in synchronous distributed

systems Figure 2.16 Timing failures

Masking failures

•knowledge of the failure can enable a new service to be designed to mask the
failure of the components on which it depends
80System Fundamental
models2.4 models
Reliability of one-to-one communication

•reliable communication:

– Validity: Any message in the outgoing message buffer is eventually

deliv- ered to the incoming message buffer
– Integrity: The message received is identical to one sent, and no
messages are delivered twice
81System Fundamental
models2.4 models
3. Security model

•modular nature of distributed systems and their openness exposes them to

attack by

– both external and internal agents

•Security model defines and classifies attack forms,

– providing a basis for the analysis of threats

– basis for design of systems that are able to resist them

the security of a distributed system can be achieved by securing the processes

and the channels used for their interactions and by protecting the objects that
they encapsulate against unauthorized access.
82System Fundamental
models2.4 models
Protecting objects
•Users with access rights

•association of each invocation and each result with the authority on which it
is issued

– such an authority is called a principal

* principal may be a user or a process

Figure 2.17 Objects and principals

83System Fundamental
models2.4 models
Securing processes and their interactions
•securing communications over open
cahnnels

•open service interfaces

The enemy
or also: adversary
Figure 2.18 The enemy
84System Fundamental
models2.4 models
Threats to processes

•lack of knowledge of true source of a

message

– problem both to server and client side

– example: spoofing a mail server

Threats to communication channels

•threat to the privacy and integrity of

messages

•can be defeated using secure channels

85System Fundamental
models2.4 models
Defeating security threats

Cryptography and shared secrets

•Cryptography is the science of keeping messages secure

•Encryption is the process of scrambling a message in such a way as to

hide its contents

Authentication

•based on shared secrets authentication of messages – proving the identities

sup- plied by their senders
86System Fundamental
models2.4 models
Secure channels

Figure 2.19 Secure

channels

Properties of a secure channel:

•Each of the processes knows reliably the identity of the principal on whose
behalf the other process is executing

•A secure channel ensures the privacy and integrity (protection against

tamper- ing) of the data transmitted across it
87System models2.4 Fundamental
models
•Each message includes a physical or logical timestamp to prevent messages
from being replayed or reordered

Other possible threats from an enemy

•Denial of service:

– the enemy interferes with the activities of authorized users by making

ex- cessive and pointless invocations on services or message
transmissions in a network, resulting in overloading of physical
resources (network band- width, server processing capacity)

•Mobile code:

– execution of program code from elsewhere, such as the email

attachment etc.
88System Fundamental
models2.4 models
The uses of security models

Security analysis involves

•the construction of a threat model:

– listing all the forms of attack to which the system is

exposed
– an evaluation of the risks and consequences of each

End of week 2
144Interprocess Introductio
communication4.1 n
4 Interprocess communication
4.1 Introduction
Figure 4.1 Middleware layers

How middleware and application programs can use UDP and TCP?
What is specific about IP multicast? Why/how could it be made more
reliable? What is an overlay network?
What is MPI?
145Interprocess The API for the Internet
communication4.2 protocols
2. The API for the Internet protocols

1.The characteristics of interprocess communication

Synchronous and asynchronous communication

synchronous – sending and receiving processes synchronize at every message
•both send and receive – blocking operations

– whenever send is issued – sending process blocked until receive is

issued
– whenever receive is issued by a process, it is blocked until the message
arrives
asynchronous – send – nonblocking; receive – either blocking or non-

blocking In case threads are supported (Java) blocking receive has no w

disadvantages
thread is handling the communication while other threads can continue their
146Interprocess The API for the Internet
communication4.2 protocols
Message destinations

•messages sent to ( Internet address, local

port)

Reliability & ordering – also important factors

4.2.2 Sockets
socket – abstraction providing an endpoint for communication
betwee
Figure 4.2 Sockets and
ports
147Interprocess The API for the Internet
communication4.2 protocols
Java API for Internet addresses

•Java class InetAddress referring to Domain Name System (DNS)

✞
hostnames ☎
Inet AddressaComputer = Inet Address . getByName ( );
✝"bruno.dcs.qmul.ac.uk"

4.2.3 UDP datagram communication

– datagram transmission without acknowledgement or retries

•create a socket bound to an Internet address of the local host and a local port

1.A server will bind its socket to a server port

2.A client binds its socket to any free local port

•The receive method returns the Internet address and port of the sender, in
addi- tion to the message (allowing the recipient to send a reply)
148Interprocess communication4.2 The API for the Internet

protocols Issues related to datagram communication:

Message size:

•in IP protocol – ≤ 216(incl. headers), but in most environments ≤ 8

kilobytes

Blocking:

•Sockets normally provide non-blocking sends and blocking receives

Timeouts:

•if needed, should be fairly large in comparison with the time for message
transmission

Receive from any:

•by default every message is placed in a receiving queue

149Interprocess The API for the Internet
communication4.2 protocols
Failure model for UDP datagrams
(In Chapter 2: failure model for communication channels – reliable
communication in terms of 2 properties – integrity and validity)
UDP datagrams suffer from

•Omission failures

•Ordering

Applications – provide your own checks!

Use of UDP

•Domain Name System (DNS)

•Voice over IP (VOIP)

No overheads associated with guaranteed message delivery. But overheads on:

150Interprocess communication4.2 The API for the Internet
protocols

•the need to store state information at the source and destination

•transmission of extra messages

•latency for the sender

Java API for UDP datagrams

2 classes: DatagramPacket and DatagramSocket

Class DatagramPacket – provides constructor for making an instance out of

•an array of bytes comprising a message

•the length of the message

•and the Internet address and

•local port number of the destination socket

 The API for the Internet
protocols
DatagramPacke
151Interprocess communication4.2
t array of bytes containing message length of message Internet address port number
152Interprocess communication4.2 The API for the Internet

protocols On the receiving side: DatagramPacket has another constructor +

methods get-
•Data, getPort
Class and getAddress
– supports sockets for sending
DatagramSocket

and receiving datagrams

• •constructor with port number

• – has also no-argument case – system to

– send and receive
choose a free port
* argument –
DatagramPacket
• •Methods:
– setSoTimout – block receive
for specified time
before
throwin
g
InterruptedIOException
– connect – to connect to a particular remote port and internet address for
exclusive communication to/from there
Figure 4.3 UDP client sends
153Interprocess a message to the server
communication4.2 TheandAPI
gets afor the Internet
✞ ☎
reply
importjava . net . ;
protocols *
importjava . i o . * ;
p u b l i cc l a s sUDPClient
( S t r i n gargs [ ] ) {
{ / /a rgsg i v emessagec o n t e n t sands e r v e rhostname
p u b l i cs t a t i cvoidmain
DatagramSocketa Socket = n u l l ;
try {
a Socket = newDatagramSocket ( ) ;
byte [ ] m = args [ 0 ] . g e t B y t e s ( ) ;
Inet AddressaHost = Inet Address . getByName ( args [ 1 ] ) ;
i n ts e r v e r Po r t = 6789 ;
DatagramPacketr e q u e s t = newDatagramPacket (m,m. l e n g t h ( ) , aHost , s e r v e r Po r t
);
aSocket . send ( re q u e s t ) ;
byte [ ] b u f f e r = newbyte [ 1 0 0 0 ] ;
DatagramPacketr e p l y = newDatagramPacket ( buffer , b u f f e r . l e n g t h ) ;
aSocket . r e c e i v e ( r e p l y ) ;
System . out . p r i n t l n ( "Reply: " + newS t r i n g ( r e p l y . get Data ( ) ) ) ;
} catch ( Socket Exceptione ) { System . out . p r i n t l n ( "Socket: " + e . get Message ( ) ) ;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "IO: " + e . get Message ( ) ) ; }
} f i n a l l y { i f ( a Socket != n u l l ) aSocket . c l o s e ( ) ; }
} }
✝
 Figure 4.4 UDP server
154Interprocess repeatedly receives a request
communication4.2 The and
APIsends
foritthe
backInternet
to the
✞ ☎
client
importjava . net . * ;
protocols
importjava . i o . * ;
p u b l i cc l a s sUDPServer
( S t r i n gargs [ ] ) {
{ = n u l l;
p u b l i cs t a t i cvoidmain
DatagramSocketa
a Socket = newDatagramSocket ( 6 7 8 9 )
Socket
; try {
byte [ ] b u f f e r = newbyte [ 1 0 0 0 ] ;
while ( t ru e ) {
DatagramPacketr eques = newDatagramPacket ( buffer , b u f f e r . l e n g t h )
taSocket . r e c e i v e ( r e q u e s t; ) ;
DatagramPacketr e p l y = newDatagramPacket ( r e q u e s t . get Data ( ) ,
r e q u e s t . get Length ( ) , r e q u e s t . get Address ( ) , r e q u e s t . g e t Po r t ( ) ) ;
aSocket . send ( re p l y ) ;
}
} catch ( Socket Exceptione ) { System . out . p r i n t l n ( "Socket: " + e . get Message ( )
);
} catch ( IOExceptione ) { System . out . p r i n t l n ( "IO: " + e . get Message ( ) ) ; }
} f i n a l l y { i f ( a Socket != n u l l ) aSocket . c l o s e ( ) ; }
} }
✝
155Interprocess communication4.2 The API for the Internet
protocols

4.2.4 TCP stream communication

Network characteristics hidden by stream abstraction:

•Message sizes

•Lost messages

•Flow control

•Message duplication and ordering

•Message destinations

– once connection established – simply read/write to/from stream

– to establish connection
* connect request (from client)
* accept request (from server)
156Interprocess communication4.2 The API for the Internet

protocols Pair of socets associated with srtream – read and write

Issues related to stream communication:

•Matching data items – (e.g. int should be followed by float – matching in

both side)

•Blocking –

– while trying to read data before it has arrived in queue

– writing data to the stream, but the TCP flow-control mechanism still
wait- ing for data acknowledgements etc.

•Threads – usually used

Failure model

•integrity
157Interprocess The API for the Internet
communication4.2 protocols
– checksums
– sequence numbers

•validity

– timeouts
– retransmission

Use of TCP
HTTP, FTP, Telnet, SMTP

Java API for TCP streams

Classes ServerSocket and Socket
Class ServerSocket:

•to listen connect reqests from

158Interprocess The API for the Internet
communication4.2 protocols
• accept method

– gets a connect request from the queue or

– if the queue is empty, blocks until one arrives
– result of executing accept – an instance of Socket – a socket to use for
communicating with the client

Class Socket:
•for use by pair of processes

•client constructor – to create a socket specifying DNS hostname and port of

a server

– connects to the specified remote computer and port number

•methods:

– getInputStream and getOutputStream

Figure 4.5 TCP client makes
159Interprocess connection to server, The
communication4.2 sends API
request
forandthe
receives
Internet ☎
✞
reply
importjava . net . ;
protocols *
importjava . i o . * ;
p u b l i cc l a s sTCPClient
( S t r i n gargs [ ] ) {
{ / /argumentssupplymessageandhostnameofd e s t i n a t i o n
p uSockets
b l i cs t a t i cvoidmain
= n u l l;
try {
i n ts e r v e r Po r t = 7896 ;
s = newSocket ( args [ 1 ] , s e r v e r P o r t ) ;
Data Input Streamin = newData Input Stream ( s . get Input Stream ( ) ) ;
DataOutputStreamout = newDataOutputStream ( s . get Output Stream ( ) ) ;
out . writeUTF ( args [ 0 ] ) ; / /UTFi sas t r i n gencodingseeSn4 . 3
S t r i n gdata = in . readUTF ( ) ;
System . out . p r i n t l n ( "Received: "+ data ) ;
} catch ( UnknownHostExceptione ) {
System . out . p r i n t l n ( "Sock:" +e . get Message ( ) ) ;
} catch ( EOFExceptione ) { System . out . p r i n t l n ( "EOF:" +e . get Message ( ) ) ;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "IO:" +e . get Message ( ) ) ; }
} f i n a l l y { i f ( s != n u l l ) t r y { s . c l o s e ( ) ; } catch ( IOExceptione ) { System .
out .
p r i n t l n ( "c l o s e:" +e . get Message ( ) ) ; } }
} }
✝
160Interprocess communication4.2 The API for the Internet
protocols

✞ ☎
importjava . net . * ;
importjava . i o . * ;
Figure 4.6 TCP
{ server makes a connection for each
p u b l i cc l a s sTCPServer
p u b l i cs t a t i
( S t r i n gargs [ ] ) {
client and then echoes the client’s request
cvoidmain try {
i n ts e r v e r Po r t = 7896 ;
Server Socketl i s t e n S o c k e = newServer Socket ( s e r v e r Po r t )
t while ( t ru e ) { ;
Socketc l i e n t S o c k e t = l i s t e n S o c k e t . a c c e p t ( )
;
} Connectionc = newConnection ( c l i e n t S o c k e t )
;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "Li s t e :" +e . get Message ( ) ) ;
} n }
}
clas {
sConnectionextendsThread
Data Input Streamin ;
DataOutputStreamout ;
p u b l i cConnection
Socketc l i e n t S o c k e t ( Socketa
; ClientSocket )
{
try {
clientSocket = aClientSocket ;
161Interprocess communication4.2 The API for the Internet
in = newData Input Stream ( c l i e n t S o c k e t . get Input Stream ( ) ) ;
out =newDataOutputStream ( c l i e n t S o c k e t . get Output Stream ( ) ) ;
protocols
this . start () ;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "Connection:" +e . get Message ( ) ) ;
} }
p u b l i cvoidrun () {
try { / /anechos e r v e r
S t r i n gdata = in . readUTF ( )
o; ut . writeUTF ( data ) ;
} catch ( EOFExceptione ) { System . out . p r i n t l n ( "EOF:" +e . get Message ( ) ) ;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "IO:" +e . get Message ( ) ) ; }
} f i n a l l y { t r y { c l i e n t S o c k e t . c l o s e ( ) ; } catch ( IOExceptione ) { / * c l o s ef a i l e d * /
}}
} }
✝
162Interprocess communication4.3 External data representation and
marshalling
4.3 External data representation and marshalling
•messages ←−

– data values of many different types

– different floating-point number representations
– integers – big-endian, little-endian order
– ASCII – 1byte; Unicode – 2bytes

⇒ either:
a) convert data to agreed external format, or
b) transmit data in sender’s format + format used – recipient converts the values if
needed

external data representation: agreed standard for the representation of data struc-
tures and primitive values
163Interprocess communication4.3 External data representation and
marshalling
marshalling: process of taking a collection of data items and assembling them into
a form suitable for transmission in a message

unmarshalling: process of disassembling a collection data items from a message

at the destination

•CORBA’s (Common Object Request Broker Architecture) common data

representation (bin, just values)

•Java’s object serialization (bin, data + type info)

•XML (Extensible Markup Languaga) (txt, may refer to externally

defined
namespaces)

•Google – protocol buffers (both stored and transmitted data)

•JSON (JavaScript Object Notation)http://www.json.org

164Interprocess communication4.3 External data representation and
marshalling

4.3.1 CORBA’s Common Data Representation (CDR)

primitive 4.unsigned 7.char 10.any
types: 1.short (which long can represent
8.boolean any basic or
(16-bit)
2.long (32- 5.float (32-bit) (TRUE,
constructed
bit) FALSE)
3.unsigne 6.double type)
d short 9.octet (8-
(64
bit)
Constructed (composite) types: sequence of bytes in a particular
-
order: Figure 4.7 CORBA CDR for constructed types
bit)
165Interprocess communication4.3 External data representation and

marshalling CORBA CDR that contains the three fields of a struct whose

respective types are

string, string and unsigned long:
•Person struct with value: {‘Smith’, ‘London’,

1984} Figure 4.8 CORBA CDR message

 External data representation and
marshalling
✞ ☎
166Interprocess
structPerson { communication4.3
stringname ;
stringplace ;
unsignedlongyear
;
✝
};
Marshalling through CORBA IDL

Sun XDR standard

•similar to CORBA in many ways

•sending messages between clients and servers in Sun

NFS

•http://www.cdk5.net/ipc
167Interprocess External data representation and
communication4.3 marshalling
4.3.2
✞ Java object ☎
serialization
p u b l i cc l a s sPersonimplementsS e r i a l i z a b l e {
p r i v a t eS t r i n gname
;
;
p r i v a t eS t ri n gp l a c e
p u b l i cPerson ( S t ri n gaName , S t ri n gaPlace , i n taYear ) {
p r i v a t ei n ty ear ;
name = aName ;
p l a c e = a Place ;
year = aYear ;
}
/ /f o l l o w e dbymethodsf o ra c c e s s i n gt h ei n s t a n c ev a r i a b l e s
}
✝

serialization – flattening an object or a connected set of objects into a serial form

suitable for storing on disk or transmitting in a message
deserialization
168Interprocess – vica communication4.3
versa, assuming no a priori knowledge
Externalabout
dataof types of
objects
representation and marshalling
– self-containness

•serialization of an object + all objects it references as well to ensure that with

the object reconstruction, all of its references can be fulfilled at the
destination
✞ ☎
•recursive=procedure
Personp newPerson ( "Smith" , "London" , 1984)
✝ ;
Figure 4.9 Indication of Java serialized
form
169Interprocess External data representation and
communication4.3 marshalling
•serialize:

– create an instance of the class ObjectOutputStream and invoke its

writeObject method

•deserialize:

– open an ObjectInputStream on the stream and use its readObject

method to reconstruct the original object

(de)serialization carried out automatically in RMI

Reflection -– the ability to enquire about the properties of a class, such as the
names and types of its instance variables and methods

•enables classes to be created from their names

•a constructor with given argument types to be created for a given class

170Interprocess communication4.3 External data representation and
marshalling
•Reflection makes it possible to do serialization and deserialization in a com-
pletely generic manner

4.3.3 Extensible Markup Language (XML)

•defined by the World Wide Web Consortium (W3C)

•data items are tagged with ‘markup’ strings

•tags relate to the structure of the text that they enclose

•XML is used to:

– enable clients to communicate with web services

– defining the interfaces and other properties of web services
– many other uses
171Interprocess communication4.3 External data representation and
marshalling

* specification of user interfaces

* encoding of configuration files in operating systems

•clients usually use SOAP messages to communicate with web services

SOAP – XML format whose tags are published for use by web services and their
clients
XML elements and attributes
Figure 4.10 XML definition of the Person
✞ ☎
structure
< personid ="123456789" >
<name>Smith </ name>
< place >London </ place
>
<year >1984 </ year >
</ person > <!−− acomment −−>
✝

Elements: portion of character data surrounded by matching start and end

172Interprocess communication4.3 External data representation and
marshalling

•An empty tag – no content and is terminated with /> instead of >

– For example, the empty tag <european/> could be included within

the
<person> ...</person> tag

Attributes: element – generally a container for data, whereas an attribute – used

for labelling that data

•Attributes are for simple values

•if data contains substructures or several lines, it must be defined as an element

Names start with letter _ or :

Binary data – expressed in character data in base64

Parsing and well-formed documents

 External data representation and
marshalling
✞ ☎
173Interprocess
<?XMLversio
communication4.3
= "1 .0" encoding = "UTF−8" standalone = "yes"
✝n ?>

XML namespaces – URL referring to the file containing the namespace

definitions.

✞ •For example: ☎
xmlns : pers = "http: /
✝/www.cdk5.net/person"

Figure 4.11 Illustration of the use of a namespace in the Person

✞ ☎
structure
< personpers : id ="123456789" xmlns : pers = "h t t p: / /www.cdk >
5.net/person"
< pers : name> Smith </ pers : name>
< pers : place > London </ pers : p l a c e >
< pers : year > 1984 </ pers : year >
✝</ person >
174Interprocess communication4.3 External data representation and
marshalling
XML schemas [www.w3.org VIII] defines the elements and attributes that can ap- pear in a
document, how the elements are nested and the order and number of elements, and
whether an element is empty or can include text

•used for encoding and

validation
Figure
✞
4.12 An XML schema for the Person ☎
structure
<xsd : schemaxmlns : xsd = URLo fXMLschemad e f i n i t i o n s
>
< xsd : elementname = "person" type ="person Type" / >
< xsd : complexTypename ="person Type" >
<xsd <xsd
: sequence
: > = "name" type ="xs:s t r i n g" / >
elementname = "p lace" type ="xs:s t r i n g" / >
<xsd : = "year" type ="xs:p o s i t i v e I n t e g e r" /
elementname >
<xsd <xsd
: a t t r: i b u t ename = "i type = "xs:p o s i t i v e I n t e g e r" /
d" elementname >
</ xsd : sequence
</ xsd : complexType > >
✝</ xsd : schema >

APIs for accessing XML – in Java, Python

175Interprocess External data representation and
communication4.3 marshalling
4. Remote object references

Java, CORBA

• remote object reference is an identifier for a remote object that is valid

through- out a distributed system

Figure 4.13 Representation of a remote object reference

176Interprocess Multicast
communication4.4 communication
4. Multicast communication
single message from one process to each of the members of a group of
processes,
usually in such a way that the membership of the group is transparent to the sender
1.Fault tolerance based on replicated services

2.Discovering services in spontaneous

networking 3.Better performance through

replicated data 4.Propagation of event

notifications

4.4.1 IP multicast – An implementation of multicast communication

Java’s API to it via the MulticastSocket class

IP multicast
177Interprocess Multicast
communication4.4 communication
•group specified by a Class D Internet address

– first 4 bits are 1110 in IPv4

•Being a member of a multicast group allows a computer to receive IP

packets sent to the group

•membership dynamic

– computers allowed to join or leave at any time

– to join an arbitrary number of groups
– possible to send datagrams to a multicast group without being a
membe

•At the application programming level, IP multicast available only via UDP

•Multicast routers
178Interprocess Multicast
communication4.4 communication
Multicast address allocation:

•Local Network Control Block (224.0.0.0 to 224.0.0.225)

•Internet Control Block (224.0.1.0 to 224.0.1.225)

•Ad Hoc Control Block (224.0.2.0 to 224.0.255.0)

•Administratively Scoped Block (239.0.0.0 to 239.255.255.255) –

constrained propagation

Failure model for multicast datagrams

•failure characteristics as UDP datagrams

• ureliable multicast
179Interprocess Multicast
communication4.4 communication
Java API to IP
multicast
Figure 4.14 Multicast peer joins a group and sends and receives
datagrams ☎
✞importjava . net . * ;
importjava . i o . * ;
p u b l i cc l a s sM u l t i c a s t Pe e {
r p u b l i cs t a t i ( S t r i n gargs [ ] ) {
cvoidmain
/ /a rgsg i v emessagec o n t e n t s&d e s t i n a t i o nm u l t i c a s tgroup(e.g." 2 2 8 . 5 . 6 . 7 " )
M u l t i c a s t S o c k e ts = n u l l ;
try {
Inet Addressgroup = Inet Address . getByName ( args [ 1 ] ) ;
s = newM u l t i c a s t S o c k e t ( 6 7 8 9 ) ;
s . join Group ( group ) ;
byte [ ] m = args [ 0 ] . g e t B y t e s ( ) ;
DatagramPacketmessageOut =
newDatagramPacket (m, m. l ength , group , 6789 ) ;
s . send ( messageOut ) ;
byte [ ] b u f f e r = newbyte [ 1 0 0 0 ] ;
f o r ( i n ti = 0 ; i < 3 ; i ++) { / /g e tmessagesfromo t h e r si ngroup
DatagramPacketmessage In =
newDatagramPacket ( buffer , b u f f e r . l e n g t h ) ;
s . r e c e i v e ( message In ) ;
System . out . p r i n t l n ( "Received:" + newS t r i n g ( message In . get Data ( ) )
);
 180Interprocess communication4.4 Multicast
communication

}
s . leave Group ( group ) ;
} catch ( Socket Exceptione ) { System . out . p r i n t l n ( "Socket: " + e . get Message ( ) ) ;
} catch ( IOExceptione ) { System . out . p r i n t l n ( "IO: " + e . get Message ( ) ) ;
} f i n a l l y { i f ( s != n u l l ) s . c l o s e ( ) ; }
}
✝ }
End of week
4
181Interprocess communication4.5 Network virtualization: Overlay
networks
4.5 Network virtualization: Overlay networks
Network virtualization – construction of many different virtual networks over an
existing network

•each virtual network redefines its own addressing scheme, protocols, routing
algorithms – depending on particular application on top
182Interprocess Network virtualization: Overlay
communication4.5 networks
1. Overlay networks
overlay network – virtual network consisting of nodes and virtual links, which
sits on top of an underlying network (such as an IP network) and offers
something that is not otherwise provided:

•a service for a class of applications or a particular higher-level service

– e.g. multimedia content distribution

•more efficient operation in a given networked environment

– e.g. routing in an ad hoc network

•an additional feature

– e.g. multicast or secure communication.

This leads to a wide variety of types of overlay as captured by Figure 4.15

183Interprocess
communication4.5
Figure 4.15 Types of
overlay

Network virtualization:
Overlay networks
184Interprocess Network virtualization: Overlay
communication4.5 networks
Figure 4.15 Types of overlay
(Continued)
185Interprocess Network virtualization: Overlay
communication4.5 networks
•Advantages:

– new network services changes to the underlying network

– encourage experimentation with network services and the
customization of services to particular classes of application
– Multiple overlays can coexist

•Disadvantages:

– extra level of indirection (henceperformance penalty)

– add to the complexity of network services
186Interprocess communication4.5 Network virtualization: Overlay
networks

4.5.2 Skype: An example of an overlay network

Peer-to-peer application offering VoIP; 370M users (2009); developed by
Kazaa
p2p filesharing app

Skype architecture
•hosts and super nodes (which being selected on

demand) Figure 4.16 Skype overlay architecture

187Interprocess Network virtualization: Overlay
communication4.5 networks
User connection

•users authenticated via login server

Search for users

•super nodes – to perform the efficient search of the global index of users dis-
tributed across the super nodes

– On average, eight super nodes are contacted

– 3-4 seconds to complete for hosts that have a global IP address (5-6
second, if behind a NAT-enabled router)

Voice connection
•TCP for signalling call requests and terminations and either UDP or TCP for
the streaming audio
188Interprocess communication4.5 Network virtualization: Overlay
networks

– UDP is preferred
– TCP can be used in certain circumstances to circumvent firewalls
189Interprocess communication4.6 Case study:
MPI
4.6 Case study: MPI

MPI (The Message Passing

Interface)
•A message-passing library specification
– extended message-passing model
– not a language or compiler specification
– not a specific implementation or product

•Full featured; for parallel computers, clusters, and heterogeneous networks

•Designed to provide access to advanced parallel hardware for end users,

library writers, and tool developers

MPI as STANDARD
Goals of the MPI standard MPI’s prime goals are:
190Interprocess Case study:
communication4.6 MPI
•To provide source-code portability
•To allow efficient

implementations MPI also offers:

•A great deal of functionality

•Support for heterogeneous parallel architectures

4 types of MPI calls

1.Calls used to initialize, manage, and terminate communications

2.Calls used to communicate between pairs of processors (Pair

communication) 3.Calls used to communicate among

groups of processors (Collective

communication)
191Interprocess Case study:
communication4.6 MPI
MPI basic subroutines (functions)
MPI_Init: initialise MPI
MPI_Comm_Size: how many PE?
MPI_Comm_Rank: identify the
PE MPI_Send
MPI_Receive
MPI_Finalise: close
MPI
192Interprocess communication4.6 Case study:
MPI
Example (Fortran90) 11.1 Greetings(
http://www.ut.ee/~eero/SC/
konspekt/Naited/greetings.f90.html)
Figure 4.17 An overview of point-to-point communication in
MPI
193Interprocess
communication4.6
Figure 4.18 Selected send operations in
MPI
Case
study:
MPI