PRESENTATION BY :-

ANJALI GAUTAM (9910103506)

AMAN BALUTIA (9910103504)

AN ADAPTIVE PROGRAMMING MODEL FOR FAULT-TOLERANT

DISTRIBUTED SYSTEM

INTRODUCTION

OWHAT ARE FAULTS ?ODeviation from expected behaviorODue to a variety of factors:– Hardware failure– Software bugs– Operator errors Network errors/outages

Three categories–> transient faults–> intermittent faults–> permanent faults

Any fault may be–> fail-silent (fail-stop)–> Byzantine

OVERVIEW

Fault Avoidance– Design a system with minimal faults

Fault Removal– Validate/test a system to remove the presence of faults

Fault Tolerance– Deal with faults

FAULT TOLERANCE

100 % fault-tolerance cannot be achieved.

– The closer we wish to get to 100%, the more expensive the system will be.

– Availability: % of time that the system is functioning

Availability: how much fault tolerance?

Goal: avoid single points of failurePoints of failure: A system is k-fault

tolerant if it can withstand k faults.– Need k+1 components with silent faults -k can fail and one will still be working– Need 2k+1 components with Byzantine

faultsk can generate false replies: k+1 will

provide a majority vote

Points of failure

Modern day systems are equipped with Java Runtime Environment (ver. 1.3 or above).

This project deploys this to its advantage and a routing simulator that runs on this platform is developed.

Since JDK is necessary for other processes in an operating system, this is almost a platform independent simulator as it can run with JDK 1.3 or any other version above this one.

Employment of jdk 1.3 or above

Fault Tolerance is an important issue in Distributed Computing. Fault-tolerant describes a computer system or component designed so that, in the event that a component fails, a backup component or procedure can immediately take its place with no loss of service. In real time distributed system feasibility of task is very important.

The major point of all is to make system functioning even if any part goes off. This would make a system available, reliable, safe and easy maintainable since taking off one element of the system will not stop its function and during this down time that element can be improved to make system more secure and make some updates to it.

LITERATURE SURVEY

SYNCHRONOUS MODEL : Uses time bounds.

ASYNCHRONOUS MODEL : Time bounds are absent.

DISTRIBUTED SYSTEM MODELS

HARDWARE SPECIFICATION Processor : Any Processor above 500 Mhz. Ram : 128Mb. Hard Disk : 10 Gb. Compact Disk : 650 Mb. Input device : Standard Keyboard and Mouse. Output device : VGA and High Resolution Monitor. SOFTWARE SPECIFICATION Operating System : Windows 2000 server Family. Techniques : JDK 1.5 Data Bases : Microsoft Sql Server Front End : Java Swing Back End : Sql Server

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

Execution qualities, such as security and usability, which are observable at run time.

Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system

NON FUNCTIONAL REQUIREMENTS

The synchronous distributed computing model provides processes with bounds on processing time and message transfer delay. These bounds, explicitly known by the processes, can be used to safely detect process crashes and consequently allow the non-crashed processes to progress with safe views of the system state.

In these systems, a system designer can only assume an upper bound on the number of processes that can crash. The protocol has no means to know whether a given process is alive or not. Moreover, if more than f processes crash, there is no guarantee on the protocol behaviour

EXISTING MODEL

Our programming model provides the upper-layer applications with sufficient process state information (the sets) that can be used in order to adapt to the available system synchrony or QoS (in terms of timely and untimely channels), providing more efficient solutions to fault tolerant problems when possible.

PROBLEM STATEMENT

FRONT END: JAVA programming (JVM & Java API)

BACK END: MYSQL server (ODBC & JDBC)

SOFTWARE USED

The system design can be divided into the following modules:

Identify the status of NodeMessage TransmissionChange statusUpdate status

DESIGN

There are many classes that need to be coded for completing the simulator :

For example : All the faulty nodes (server and client) must be coded into different classes , and are dependent to the class that selects these algorithms and link them to the interface .

Class dependencies work along with a Jfree Chart which is a library of professional graphs and can be updated when integration of functionalities is done.

CODING CLASSES

Integration of classes will be done once all the unit modules are coded completely and tested for errors.

The project includes various dependencies among classes , like inheritance , polymorphism etc.

Integration and Integrated testing will be performed by creating batch files that integrates various parts of the program.

Using socket programming for integration.

Integration of two language modules (SQL & java swing) is a difficult task.

INTEGRATION

SCREENSHOTS

Screen2

Screen3

System Testing is utilized as user-oriented vehicle before implementation .

blackbox testing (Stress Testing)

whitebox testing (Compilation Testing)

usability documentation and procedure

TESTING

PROJECT PLAN

PROJECT ANALYSIS

ALGORITM DESIGN FOR LEX ANALYSIS

CODING AND IMPLIMENTATION

FINAL IMPLEMENTATION(INTEGRATION)

Sites referred:http://java.sun.comhttp://www.sourcefordgde.comhttp://www.jfree.org/http://www.networkcomputing.com/

REFERENCES

THANK YOU