S.NO
NAME OF TOPIC
PAGE
NO.
1
Destination based routing
2-3
2
Deadlock free Packet switching
4
3
Introduction to Wave & traversal
5-6
algorithms
4
5
7-8
Election algorithm
CORBA Case Study: CORBA, CORBA
services
1
9-11
UNIT-5
Destination Based Routing
Destination-based routing builds the "route" from the destination backwards to
the source. Destination-based routing is the typical, most common type of
routing.For this, each message that we send contains the address of the
destination and the forwarding decision process makes its forwarding decision
solemnly based on this address (and independent of the original sender).
I.e. we don't care about who sent the message, only about where it is supposed to
go.So, when constructing a routes, one thing we can do is root a spanning tree at
the destination.This creates a path from all possible sources to that destination.
This is called a "sink tree".
2
3
Deadlock-free Packet Switching
Messages (packets) traveling through a packet-switched communication net-work must be
stored at each node before being forwarded to the next node on the path to their
destination.Each node of the network reserves some buffer space for this purpose. As the
amount of buffer space is finite in each node, situations may occur where no packet can be
forwarded because all buffers in the next node are occupied, as illustrated by Figure.Each of
the four nodes has B buffers, each capable of containing exactly one packet. Node s has sent
B packets with destination v to t, and node v has sent B packets with destination s to u.
All buffers in u and v are now occupied, and consequently none of the packets stored in t and
u can be forwarded towards its destination.Situations where a group of packets can never
reach their destination because they are all waiting for the use of a buffer currently occupied
by another packet in the group are referred to as store-and-forward deadlocks.
The packet switching controller has the following requirements:
1.The consumption of a packet (at its destination) is always allowed.
2. The generation of a packet in a node where all buffers are empty is always allowed.
3.The controller uses only local information, that is, whether a packet can be accepted in a
node packet can be accepted in a node u depends only information known to u or contained
in the packet.
4
Wave and Traversal Algorithms
Wave AlgorithmA wave algorithm is a distributed algorithm that satisfies the following three requirements:
Termination: Each computation is finite. A wave algorithm is a distributed algorithm that
satisfies the following three requirements:
Termination:Each computation is finite
Decision:Each computation contains at least one decide event
Dependence:In each computation each decide event is causally preceded by an event in each
process
Decision: Each computation contains at least one decide event
Dependence: In each computation each decide event is causally preceded by an event in each
process.
The Echo Algorithm - a wave algorithm
Var recp
: integer
init 0;
// Counts no of recvd mesgs father p
: process in it udef;
For the initiator
begin forall q
∈ Neigh p do send ⟨to k⟩ to q ;
while recp< #Neigh p do
begin receive ⟨tok⟩ ; recp= recp+ 1 end ;Decide
end
5
For non—initiators
begin receive ⟨tok⟩ from neighbor q ; fatherp= q ; recp= recp+ 1 ;
for all q ∈ Neigh p, q ≠father p do send ⟨tok⟩ to q ;
while recp < #Neigh p do
begin receive ⟨tok⟩ ; recp= recp+ 1 end ;
send ⟨tok⟩to father
end
Traversal Algorithms –
A traversal algorithm is an algorithm with the following three properties:
 In each computation there is one initiator, which starts the algorithm by sending out
exactly one message
 A process, upon receipt of a message, either sends out one message or decides
 The algorithm terminates in the initiator and when this happens, each process has sent
a message at least once
A traversal algorithm is a systematic procedure for exploring a graph by examining all of its
vertices and edges.Traversal algorithms are typically used to explore unknown graphs and
build a map as the graph is visited.
6
Election Algorithm
• Any process can serve as coordinator
• Any process can “call an election” (initiate the algorithm to choose a new coordinator).
.There is no harm (other than extra message traffic) in having multiple concurrent
elections.
•
Elections may be needed when the system is initialized, or if the coordinator crashes or
retires.
The leader election abstraction consists in choosing one process to be selected as a unique
representative of the group of processes in the system.For this abstraction to be useful in a
distributed setting, a new leader should be elected if the current leader crashes. Such
abstraction is in case indeed useful in a primary-backup replication scheme for
instance.Following this scheme, a set of replica processes coordinate their activities to
provide the illusion of a unique fault-tolerant (highly-available) service.Among the set of
replica processes, one is chosen as the leader. This leader process, sometimes called the
primary, is supposed to treat the requests submitted by the client processes, on behalf of the
other replicas, called backups.Before a leader returns a reply to a given client, it updates its
backups to keep them up to date.If the leader crashes, one of the backups is elected as the
new leader, i.e., the new primary.
Interface and properties of leader election
Module:
Name: LeaderElection (le).
Events:
Indication: pi: Used to indicate that process pi is now the leader.
Properties:
LE1: Either there is no correct process, or some correct process is eventually the leader.
LE2: If a process pi is leader, then all other leaders have crashed.
The first property ensures the eventful presence of a correct leader.
The property ensures unless there is no correct process, some correct process is eventually
elected leader.The second property ensures the stability of the leader.It ensures that the only
reason to change the leader is if it crashes.
7
BULLY ALGORITHM
When a process notices that the coordinator is no longer responding to requests, it initiates
an election. A process, P, holds an election as follows:
1. P sends an ELECTION message to all processes with higher numbers
2. If no one responds, P wins the election and becomes coordinator
3. If one of the higher-ups answers, it takes over. P's job is done
If a process can get an ELECTION message from one of its lower-numbered
colleagues. message arrives => the receiver sends an OK message back to the sender to
indicate that he is alive and will take over.
The receiver then holds an election, unless it is already holding one. Eventually, all processes
give up but one, and that one is the new
coordinator. It announces its victory by sending all processes a message telling them that
starting immediately it is the new coordinator. If a process that was previously down comes
back up, it holds an election.If it happens to be the highest-numbered process currently
running, it will win the election and take over the coordinator's job.
Thus the biggest guy in town always wins, hence the name "bully algorithm."
RING ALGORITHM
„
Based on the use of a ring.
Assume: the processes are physically or logically ordered, so that each process
knows who its successor is. When any process notices that the coordina
tor is not functioning, it builds an ELECTION message containing its own process number
and sends the message to its successor.
If the successor is down, the sender skips over the successor and goes to the next member
along the ring, or the one after that, until a running process is located.
At each step, the sender adds its own process number to the list in the message.
Eventually, the message gets back to the process that started it all.
That process recognizes this event when it receives an incoming message containing its own
process number. At that point, the message type is changed to COORDINATOR and
circulated once again, this time to inform everyone else who the coordinator is (the list
member with the highest number) and who the members of the new ring are.
When this message has circulated once, everyone goes back to work.
8
CORBA
The Common Object Request Broker Architecture (CORBA) is a standard developed by the
Object Management Group (OMG) to provide interoperability among distributed objects.
CORBA is the world's leading middleware solution enabling the exchange of information,
independent of hardware platforms, programming languages, and operating systems.CORBA
is essentially a design specification for an Object Request Broker (ORB), where an ORB
provides the mechanism required for distributed objects to communicate with one another,
whether locally or on remote devices, written in different languages, or at different locations
on a network.The CORBA Interface Definition Language, or IDL, allows the development of
language and location-independent interfaces to distributed objects. Using CORBA,
application components can communicate with one another no matter where they are
located, or who has designed them. CORBA provides the location transparency to be able to
execute these applications.CORBA is often described as a "software bus" because it is a
software-based communications interface through which objects are located and accessed.
The illustration below identifies the primary components seen within a CORBA
implementation.
Data communication from client to server is
accomplished through a well-defined object-oriented interface. The Object Request Broker
(ORB) determines the location of the target object, sends a request to that object, and returns
any response back to the caller.
9
The basic steps for CORBA development include:
Create the IDL to Define the Application Interfaces
The IDL provides the operating system and programming language independent interfaces to
all services and components that are linked to the ORB.
Translate the IDL
An IDL translator typically generates two cooperative parts for the client and server
implementation, stub code and skeleton code.
Compile the Interface Files
Once the IDL is translated into the appropriate language, C++ in this example, these interface
files are compiled and prepared for the object implementation.
Complete the Implementation
If the implementation classes are incomplete, the spec and header files and complete bodies
and definitions need to be modified before passing through to be compiled. The output is a
complete client/server implementation.
Compile the Implementation
Once the implementation class is complete, the client interfaces are ready to be used in the
client application and can be immediately incorporated into the client process.
Link the Application
Once all the object code from steps three and five have been compiled, the object
implementation classes need to be linked to the C++ linker.
Run the Client and Server
The development process is now complete and the client will now communicate with the
server. The server uses the object implementation classes allowing it to communicate with
the objects created by the client requests.
There are several CORBA services. Here is a one line description of most of the services:
10
Corba Services
Service
Object life cycle
Naming
Events
Relationships
Externalization
Transactions
Concurrency Control
Property
Trader
Query
Description
defines how CORBA objects are created, removed,
moved, and copied
defines how CORBA objects can have friendly
symbolic names
decouples the communication between
distributed objects
provides arbitrary typed n-ary relationships
between CORBA objects
coordinates the transformation of CORBA objects
to and from external media
coordinates atomic access to CORBA objects
provides a locking service for CORBA objects in
order to ensure serializable access
supports the association of name-value pairs with
CORBA objects
supports the finding of CORBA objects based on
properties describing the service offered by the
object
supports queries on objects
11