Chapter 6 slides

Slides for Chapter 6:
Indirect Communication

From Coulouris, Dollimore, Kindberg and Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012

Indirect communication

is defined as communication between entities in a distributed system
through an intermediary with no direct coupling between the sender and
the receiver(s).

Space uncoupling, in which the sender does not know or need to know the identity of
the receiver(s), and vice versa. Because of this space uncoupling, the system developer
has many degrees of freedom in dealing with change: participants (senders or receivers)
can be replaced, updated, replicated or migrated.

Time uncoupling, in which the sender and receiver(s) can have independent lifetimes.
In other words, the sender and receiver(s) do not need to exist at the same time to
communicate. This has important benefits, for example, in more volatile environments
where senders and receivers may come and go.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012 2

Figure 6.1
Space and time coupling in distributed systems

© Pearson Education 2012
3

Figure 6.2
Open and closed groups

Group communication offers a service whereby a message is sent to a
group and then this message is delivered to all members of the group. In
this action, the sender is not aware of the identities of the receivers.

Closed group Open group

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4

Figure 6.2
Open and closed groups

A group is said to be closed if only members of the group may multicast to
it. A process in a closed group delivers to itself any message that it
multicasts to the group. A group is open if processes outside the group
may send to it.

Closed group Open group


Overlapping and non-overlapping groups:

In overlapping groups, entities (processes or objects) may be members of
multiple groups, and non-overlapping groups imply that membership does
not overlap (any process belongs to at most one group).
Note that in real-life systems, it is realistic to expect that group
membership will overlap.

Synchronous and asynchronous systems: There is a requirement to
consider group communication in both environments.

6

Reliability and Ordering

Reliability is defined in terms of two properties:
Integrity: the message received is the same as the one sent, and no
messages are delivered twice
Validity: any outgoing message is eventually delivered.

Ordering is not guaranteed by underlying interprocess communication
primitives. To counter this, group communication services offer ordered
multicast, with the option of FIFO ordering, Causal ordering, Total
ordering.

7

Figure 6.3
The role of group membership management

Group
address
expansion

Group Leave
send

Multicast Group membership
communication Fail
management

Join

Process group


The role of group membership management

• Providing an interface for group membership changes
• Failure detection
• Notifying members of group membership changes
• Notifying members of group membership changes


Figure 6.4
The architecture of JGroups

Building blocks offer
higher-level abstractions,
building on the underlying
service offered by Channels represent the most
channels. primitive interface for application
developers, offering the core
functions of joining, leaving,
sending and receiving.

The protocol stack provides the
underlying communication protocol,
constructed as a stack of protocol
layers.
10

Figure 6.5
Java class FireAlarmJG

import org.jgroups.JChannel;
public class FireAlarmJG {
public void raise() {
try {
JChannel channel = new JChannel();
channel.connect("AlarmChannel");
Message msg = new Message(null, null, "Fire!");
channel.send(msg);
}
catch(Exception e) {
}
}
11

Figure 6.6
Java class FireAlarmConsumerJG

import org.jgroups.JChannel;

public class FireAlarmConsumerJG {
public String await() {
try {
JChannel channel = new JChannel();
channel.connect("AlarmChannel");
Message msg = (Message) channel.receive(0);
return (String) msg.GetObject();
} catch(Exception e) {
return null;
}
}
}
12

Dealing room system

A dealing room system could be implemented by processes with two different
tasks:

• An information provider process continuously receives new trading
information from a single external source. Each of the updates is regarded as an
event. The information provider publishes such events to the publish-subscribe
system for delivery to all of the dealers who have expressed an interest in the
corresponding stock. There will be a separate information provider process for
each external source.

• A dealer process creates a subscription representing each named stock that
the user asks to have displayed. Each subscription expresses an interest in
events related to a given stock at the relevant information provider. It then
receives all the information sent to it in notifications and displays it to the user.
13

Figure 6.7
Dealing room system

Dealer’s computer External Dealer’s computer
source

Dealer Notification Notification Dealer

Notification Information
provider Notification

Notification
Notification
Notification
Dealer’s computer Dealer’s computer
Notification
Information
provider
Notification
Dealer Notification
Dealer
External
source


Characteristics of publish-subscribe systems

Publish-subscribe systems have two main characteristics:

Heterogeneity: When event notifications are used as a means of
communication, components in a distributed system that were not designed to
interoperate can be made to work together.

Asynchronicity: Notifications are sent asynchronously by event-generating
publishers to all the subscribers that have expressed an interest in them to
prevent publishers needing to synchronize with subscribers – publishers and
subscribers need to be decoupled.

15

Figure 6.8
The publish-subscribe paradigm

16

Publish-subscribe systems

The expressiveness of publish-subscribe systems is determined by the
subscription (filter) model, with a number of schemes defined and considered
in increasing order of sophistication:

•Channel-based
•Topic-based (also referred to as subject-based)
•Indirect communication/publish-subscribe
•Content-based
•Type-based

17

Figure 6.9
A network of brokers

18

Figure 6.10
The architecture of publish-subscribe systems

19

Figure 6.11
Filtering-based routing

upon receive publish(event e) from node x 1
matchlist := match(e, subscriptions) 2
send notify(e) to matchlist; 3
fwdlist := match(e, routing); 4
send publish(e) to fwdlist - x; 5
upon receive subscribe(subscription s) from node x 6
if x is client then 7
add x to subscriptions; 8
else add(x, s) to routing; 9
send subscribe(s) to neighbours - x; 10

20

Figure 6.12
Rendezvous-based routing

upon receive publish(event e) from node x at node i
rvlist := EN(e);
if i in rvlist then begin
matchlist :=match(e, subscriptions);
send notify(e) to matchlist;
end
send publish(e) to rvlist - i;
upon receive subscribe(subscription s) from node x at node i
rvlist := SN(s);
if i in rvlist then
add s to subscriptions;
else
send subscribe(s) to rvlist - i;

21

Figure 6.13
Example publish-subscribe system

22

Figure 6.14
The message queue paradigm

23

Figure 6.15
A simple networked topology in WebSphere MQ

24

Figure 6.16
The programming model offered by JMS

25

Figure 6.17
Java class FireAlarmJMS

import javax.jms.*;
import javax.naming.*;
public class FireAlarmJMS {

try { 1
Context ctx = new InitialContext(); 2
TopicConnectionFactory topicFactory = 3
(TopicConnectionFactory)ctx.lookup ("TopicConnectionFactory"); 4
Topic topic = (Topic)ctx.lookup("Alarms"); 5
TopicConnection topicConn = 6
topicConnectionFactory.createTopicConnection(); 7
TopicSession topicSess = topicConn.createTopicSession(false, 8
Session.AUTO_ACKNOWLEDGE);
9
TopicPublisher topicPub = topicSess.createPublisher(topic);
10;
TextMessage msg = topicSess.createTextMessage(); 11
msg.setText("Fire!"); 12
topicPub.publish(message); 13
} catch (Exception e) { 14
} 15Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
26
}

Figure 6.18
Java class FireAlarmConsumerJMS

import javax.jms.*; import javax.naming.*;
public class FireAlarmConsumerJMS
try { 1
Context ctx = new InitialContext(); 2
TopicConnectionFactory topicFactory = 3
(TopicConnectionFactory)ctx.lookup("TopicConnectionFactory"); 4
Topic topic = (Topic)ctx.lookup("Alarms"); 5
TopicConnection topicConn = 6
topicConnectionFactory.createTopicConnection(); 7
TopicSession topicSess = topicConn.createTopicSession(false, 8
Session.AUTO_ACKNOWLEDGE); 9
TopicSubscriber topicSub = topicSess.createSubscriber(topic); 10
topicSub.start(); 11
TextMessage msg = (TextMessage) topicSub.receive(); 12
return msg.getText(); 13
} catch (Exception e) { 14
return null; 15
}16
} Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
27

Figure 6.20
The tuple space abstraction

29

Figure 6.21 (1)
Replication and the tuple space operations [Xu and Liskov 1989]

write
1. The requesting site multicasts the write request to all members of the view; 2.
On receiving this request, members insert the tuple into their replica and
acknowledge this action;
3. Step 1 is repeated until all acknowledgements are received.

read
1. The requesting site multicasts the read request to all members of the view;
2. On receiving this request, a member returns a matching tuple to the requestor;
3. The requestor returns the first matching tuple received as the result of the operation (ignoring others); 4
Step 1 is repeated until at least one response is received.

continued on next slide

30

Figure 6.21 (continued)
Replication and the tuple space operations [Xu and Liskov 1989]

take Phase 1: Selecting the tuple to be removed
1. The requesting site multicasts the take request to all members of the view;
2. On receiving this request, each replica acquires a lock on the associated tuple set and, if the lock cannot
be acquired, the take request is rejected;
3. All accepting members reply with the set of all matching tuples;
4. Step 1 is repeated until all sites have accepted the request and responded with their set of tuples and the
intersection is non-null;
5. A particular tuple is selected as the result of the operation (selected randomly from the intersection of all
the replies);
6. If only a minority accept the request, this minority are asked to release their locks and phase 1 repeats.

Phase 2: Removing the selected tuple
1. The requesting site multicasts a remove request to all members of the view citing the tuple to be
removed;
2. On receiving this request, members remove the tuple from their replica, send an acknowledgement

and release the lock;
3. Step 1 is repeated until all acknowledgements are received.
31

Figure 6.22
Partitioning in the York Linda Kernel

32

Figure 6.23
The JavaSpaces API

33

Figure 6.24
Java class AlarmTupleJS

import net.jini.core.entry.*;
public class AlarmTupleJS implements Entry {
public String alarmType;
public AlarmTupleJS() { }
}
public AlarmTupleJS(String alarmType) {
this.alarmType = alarmType;}
}
}

34

Figure 6.25
Java class FireAlarmJS

import net.jini.space.JavaSpace;
public class FireAlarmJS {
try {
JavaSpace space = SpaceAccessor.findSpace("AlarmSpace");
AlarmTupleJS tuple = new AlarmTupleJS("Fire!");
space.write(tuple, null, 60*60*1000);
catch (Exception e) {
}
}
}

35

Figure 16.26
Java class FireAlarmReceiverJS

import net.jini.space.JavaSpace;
public class FireAlarmConsumerJS {
try {
JavaSpace space = SpaceAccessor.findSpace();
AlarmTupleJS template = new AlarmTupleJS("Fire!");
AlarmTupleJS recvd = (AlarmTupleJS) space.read(template, null,
Long.MAX_VALUE);
return recvd.alarmType;
}
catch (Exception e) {
return null;
}
}
}

36

Figure 6.27
Summary of indirect communication styles

37

Chapter 6 slides

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Chapter 6 slides (20)

Chapter 6 slides