Introduction to Distributed System
You will find about Distribute agreement: CORBA. Agreement Protocol, fault, failure & recovery, replicated data management & transparency.
Table of Contents
CORBA (Common Object Request Broker Architecture)
Corba is a standard defined by OMG (Object Management Group)
It enables software component to work together.
Software component may be written-in/running-on different languages/computers.
CORBA defines single application with set of services.
CORBA is composed of five major components
1. ORB (Object Request Broker): software that implements CORBA Specification.
2. IDL (Interface defination language): defines the types of objects by defining there interface (consist of set of named operations with their parameters).
3. Dynamic Invocation Interface: make invocation on CORBA object by dynamically constructing requests to obtain instance of CORBA object.
4. Interface Repository: specify interface to object which enable client to locate an object that is unknown at compile time.
5. Object Adapters: object implementation accesses services provided by ORB.
1. Naming: allow CORBA object to located by name.
2. Trading: allow CORBA object to located by attribute.
3. Event: allow objects to communicate notifications to subscribers.
5. Security: authentication, access control & auditing.
6. Transaction & Concurrency Control: allow CORBA objects for flat or nested transactions.
7. Persistent Object
1. CORBA Object Model: implements an IDL interface & implemented by langugage that is not object oriented.
2. CORBA IDL: IDL
Concept of fault, failure & Recovery
failure: when system: deviates from its specified behaviour or does not meet its requirements.
A single fault may result in multiple errors & a single error may lead to multiple failures.
error repersent invalid system state & result of fault.
fault repersent root cause of failure.
In software system, an incorrect instruction in a program may cause failure.
like decrement a value instead of incrementing & value is also used in other program => whole system deviate from its desired behaviour.
In this case incorrect instruction is fault, invalid value is error & behaviour of system is failure.
Based on duration
Transient fault disappear without any apparent intervention. Permanent fault need to remove externally.
Based on behaviour
Crash fault: either completely stops or never return to invalid state.
Omission fault: completely fails to perform its service.
Timing fault: does not complete service on time.
Byzantine fault: fault of an arbitary nature. many security attacks such as censorship, freeloading & data corruption.
Protected using BFT (Byzantine fault tolerance) Technique mask a bounded number of Byzantine faults.
Alternative approach is detecting rather than masking faulty behaviour.
Important to recover crtical processes to a known state in order to resume processing.
Recovery Approach: Backward & forward
Backward use checkpointing to record system state.
Forward bring system to new stable stable from which it is possible to proceed.
For sites to achieve a common goal, it required sites to reach a mutual agreement.
Reaching an agreement require sites have knowledge of values of other sites.
if system is free from failures, an agreement can easily reached among processor.
but when system is prone to failure processor must exchange their values with other & broadcast several times to isolate effect of faulty processor.
process for reaching an agreement is called an agreement protocol.
- n processor is system & at most m can be faulty.
- processors can directly communicate by message passing.
- receiver knows identity of sender
- reliable communication
Agreement Problems: Byzantine, Consensus & Interactive consistency
Byzantine agreement problem: single value initiate by an arbitrary processor & all non faullty processor have to agree on that value.
Concensus problem: every processor have its own initiate value & all non faullty processor have to agree on a single common value.
Interactive consistency: every processor have its own initiate value & all non faullty processor have to agree on a single common value.
Byzantine Agreement Problem
establishing a fault tolerant agreement when one or more nodes in system have been failed.
Imagine that several division of Byzantine army camped outside enemy city & each division command by its own general.
general can communicate with one another through messenger & after obesrving enemy they must decide common action plan.
some of the general are traitors, trying to prevent loyal general from reaching agreement.
General must have an algorithm to guarantee that
- loyal general will do all that algo says.
- small nos of traitors cannot cause the loyal general to adopt the plan.
Requirements: Agreement, Termination & Integrity
Replicated Data Management
sharing information ensuring consistency between redundant resource to improve reliability, fault tolerance & accessibility.
Network traffic, Availability, Reliability, Response time, Throughput, Scalability
each client request is proceed by all servers. deterministic server & anatomic broadcast protocol used.
anatomic broadcast guarantee that either all server recieve request or none plus all message recieve in same order.
only one server processes client request. primary server updates state on other & send back response to client.
user should unaware of where services are located & also transparent of transferring from local machine to remote machine.
Relocation Transparency: transparent in resource move, uniform namespace of files.
Migration Transparency: transparent in load balancing of any particular client by change of location of object.
Failure Transparency: hide any failure & recovery of resource.