Distributed Systems CSE

Fault Tolerance

1. Faults & Fault Tolerance

2. Features of Fault Tolerance

3. Types of Fault Tolerance

4. Classification of Failures

5. Failure masking by Redundancy

Issues

FAULT: It is an incorrect internal state in system

 Ex: database slowdown, memory leak, blocked thread, bad data etc.

FAILURE: Inability of the system to do its intended job

Fault tolerance is the property that enables the system to continue operating properly in the event of
failure of some of components.

 Being fault tolerant is strongly related to the dependable systems

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE
KEY FEATURES

1. Availability

2. Reliability

3. Safety

4. Maintainability

Availability: Availability is defined as the property that a system is ready to be used immediately

 A high available system is one that will most likely be working at an given instance of
time(even after failure)

Reliability:

 Refers to property that a system can run continuously without failure

 A highly reliable system is one that will most likely continue work without an interruption

 Ex: If a system goes down on millisecond every one hour then the system is 99.99% available
but it is highly unreliable

Safety:

 Refers to that situation that when a system temporarily fail, to operate correctly, nothing
bad/catastrophic/ dangerous happens

 Ex: Sending people into space requires a high degree of safety, if such control system
temporarily fail for only a very brief moment the effect will be disastrous

Maintainability:

 Refers to how easy a failed system can be repaired

TYPES OF FAULTS

1. Transient Faults
2. Intermittent Faults
3. Permanent Faults
4. Processor Faults

Transient Faults

 Transient faults occurs once and disappear

 Ex: a bird flying through a beam of a microwave transmitter may cause loss of bits

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE

Intermittent Faults

 Fault occur, then variables of its own occurred, then reappear and so on

Ex: Lose connections

Permanent Faults

 Continue to exist until the fault component is replaced

 Ex: Burnt-out chips

Processor Faults (System Failures)

 Fail silent faults: Faulty processor just stops and doesn’t respond at all

 Byzantine faults: Faulty processor continues to run, issuing in the wrong answers/maliciously

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3

Distributed Systems CSE

CLASSIFICATION OF FAILURE MODELS

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 4

Distributed Systems CSE

FAILURE MASKING BY REDUNDANCY

Strategy: hide the occurrence of failure from other processes

using redundancy. Three main types:

 Information Redundancy – add extra bits to allow for error detection/recovery (e.g.,
Hamming codes and the like).

 Time Redundancy – perform operation and, if needs be, perform it again. Think about how
transactions work.

(e.g. Atomic Transaction) (BEGIN/END/COMMIT/ABORT).

 Physical Redundancy – add extra (duplicate) hardware and/or software to the system.

E.g.: Addition of Extra Processors .

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 5

Distributed Systems CSE
1. Process Resilience

2. Flat vs Hierarchical Groups

3. Agreement In Faulty Systems

• Byzantine Agreement

4. Failure Detection

FAULT: It is an incorrect internal state in system

 Ex: database slowdown, memory leak, blocked thread, bad data etc.

FAILURE: Inability of the system to do its intended job

PROCESS RESILIENCE is about preventing faults turning into failure

 Processes can be made fault tolerant by arranging to have a group of processes, with each
member of the group being identical.

 A message sent to the group is delivered to all of the “copies” of the process (the group
members), and then only one of them performs the required service.

 If one of the processes fail, it is assumed that one of the others will still be able to
function (and service any pending request or operation).

Flat vs Hierarchical Groups

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE

AGREEMENT IN FAULTY SYSTEMS

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
BYZANTINE AGREEMENT PROBLEM

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3

Distributed Systems CSE

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 4

Distributed Systems CSE

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 5

Distributed Systems CSE

FAILURE DETECTION

 Failure detection is one of the cornerstones of fault tolerance in distributed systems.

 What it all boils down to is that for a group of processes, non faulty members should be able
to decide who is still a member, and who is not. In other words, we need to be able to detect
when a member has failed.

 When it comes to detecting process failures, there are essentially only two mechanisms

 i)Either processes actively send "are you alive?" messages to each other (for which they
obviously expect an answer) (usually followed)

 ii) or passively waits until message come in from different process(practically this idea seems
to be good not used as if some process is not sending any message hence we cannot say its
dead)

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 6

Distributed Systems CSE
RELIABLE CLIENT SERVER COMMUNICATION

 In addition to process failures, a communication channel may exhibit

crash,omission,timing,and/or arbitrary failure

POINT TO POINT COMMUNICATION

 In many distributed systems reliable point to point communication is established by making

use of reliable transport protocol such as TCP

 TCP masks omission failure, which occur in the form of last messages, by using
acknowledgment and re-transmission(which are completely hidden from user).

 How ever crash failures are not masked .It occurs when connection breaks, Here the client
informed that crash happened due to this reason

 One way to mask this is to re-connect/re-establish connection automatically from server side

RPC Semantic in presence of failure

 The goal of RPC is to hide communication by making remote procedure call, just like local ones
with few exceptions when server/client gets an issue

FEW FAILURES

 The client is unable to locate the server

 The request message from client to the server is lost

 The server crashes after receiving the request

 The reply message form server to client is lost

 The client crashes after sending request

i)The client is unable to locate the server:

 Assume the server is down and client is requesting for the website then instead of loading
infinitely. We show an exception stating that page cannot be reached(currently in use today)

ii) LOST REQUEST MESSAGE:

 So with the concept of ack and timer we solve this lost request message

 Whenever a client request for something, it will start a timer and if did not got any reply/ack it
will re-transmit again

 Advantage: Server will never know that packets are re-transmitted

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE

iii) SERVER CRASHES

 In server side we have 3 cases i.e., 1 success and 2 crash cases

 Here depending on case of crash the operation in that server should do will depend

 In case i) As the execution is done successfully by server then just re-sending ack/reply will be
enough

 In case ii) here as execution is not done hence need to request again, based on this the client
cannot identify requirements, Hence to avoid these confusions we divide process into three
different events and based on the order we decide what append

1. send the completion message (M)

2. print the text (P).

3. crash (C).

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
 These events can occur in six different orderings:

1. M ~P ~C: A crash occurs after sending the completion message and printing the text.

2. M ~C (~P): A crash happens after sending the completion message, but before the text could
be printed.

3. p ~M ~C: A crash occurs after sending the completion message and printing the text.

4. P~C( ~M): The text printed, after which a crash occurs before the completion message could
be sent.

5. C (~P ~M): A crash happens before the server could do anything.

6. C(~M ~P): A crash happens before the server could do anything.

iv)LOST REPLY MESSAGES

 Lost replies can also be difficult to deal with.

 The obvious solution is just to rely on a timer again that has been set by the client's operating
system. If no reply is forthcoming within a reasonable period, just send the request once
more.

v)CLIENT CRASHES

 What happens if a client sends a request to a server to do some work and crashes before the
server replies? At this point a computation is active and no parent is waiting for the result.
Such an unwanted computation is called an orphan.

 Orphans can cause a variety of problems creating load on systems/server/waiting CPU cycles

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3

Distributed Systems CSE
Reliable Group Communication

 Reliable multicast services guarantee that all messages are delivered to all members of a
process group.

 The idea is simple but is become more and more tricky as no of clients/systems increases

 This is a simple solution to reliable multicasting when all receivers are known and are assumed
not to fail. The sending process assigns a sequence number to outgoing messages (making it
easy to spot when a message is missing).

 Message transmission – note that the third receiver is expecting 24.

 Reporting feedback – the third receiver informs the sender.

Scalability in Reliable Multicasting

 The main problem with the reliable multicast scheme just described is that it cannot support
large number of receivers.

 If there are N receivers, the sender must be prepared to accept at least N acknowledgments.

 With many receivers, the sender may be swamped with such feedback messages, which is also
referred to as a feedback implosion.

 One solution to this problem is not to have receivers acknowledge the receipt of a message

 Instead, a receiver returns a feedback message only to inform the sender it is missing a
message.

Non-hierarchical Feedback Control

 Feedback Suppression – reducing the number of feedback messages to the sender (as
implemented in the Scalable Reliable Multicasting Protocol).

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE

 Hierarchical reliable multicasting is another solution, the main characteristic being that it
supports the creation of very large groups.

 Sub-groups within the entire group are created, with each local coordinator forwarding
messages to its children.

 A local coordinator handles retransmission requests locally, using any appropriate multicasting
method for small groups.

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
Distributed COMMIT and RECOVERY

Distributed COMMIT(SAVING)

 General Goal: We want an operation to be performed by all group members or none at all.

 There are three types of “commit protocol”:

 1.single-phase commit

 2. two-phase commit

 3. three-phase commit.

Commit Protocols

1. One-Phase Commit Protocol:

 An elected coordinator tells all the other processes to perform the operation in question.

 But if a process cannot perform operation? There is no way to tell

 Hence one phase protocol commit cannot be used

2. The Two-Phase Commit Protocol

 First developed in 1978!!!

 Summarized: GET READY, OK, GO AHEAD.

 The coordinator sends a VOTE_REQUEST message to all group members.

 The group member returns VOTE_COMMIT if it can commit locally, otherwise

VOTE_ABORT.

 All votes are collected by the coordinator. A GLOBAL_COMMIT is sent if all the group
members voted to commit. If one group member voted to abort, a GLOBAL_ABORT is
sent.

 The group members then COMMIT or ABORT based on the last message received from
the coordinator.

Two-Phase Commit Finite State Machines

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE
a) The finite state machine for the coordinator.

b) The finite state machine for a participant (group member).

Big Problem with Two-Phase Commit

 It can lead to both the coordinator and the group members blocking, which may lead to the
dreaded deadlock.

 If the coordinator crashes, the group members may not be able to reach a final decision,
and they may, therefore, block until the coordinator recovers …

 Two-Phase Commit is known as a blocking-commit protocol for this reason.

 The solution? The Three-Phase Commit Protocol.

3. Three-Phase Commit Protocol

a) Finite state machine for the coordinator.

b) Finite state machine for a group member.

c) Main point: although 3PC is generally regarded as better than 2PC, it is not applied often in
practice, as the conditions under which 2PC blocks rarely occur.

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
RECOVERY STRATEGIES

 Once a failure has occurred , it is essential that the process where the failure happened to
recover to correct state

 Recover from an error is fundamental to fault tolerance

Two forms of recovery

 1.Backward recovery: Return the system to some previous correct

state(using check points, then continue executing)

 2.Forward Recovery: Bring a system into correct state, from which it can then continue to
execute

Major Disadvantages of backward recovery:

 1.Checkpoint can be very expensive(especially when errors are very rare)

Major Disadvantages of forward recovery:

 In order to work, all potential errors need to be accounted for up front

 When an error occurs, the recovery mechanism then knows what to do bring the system
forward to a correct state

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3

Distributed Systems CSE
Distributed Object-Based Systems

– CORBA

– DCOM

– GLOBE

CORBA

CORBA: Common Object Request Broker Architecture

Background:

• Developed by the Object Management Group (OMG) in response to industrial demands for
object- based middleware

• Currently in version #2.4 with #3 (almost) done

• CORBA is a specification: different implementations of CORBA exist

• Very much the work of a committee: there are over 800 members of the OMG and many of
them have a say in what CORBA should look like.

Essence: CORBA provides a simple distributed-object model, with specifications for many supporting
services it may be here to stay (for a couple of years)

CORBA Overview

Object Request Broker (ORB): CORBA’s object broker that connects clients, objects, and services

Proxy/Skeleton: Precompiled code that takes care of (un)marshaling invocations and results.

Dynamic Invocation/Skeleton Interface (DII/DSI): To allow clients to “construct” invocation

requests at runtime instead of calling methods at a proxy, and having the server-side “reconstruct”
those request into regular method invocations.

Object adapter: Server-side code that handles incoming invocation requests.

• Interface repository: Database containing interface definitions and which can be queried at
runtime
• Implementation repository: Database containing the implementation (code, and possibly also
state) of objects. Effectively: a server that can launch object servers.
SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1
Distributed Systems CSE
CORBA Object Model
Essence: CORBA has a “traditional” remote-object model in which an object residing at an object
server is remote accessible through proxies
Observation: All CORBA specifications are given by means of interface descriptions, expressed in an
IDL(Interface Definition Language). CORBA follows an interface-based approach to ob- jects:
• Not the objects, but interfaces are the really important entities
• An object may implement one or more interfaces
• Interface descriptions can be stored in an interface repository, and looked up at runtime
• Mappings from IDL to specific programming are part of the CORBA specification (languages
include C, C++, Smalltalk, Cobol, Ada, and Java.

CORBA Services
Service Description
Collection Facilities for grouping objects into lists, queue, sets, etc.
Query
Facilities for querying collections of objects in a declarative manner

Concurrency Facilities to allow concurrent access to shared objects

Transaction
Flat and nested transactions on method calls over multiple objects

Event
Facilities for asynchronous communication through
events
Notification
Advanced facilities for event-based asynchronous communication

Externalization Facilities for marshaling and unmarshaling of objects

Life cycle
Facilities for creation, deletion, copying, and moving of objects

Licensing Facilities for attaching a license to an object

Naming Facilities for system wide naming of objects
Property
Facilities for associating (attribute, value) pairs with ob- jects

Trading
Facilities to publish and find the services an object has to offer

Persistence Facilities for persistently storing objects

Relationship Facilities for expressing relationships between objects
Security
Mechanisms for secure channels, authorization, and auditing

Time Provides the current time within specified error margins

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
CORBA Communication Model & Interoperable Object References

Communication Models

Object invocations: CORBA distinguishes three different forms of direct invocations:

Request type Failure sem. Description

Synchronous Atmost-once Caller blocks
One-way Unreliable Nonblocking call

Deferred Atmost-once Nonblocking, but can pick up

synchronous results later

Event communication: There are also additional fa- cilities by means of event channels:

Messaging facilities: reliable asynchronous and persistent method invocations:

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE
Processes

Interceptors: A user written object that allows functionality to be inserted into CORBA. Adds security
& monitors components.

Request-level: Allows you to modify invocation semantics (e.g., multicasting)

Message-level: Allows you to control message-passing between client and server (e.g., handle
reliability and fragmentation)

Naming

Important: In CORBA, it is essential to distinguish specification-level and implementation-level object

references

Specification level: An object reference is considered to be the same as a proxy for the referenced
object having an object reference means you can directly invoke methods; there is no separate client-
to-object binding phase

Implementation level: When a client gets an object reference, the implementation ensures that, one
way or the other, a proxy for the referenced object is placed in the client’s address space:

Conclusion: Object references in CORBA used to be highly implementation dependent: different

implementations of CORBA could normally not exchange their references.

Naming Service

Essence: CORBA’s naming service allows servers to associate a name to an object reference, and have
clients subsequently bind to that object by resolving its name

Observation: In most CORBA implementations, ob- ject references denote servers at specific hosts;
nam- ing makes it easier to relocate objects

Observation: In the naming graph all nodes are ob- jects; there are no restrictions to binding names to
ob- jects CORBA allows arbitrary naming graphs

Question: How do you imagine cyclic name resolu- tion stops?

Observation: There is no single root; an initial con- text node is returned through a special call to the
ORB. Also: the naming service can operate across different ORBs interoperable naming service

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
Interoperable Object References

Observation1: Recognizing that object references are implementation dependent, we need a separate
referencing mechanism to cross ORB boundaries

Solution: Object references passed from one ORB to another are transformed by the bridge through
which they pass (different transformation schemes can be implemented)

Observation2: Passing an object reference from ORB A to ORB B circumventing the A-to-B bridge may
be useless if ORB B doesn’t understand

Observation: To allow all kinds of different systems to communicate, we standardize the reference
that is passed between bridges:

Fault Tolerance

Essence: Mask failures through replication, by putting objects into object groups. Object groups are
transparent to clients: they appear as “normal” objects. This approach requires a separate type of
object reference: Interoperable Object Group Reference:

IOGRs have the same structure as IORs; the main difference is that they are used differently. In IORs
an additional profile is used as an alternative; in IOGR, it denotes another replica.
SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3
Distributed Systems CSE
Security

Essence: Allow the client and object to be mostly unaware of all the security policies, except perhaps
at binding time; the ORB does the rest. Specific policies are passed to the ORB as (local) objects and
are invoked when necessary:

Examples: Type of message protection, lists of trusted parties.

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 4

Distributed Systems CSE
Distributed COM

DCOM: Distributed Component Object Model

• Microsoft’s solution to establishing inter-process communication, possibly across machine

boundaries.

• Supports a primitive notion of distributed objects

• Evolved from early Windows versions to current NT-based systems (including Windows 2000)

• Comparable to CORBA’s object request broker

DCOM Overview

DCOM is related to many things that have been introduced by Microsoft in the past couple of years:

Adds facilities to communicate across process and machine boundaries.

SCM: Service Control Manager, responsible for activating objects (cf., to CORBA’s implementation
repository).

Proxy marshaler: handles the way that object references are passed between different machines

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE
COM Object Model

1. An interface is a collection of semantically related operations

2. Each interface is typed, and therefore has a globally unique interface identifier

3. A client always requests an implementation of an interface:

– Locate a class that implements the interface

– Instantiate that class, i.e., create an object

– Throw the object away when the client is done

DCOM Services

CORBA DCOM/COM+ Windows 2000

Collection ActiveX Data Objects –
Query None –
Concurrency Thread concurrency –
Transaction COM+ Automatic DistributedTransaction
Transactions Coordinator
Event COM+ Events –
Notification COM+ Events –
Externalization Marshaling utilities –
Life cycle Class factories, JIT –
activation

Licensing Special class factories –

Naming Monikers Active Directory

Property None Active Directory
Trading None Active Directory
Persistence Structured storage Database access
Relationship None Database access
Security Authorization SSL, Kerberos
Time None None

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 2

Distributed Systems CSE
Communication Models

Object invocations: Synchronous remote method calls with at-most-once semantics. Asynchronous
invocations are supported through a polling model, as in CORBA.

Event communication: Similar to CORBA’s push style model:

Messaging: Completely analogous to CORBA messaging.

Processes: Passing Object References

Observation: Objects are referenced by means of a local interface pointer. The question is how such
pointers can be passed between different machines:

Naming: Monikers

Observation: DCOM can handle only objects as temporary instances of a class. To accommodate
objects that can outlive their client, something else is needed.

Moniker: A hack to support real objects

1. A moniker associates data (e.g., a file), with an application or program

2. Monikers can be stored

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 3
Distributed Systems CSE
3. A moniker can contain a binding protocol, specifying how the associated program should be
“launched” with respect to the data.

1 Client Calls BindMoniker at moniker

2 Moniker Lookup CLSID and tell SCM to create object
3 SCM Loads class object
4 Class object Creates object, returns int. pointer
5 Moniker Instructs object to load previously stored state
6 Object Loads its state from file
7 Moniker Returns interface pointer of object to client

Active Directory

Essence: a worldwide distributed directory service, but one that does not provide location
transparency.

Basics: Associate a directory service (called domain controller) with each domain; look up the
controller using a normal DNS query:

Controller is implemented as an LDAP server

Fault Tolerance

Automatic transactions: Each class object (from which objects are created), has a transaction attribute
that determines how its objects behave as part of a transaction:

Attr. value Description

REQUIRES NEW A new transaction is always started at each invocation
REQUIRED A new transaction is started if not already done so

SUPPORTED Join a transaction only if caller is already part of one

NOT SUPPORTED Never join a transaction (no transaction support)

DISABLED Never join a transaction, even if told to do so
Transactions are essentially executed at the level of a method invocation.
SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 4
Distributed Systems CSE
Security

Declarative security: Register per object what the system should enforce with respect to
authentication. Authentication is associated with users and user groups. There are different
authentication levels:

Auth. level Description

NONE No authentication is required

CONNECT Authenticate client when first connected to server

CALL Authenticate client at each invocation

PACKET Authenticate all data packets

PACKET INTEGRITY Authenticate data packets and do integrity check

PACKET PRIVACY Authenticate, integrity-check, and encrypt data packets

Delegation: A server can impersonate a client depending on a level:

Impersonation Description

ANONYMOUS The client is completely anonymous to the server

IDENTIFY The server knows the client and can do access control
checks

IMPERSONATE The server can invoke local objects on behalf of the client

DELEGATE The server can invoke remote objects on behalf of the

client

There is also support for programmatic security by which security levels can be set by an application,
as well as the required security services.

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 5

Distributed Systems CSE
Globe

1. Unique for its focus on scalability by means of truly distributed objects.

2. Prototype version up and running across multiple machines distributed in various networks.

Object Model

Essence: A Globe object is a physically distributed shared object: The object’s state may be physically
distributed across several machines.

Local object: A non-distributed object residing a single address space, often representing a
distributed shared object

Contact point: A point where clients can contact the distributed object; each contact point is
described through a contact address

Observation: Globe attempts to separate functionality from distribution by distinguishing different

local sub objects

Control subobject: Connects the user-defined inter- faces of the semantics subobject to the generic,
predefined interfaces of the replication subobject

Replication subobject: Contains the implementation of an object-specific consistency protocol that

controls exactly when a method on the semantics subobject may be invoked

Semantics subobject: Contains the methods that im-plements the functionality of the distributed
shared object

Communication subobject: Provides a (relatively simple), network-independent interface for

communication between local objects

Client-to-Object Binding

Observation: Globe’s contact addresses correspond to CORBA’s object references

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 1

Distributed Systems CSE

Globe Services

Service Possible implementation Av?

Collection Separate object that holds references to other objects No

Concurren Each object implements its own concurrency No

cy control strategy
Transactio Separate object representing a transaction No
n manager
Event/Notif Separate object per group of events (as No
. in DCOM)
Externaliza Each object implements its own marshaling Yes
tion routines
Life cycle Separate class objects combined with object Yes
implementations
Licensing Implemented by each object separately No

Naming Separate service, implemented by a collection of naming Yes

objects
Property Separate service, implemented by a collection of directory No
objects
Persistenc Implemented on a object basis Yes
e
Security Implemented per object, combined with (local) security Yes
services
Replication
SUTHOJU Implemented
GIRIJA RANI, on a object
Assistant Professor, basis
CSE, NGIT 2 Yes
Distributed Systems CSE

Fault Implemented object combined with fault-tolerant servers Yes

tolerance

Object References

Essence: Globe uses location-independent object handles which are to be resolved to contact
addresses (which describes where and how an object can be contacted):

Associated with a contact point of the distributed object

Specifies (for example) a transport-level network address to which the object will listen

Contains an implementation handle, specifying exactly what the client should implement if it wants to
communicate through the contact point:

– “slave/master-slave/tcp/ip”

Observation: Objects in Globe have their own object-specific implementations; there is no “standard”
proxy that is implemented for all clients

Naming Objects

Observation1: Globe separates naming from locating objects. The current naming service is based on
DNS, using TXT records for storing object handles

Observation2: The location service is implemented as a generic, hierarchical tree

Caching and Replication

Observation: Here’s where Globe differs from many other systems:

Description
Called to synchronize replicas of the semantics subobjects, obtain locks if
necessary, etc.
Provide marshaled arguments of a specific method, and pass invocation to local
objects in other address spaces

Called after the control subobject has invoked a specific method at the
semantics subobject

The organization of a local object is such that replication is inherently part of each distributed shared
object GIRIJA RANI, Assistant Professor, CSE, NGIT
SUTHOJU 3
Distributed Systems CSE
All replication subobjects have the same interface:

This approach allows to implement any object- specific caching/replication strategy

Security

Essence: Additional security subobject checks for authorized communication, invocation, and
parameter values.

Globe can be integrated with existing security services:

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 4

Distributed Systems CSE

Comparison

Issue CORBA DCOM Globe

Design goals Interoperability Functionality Scalability
Object model Remote objects Remote objects Distributed objects
Services Many of its own From environment Few
Interfaces IDL based Binary Binary
Sync. communication Yes Yes Yes
Async. communication Yes Yes No
Callbacks Yes Yes No
Events Yes Yes No
Messaging Yes Yes No
Object server Flexible (POA) Hard-coded Object dependent
Directory service Yes Yes No
Trading service Yes No No
Naming service Yes Yes Yes
Location service No No Yes
Object reference Object’s location Interface pointer True identifier
Synchronization Transactions Transactions Only intra-object
Replication support Separate server None Separate
subobject
Transactions Yes Yes No
Fault tolerance By replication By transactions By replication
Recovery support Yes By transactions No

SUTHOJU GIRIJA RANI, Assistant Professor, CSE, NGIT 5