MRC Complete Documentation

MULTIPLE ROUTING CONFIGURATION FOR FAST IP NETWORK RECOVERY

An Industry Oriented Mini Project Report

ON

“Multiple Routing Configuration for Fast IP Network Recovery”

Submitted in the partial fulfillment of the requirements for the award

OF

BACHELOR OF TECHNOLOGY

IN

COMPUTER SCIENCE AND ENGINEERING

Submitted by

P.Avanthi 08691A0506K.Deepthi 08691A0518B.Murali 08691A0549P.Gangadhar 08691A0524

Under the Guidance ofMr.T.SREENIVASULU, M.Tech

Assistant Professor in Dept of CSE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

MADANAPALLE INSTITUTE OF TECHNOLOGY AND SCIENCE(Affiliated to Jawaharlal Nehru Technological University, Anantapur and Approved by AICTE, New Delhi)

An ISO 9001:2008 Certified InstitutionMadanapalle – 517 325

2008 - 2012


Ph.08571-280255,280590 Fax:08571-280433

MADANAPALLE INSTITUTE OF TECHNOLOGY &

SCIENCE

An engineering College Sponsored by

RATAKONDA RANGA REDDY EDUCATIONAL ACADEMY

Approved by AICTE ,New Delhi and Affiliated to JNTUA, Anantapur

P.B.No-14,Angallu,Madanapalle -517325,Chittoor District, A.P.

www.mits.edu

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BONAFIDE CERTIFICATE

This is to certify that the project work entitled “MULTIPLE ROUTING CONFIGURATION FOR FAST IP NETWORK RECOVERY”, is a bonafide work carried out by P.Avanthi(08691A0506), K.Deepthi(08691A0518), B.Murali(08691A0549), P.Gangadhar(08691A0524) have submitted in the partial fulfillment of the requirements for the award of the degree Bachelor of Technology in the stream of Computer Science and Engineering in Madanapalle Institute of Technology and Science, Madanapalle, affiliated to Jawaharlal Nehru Technological University, Anantapur during the academic year 2008 - 2012

GUIDE: HOD:

Mr. T. SREENIVASULU, M.Tech Dr. A. NAGARAJARAO,M.Tech,Ph.D

Assistant Professor, Professor & Head Of The Department,

Dept. of C.S.E. Dept. of C.S.E.

Submitted for the University Examination held on:

Internal Examiner External Examiner


ACKNOWLEDGEMENT

We would like to express our sincere thanks to our project guide

Mr.T.SREENIVASULU, M.Tech, Assistant Professor in CSE Department for his guidance,

encouragement and help in completing this project.

We are very much thankful to our project coordinator Mr.K.LAKSHMAIAH, M.Tech.,

(Ph.D.) for his unforgettable support in acknowledge page

We express our deep sense of gratitude to Dr.A.NAGARAJA RAO, M.Tech., Ph.D.,

Head of the Department of Computer Science and Engineering, for his valuable guidance

and constant encouragement given to us during this work.

We sincerely thank Dr. K.SREENIVASA REDDY M.E Ph.D., Principal for permitting

us to carry out project work in the college and for valuable suggestions.

We sincerely thank to the Management of Madanapalle Institute of Technology and

Science for providing excellent infrastructure facilities.

We are very much grateful to all the faculty members of the CSE Department for their

value based imparting of the theory and practical subjects, which we have used in this project

work. We also thank the members of non-teaching staff for their cooperation and timely help.


DECLARATION

We P.AVANTHI (08691A0506), K.DEEPTHI (08691A0518), B.MURALI(08691A0549) &

P.GANGADHAR(08691A0524) hereby declare that the mini project report entitled

“MULTIPLE ROUTING CONFIGURATION FOR FAST IP NETWORK RECOVERY”

done by us under the guidance of Mr.T.SREENIVASULU, M.TECH submitted in partial

fulfillment of the requirements for the award of degree of Bachelor of Technology in Computer

Science and Engineering Madanapalle Institute of Technology and Science, Madanapalle

affiliated to Jawaharlal Nehru Technological University, Anantapur during the academic

year 2008-2012.

The results embodied in this project have not been submitted to any other university or

institute for the award of any degree or diploma

Date:

Place:

Signature of the Students

P.Avanthi

K.Deepthi

B.Murali

P.Gangadhar


CONTENTS CHAPTER Page No.

1: INTRODUCTION

1.1: System Overview 10

2: SYSTEM ANALYSIS

2.1: Existing System 12

2.2: Proposed System 13

2.3: Feasibility Study 13

2.4: Software and Hardware Requirements 14

2.5: Data Flow Diagrams 15

3: SYSTEM DESIGN

3.1: Design Objectives 19

3.2: UML Diagrams 19

3.3: Database Tables 32

4: IMPLEMENTATION

4.1: Introduction 36

4.2: Modules Implemented 37

5: TESTING

5.1: Testing Fundamentals 40

5.2: White Box Testing 44

5.3: Black Box Testing 45

6: OUTPUT SCREENS 477: CONCLUSIONS AND FUTURE WORK 57

APPENDIX A. BIBLIOGRAPHY & REFERENCES XX


ABSTRACT


ABSTRACT

As the Internet takes an increasingly central role in our communications infrastructure,

the slow convergence of routing protocols after a network failure becomes a growing problem.

To assure fast recovery from link and node failures in IP networks, we present a new recovery

scheme called Multiple Routing Configurations (MRC). It can be implemented with only minor

changes to existing solutions. In this paper we present MRC, and analyze its performance with

respect to scalability, backup path lengths, and load distribution after a failure. We also show

how an estimate of the traffic demands in the network can be used to improve the distribution of

the recovered traffic, and thus reduce the chances of congestion when MRC is used.


INTRODUCTION

INTRODUCTION


In recent years the Internet has been transformed from a special purpose network to a

ubiquitous platform for a wide range of everyday communication services. The demands on

Internet reliability and availability have increased accordingly. A disruption of a link in central

parts of a network has the potential to affect hundreds of thousands of phone conversations or

TCP connections, with obvious adverse effects. The ability to recover from failures has always

been a central design goal in the Internet. IP networks are intrinsically robust, since IGP routing

protocols like OSPF are designed to update the forwarding information based on the changed

topology after a failure. This re-convergence assumes full distribution of the new link state to all

routers in the network domain. When the new state information is distributed, each router

individually calculates new valid routing tables.

This network-wide IP re-convergence is a time consuming process, and a link or node failure is

typically followed by a period of routing instability. During this period, packets may be dropped

due to invalid routes. This phenomenon has been studied in both IGP and BGP context , and has

an adverse effect on real-time applications . Events leading to a re-convergence have been shown

to occur frequently .Much effort has been devoted to optimizing the different steps of the

convergence of IP routing, i.e., detection, dissemination of information and shortest path

calculation, but the convergence time is still too large for applications with real time demands[6].

A key problem is that since most network failures are short lived [7], too rapid triggering of the

re-convergence process can cause route flapping and increased network instability.


SYSTEM ANALYSIS

SYSTEM ANALYSIS

2.1 EXISTING SYSTEM

In the existing system, it performs re-convergence only after node or link failures, as we know it is time consuming. Convergence process is slow because it is reactive and global. It reacts to failure after it has happened, and it involves all routers in the domain. This phenomenon has an adverse effect on real-time applications.

Bottlenecks:


The Bottlenecks of the existing system are:

This convergence process is slow because it is reactive and global. It’s time consuming process to recover from node or link failure.

2.2 PROPOSED SYSTEM

The main idea of MRC is to use network graph and the associated link weights to have backup configuration. It is 3 folded methodologies, which includes

“Backup of all possible paths”, “Applying Shortest Path Finding Algorithm”, and “When failure occurs, taking the alternative route from the backups”.

It not only guarantees connectivity after failure, but also avoids unacceptable load distribution.

Advantages:

MRC has a range of attractive features:

Almost continuous forwarding of packets in case of node or link failure. Always provides the network availability. Uses a single mechanism to handle both link and node failures. MRC makes no assumptions with respect to the failures. No Re-Convergence applied for Temporary failures. Minor modifications are enough, to the existing system.

2.3 FEASIBILITY STUDY

The feasibility of the project is analyzed in this phase and business proposal is put forth

with a very general plan for the project and some cost estimates. During system analysis the

feasibility study of the proposed system is to be carried out. This is to ensure that the proposed

system is not a burden to the company. For feasibility analysis, some understanding of the major

requirements for the system is essential.


Three key considerations involved in the feasibility analysis are

ECONOMICAL FEASIBILITY

TECHNICAL FEASIBILITY

SOCIAL FEASIBILITY

ECONOMICAL FEASIBILITY

This study is carried out to check the economic impact that the system will have on the

organization. The amount of fund that the company can pour into the research and development

of the system is limited. The expenditures must be justified. Thus the developed system as well

within the budget and this was achieved because most of the technologies used are freely

available. Only the customized products had to be purchased.

TECHNICAL FEASIBILITY

This study is carried out to check the technical feasibility, that is, the technical

requirements of the system. Any system developed must not have a high demand on the available

technical resources. This will lead to high demands on the available technical resources. This

will lead to high demands being placed on the client. The developed system must have a modest

requirement, as only minimal or null changes are required for implementing this system.


SOCIAL FEASIBILITY

The aspect of study is to check the level of acceptance of the system by the user. This

includes the process of training the user to use the system efficiently. The user must not feel

threatened by the system, instead must accept it as a necessity. The level of acceptance by the

users solely depends on the methods that are employed to educate the user about the system and

to make him familiar with it. His level of confidence must be raised so that he is also able to

make some constructive criticism, which is welcomed, as he is the final user of the system.

2.4 SOFTWARE AND HARDWARE REQUIREMENTS

Hardware Requirements:

System : Pentium IV 2.4 GHz.

Hard Disk : 40 GB.

Floppy Drive : 1.44 Mb.

Monitor : 15 VGA Colour.

Mouse : Logitech.

Ram : 256 Mb.


Software Requirements:

Operating system : Windows XP Professional.

Coding Language : Java.

Tool Used : Eclipse.

2.5 DATAFLOW DIAGRAMS

The DFD takes an input-process-output view of a system i.e. data objects flow into the

software, are transformed by processing elements, and resultant data objects flow out of the

software.

Data objects represented by labeled arrows and transformation are represented by circles

also called as bubbles. DFD is presented in a hierarchical fashion i.e. the first data flow model

represents the system as a whole. Subsequent DFD refine the context diagram (level 0 DFD),

providing increasing details with each subsequent level.


The DFD enables the software engineer to develop models of the information domain &

functional domain at the same time. As the DFD is refined into greater levels of details, the

analyst performs an implicit functional decomposition of the system. At the same time, the DFD

refinement results in a corresponding refinement of the data as it moves through the processes

that embody the applications.

A context-level DFD for the system the primary external entities produce information for

use by the system and consume information generated by the system. The labeled arrow

represents data objects or object hierarchy.

A DFD identifies all inputs and outputs and reads left to right and top to bottom. It

indicates external sources and destinations of data with Squares. It indicates each process internal

to the system with rounded Circles. There must be no unnamed process. It identifies all data

flows for each process step, except simple Record retrievals and labels data flow on each arrow.

Level -1

Client

Send a packet

Router


Level-0

Client Router Server

MRC

Server


SYSTEM DESIGN

SYSTEM DESIGN

3.1 Design Objectives:

Design is the first step in moving from problem domain to the solution domain. Design is

essentially the bridge between requirements specification and the final solution.

The goal of design process is to produce a model or representation of a system, which can

be used later to build that system. The produced model is called the “Design of the system”. It is

a plan for a solution for the system.

UNIFIED MODELLING LANGUAGE (UML):

An Overview of UML:

The UML is a language for

• Visualizing

• Specifying

• Constructing


• Documentation

These are the artifacts of a software-intensive system.

A conceptual model of UML:

The three major elements of UML are

• The UML’s basic building blocks.

• The rules that dictate how those building blocks may be put together.

• Some common mechanisms that apply throughout the UML.

Basic building blocks of the UML:

The vocabulary of UML encompasses three kinds of building blocks:

• Things

• Relationships

• Diagrams

Things are the abstractions that are first-class citizens in a model.

Relationships tie these things together.

Diagrams group the interesting collection of things.

Things in UML: There are four kinds of things in the UML

• Structural things

• Behavioral things

• Grouping things

• Annotational things


These things are the basic object oriented building blocks of the UML. They are used to

write well-formed models.

STRUCTURAL THINGS

Structural things are the nouns of the UML models. These are mostly static parts of the

model, representing elements that are either conceptual or physical. In all, there are seven kinds

of Structural things.

Class:

A class is a description of a set of objects that share the same attributes, operations,

relationships, and semantics. A class implements one or more interfaces.

Graphically a class is rendered as a rectangle, usually including its name, attributes and

operations, as shown below.

Interface:

An Interface is a collection of operation that specifies a service of a class or component.

An interface describes the externally visible behavior of that element.

Graphically, the interface is rendered as a circle together with its name.

Use case:

Interface


Use case is a description of a set of sequence of actions that a system performs that yields an

observable result of value to a particular things in a model. Graphically, Use case is rendered as

an ellipse with dashed lines, usually including only its name as shown below.

Client

login to n/ w

send packet infrmn

receive ack from server

Component:

Component is a physical and replaceable part o a system that conforms to and provides

the realization of a set of interfaces.

Graphically, a component is rendered as a rectangle with tabs, usually including only its name, as

shown below.

Node:

A Node is a physical element that exists at run time and represents a computational

resource, generally having at least some memory and often, processing capability.


Graphically, a node is rendered as a cube, usually including only its name, as shown

below.

BEHAVIORAL THINGS

Behavioral Things are the dynamic parts of UML models. These are the verbs of a model,

representing behavior over time and space.

Interaction:

An interaction is a behavior that comprises a set of messages exchanged among set

objects within a particular context to accomplish a specific purpose.

Graphically, a message is rendered as a direct line, almost always including the name of

its operation, as shown below.

: Client

Network Router Destination

1 : login()

2 : authentication()

3 : send a file()

4 : packets are transmitted()

5 : route packets to destination()

6 : ack of successful receive()

State Machine:


A state machine is a behavior that specifies the sequence of states an object or an

interaction goes through during its lifetime on response to events, together with its responses to

those events.

GROUPING THINGS

Grouping things are the organizational parts of the UML models. These are the boxes

into which a model can be decomposed.

Package:

A package is a general-purpose mechanism for organizing elements into groups.

ANNOTATIONAL THINGS

Annotational things are the explanatory parts of the UML models. It doesn’t correspond

to any object but serves as comment.

Note:

A note is simply a symbol for rendering constraints and comments attached to an element

or a collection of elements.

Graphically a note is rendered with dog-eared corner together, with a textual or graphical

comment.

RELATIONSHIPS IN THE UML

There are four kinds of relationships in the UML:


• Dependency

• Association

• Generalization

• Realization

UML DIAGRAMS:

CLASS DIAGRAM:

USECASE DIAGRAMS:


SEQUENCE DIAGRAM:


COLLOBRATION DIAGRAM:

ACTIVITY DIAGRAM:



IMPLEMENTATION

IMPLEMENTATION

4.1 IMPLEMENTATION:

During the implementation stage, the system is physically created. Necessary programs

are coded, debugged and documented. The test plan is established for checking each and every

component of the system.

The choice of a programming language for a specific project must take into account both

engineering and physical characteristics.


Java is a secured language. It is platform independent as it doesn’t depend on

configuration or OS of a particular system but it should have Java Virtual Machine (JVM). Byte

code verification takes place at the end of the compilation process to make sure that is all

accurate and correct. So byte code verification is integral to the compiling and executing of Java

code.

It helps the programmer to create full featured GUI and OOPS based applications. It acts

as FRONT END tool for databases like SQL, MS- Access, Oracle, Sybase etc.

Since present applications require storing the large data and we have to manipulate on

that data, it is fully database application. For managing

Corporate database we can choose SQL acts as the BACKEND tool.

4.2 MODULES USED:

Server Client Routers

Client Module

This module is used to send the data to server through routers It will provide user friendly interface to send the data to the required

destination


Router module

This are placed in between server and client to transfer the data. Whenever client sends the data to the server it will pass through any one

router. If the router is failed the data will be transferred through another router to

reduce the system failure.

Server module It will receive the data send by the client which came from the active

router. It can have any number of clients.

Software Environment

Java Technology

Java technology is both a programming language and a platform.

The Java Programming Language

The Java programming language is a high-level language that can be characterized by all of the following buzzwords:


Simple

Architecture neutral

Object oriented

Portable

Distributed

High performance

Interpreted

Multithreaded

Robust

Dynamic

Secure

With most programming languages, you either compile or interpret a program so that you

can run it on your computer. The Java programming language is unusual in that a program is

both compiled and interpreted. With the compiler, first you translate a program into an

intermediate language called Java byte codes —the platform-independent codes interpreted by

the interpreter on the Java platform. The interpreter parses and runs each Java byte code

instruction on the computer. Compilation happens just once; interpretation occurs each time the

program is executed. The following figure illustrates how this works.

You can think of Java byte codes as the machine code instructions for the Java Virtual

Machine (Java VM). Every Java interpreter, whether it’s a development tool or a Web browser

that can run applets, is an implementation of the Java VM. Java byte codes help make “write

once, run

anywhere” possible. You can compile your program into byte codes on any platform that has a


Java compiler. The byte codes can then be run on any implementation of the Java VM. That

means that as long as a computer has a Java VM, the same program written in the Java

programming language can run on Windows 2000, a Solaris workstation, or on an iMac.

The Java Platform

A platform is the hardware or software environment in which a program runs.

We’ve already mentioned some of the most popular platforms like Windows 2000,

Linux, Solaris, and MacOS. Most platforms can be described as a combination of the

operating system and hardware. The Java platform differs from most other platforms in

that it’s a software-only platform that runs on top of other hardware-based platforms.

The Java platform has two components:

• The Java Virtual Machine (Java VM)

• The Java Application Programming Interface (Java API)

You’ve already been introduced to the Java VM. It’s the base for the Java platform

and is ported onto various hardware-based platforms.

The Java API is a large collection of ready-made software components that provide

many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is

grouped into libraries of related classes and interfaces; these libraries are known as

packages. The next section, What Can Java Technology Do? Highlights what

functionality some of the packages in the Java API provide.


The following figure depicts a program that’s running on the Java platform. As the

figure shows, the Java API and the virtual machine insulate the program from the

hardware.

Native code is code that after you compile it, the compiled code runs on a specific

hardware platform. As a platform-independent environment, the Java platform can be a

bit slower than native code. However, smart compilers, well-tuned interpreters, and just-

in-time byte code compilers can bring performance close to that of native code without

threatening portability.

What Can Java Technology Do?

The most common types of programs written in the Java programming language are

applets and applications. If you’ve surfed the Web, you’re probably already familiar with

applets. An applet is a program that adheres to certain conventions that allow it to run

within a Java-enabled browser.

However, the Java programming language is not just for writing cute, entertaining applets

for the Web. The general-purpose, high-level Java programming language is also a

powerful software platform. Using the generous API, you can write many types of

programs.

An application is a standalone program that runs directly on the Java platform. A special

kind of application known as a server serves and supports clients on a network. Examples

of servers are Web servers, proxy servers, mail servers, and print servers. Another

specialized program is a servlet. A servlet can almost be thought of as an applet that runs

on the server side. Java Servlets are a popular choice for building interactive web

applications, replacing the use of CGI scripts. Servlets are similar to applets in that they

are runtime extensions of applications. Instead of working in browsers, though, servlets

run within Java Web servers, configuring or tailoring the server.


How does the API support all these kinds of programs? It does so with packages of

software components that provides a wide range of functionality. Every full

implementation of the Java platform gives you the following features:

• The essentials: Objects, strings, threads, numbers, input and output, data

structures, system properties, date and time, and so on.

• Applets: The set of conventions used by applets.

• Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data

gram Protocol) sockets, and IP (Internet Protocol) addresses.

• Internationalization: Help for writing programs that can be localized for

users worldwide. Programs can automatically adapt to specific locales and be

displayed in the appropriate language.

• Security: Both low level and high level, including electronic signatures, public

and private key management, access control, and certificates.

• Software components: Known as JavaBeansTM, can plug into existing

component architectures.

• Object serialization: Allows lightweight persistence and communication via

Remote Method Invocation (RMI).

• Java Database Connectivity (JDBCTM): Provides uniform access to a

wide range of relational databases.

The Java platform also has APIs for 2D and 3D graphics, accessibility, servers,

collaboration, telephony, speech, animation, and more. The following figure depicts what

is included in the Java 2 SDK.


How

Will Java Technology Change My Life?

We can’t promise you fame, fortune, or even a job if you learn the Java programming

language. Still, it is likely to make your programs better and requires less effort than

other languages. We believe that Java technology will help you do the following:

• Get started quickly: Although the Java programming language is a powerful

object-oriented language, it’s easy to learn, especially for programmers already

familiar with C or C++.

• Write less code: Comparisons of program metrics (class counts, method

counts, and so on) suggest that a program written in the Java programming

language can be four times smaller than the same program in C++.

• Write better code: The Java programming language encourages good coding

practices, and its garbage collection helps you avoid memory leaks. Its object

orientation, its JavaBeans component architecture, and its wide-ranging, easily

extendible API let you reuse other people’s tested code and introduce fewer bugs.

• Develop programs more quickly: Your development time may be as much

as twice as fast versus writing the same program in C++. Why? You write fewer

lines of code and it is a simpler programming language than C++.

• Avoid platform dependencies with 100% Pure Java: You can keep

your program portable by avoiding the use of libraries written in other languages.


The 100% Pure JavaTM Product Certification Program has a repository of

historical process manuals, white papers, brochures, and similar materials online.

• Write once, run anywhere: Because 100% Pure Java programs are

compiled into machine-independent byte codes, they run consistently on any Java

platform.

• Distribute software more easily: You can upgrade applets easily from a

central server. Applets take advantage of the feature of allowing new classes to be

loaded “on the fly,” without recompiling the entire program.

ODBC

Microsoft Open Database Connectivity (ODBC) is a standard programming interface for

application developers and database systems providers. Before ODBC became a de facto

standard for Windows programs to interface with database systems, programmers had to use

proprietary languages for each database they wanted to connect to. Now, ODBC has made the

choice of the database system almost irrelevant from a coding perspective, which is as it should

be. Application developers have much more important things to worry about than the syntax that

is needed to port their program from one database to another when business needs suddenly

change.

Through the ODBC Administrator in Control Panel, you can specify the particular

database that is associated with a data source that an ODBC application program is written to

use. Think of an ODBC data source as a door with a name on it. Each door will lead you to a

particular database. For example, the data source named Sales Figures might be a SQL Server

database, whereas the Accounts Payable data source could refer to an Access database. The

physical database referred to by a data source can reside anywhere on the LAN.

From a programming perspective, the beauty of ODBC is that the application can be

written to The ODBC system files are not installed on your system by Windows 95. Rather, they

are installed when you setup a separate database application, such as SQL Server Client or

Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a file called

ODBCINST.DLL. It is also possible to administer your ODBC data sources through a stand-

alone program called ODBCADM.EXE. There is a 16-bit and a 32-bit version of this program

and each maintains a separate list of ODBC data sources.

are probably thinking there must be some catch. The only disadvantage of ODBC is that it isn’t


as efficient as talking directly to the native database interface. ODBC has had many detractors

make the charge that it is too slow. Microsoft has always claimed that the critical factor in

performance is the quality of the driver software that is used. In our humble opinion, this is true.

The availability of good ODBC drivers has improved a great deal recently. And anyway, the

criticism about performance is somewhat analogous to those The

advantages of this scheme are so numerous that you who said that compilers would never match

the speed of pure assembly language. Maybe not, but the compiler (or ODBC) gives you the

opportunity to write cleaner programs, which means you finish sooner. Meanwhile, computers

get faster every year.

JDBC

In an effort to set an independent database standard API for Java; Sun Microsystems

developed Java Database Connectivity, or JDBC. JDBC offers a generic SQL database access

mechanism that provides a consistent interface to a variety of RDBMSs. This consistent interface

is achieved through the use of “plug-in” database connectivity modules, or drivers. If a database

vendor wishes to have JDBC support, he or she must provide the driver for each platform that the

database and Java run on.

To gain a wider acceptance of JDBC, Sun based JDBC’s framework on ODBC. As you

discovered earlier in this chapter, ODBC has widespread support on a variety of platforms.

Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market much faster than

developing a completely new connectivity solution.

JDBC was announced in March of 1996. It was released for a 90 day public review that

ended June 8, 1996. Because of user input, the final JDBC v1.0 specification was released soon

after.

The remainder of this section will cover enough information about JDBC for you to know what it

is about and how to use it effectively. This is by no means a complete overview of JDBC. That

would fill an entire book.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one that, because of

its many goals, drove the development of the API. These goals, in conjunction with early


reviewer feedback, have finalized the JDBC class library into a solid framework for building

database applications in Java.

The goals that were set for JDBC are important. They will give you some insight as to why

certain classes and functionalities behave the way they do. The eight design goals for JDBC are

as follows:

• SQL Level API

The designers felt that their main goal was to define a SQL interface for Java. Although

not the lowest database interface level possible, it is at a low enough level for higher-level

tools and APIs to be created. Conversely, it is at a high enough level for application

programmers to use it confidently. Attaining this goal allows for future tool vendors to

“generate” JDBC code and to hide many of JDBC’s complexities from the end user.

• SQL Conformance

SQL syntax varies as you move from database vendor to database vendor. In an effort to

support a wide variety of vendors, JDBC will allow any query statement to be passed through

it to the underlying database driver. This allows the connectivity module to handle non-

standard functionality in a manner that is suitable for its users.

• JDBC must be implemental on top of common database interfaces

The JDBC SQL API must “sit” on top of other common SQL level APIs. This goal

allows JDBC to use existing ODBC level drivers by the use of a software interface. This

interface would translate JDBC calls to ODBC and vice versa.

• Provide a Java interface that is consistent with the rest of the Java system

Because of Java’s acceptance in the user community thus far, the designers feel that they

should not stray from the current design of the core Java system.

• Keep it simple

This goal probably appears in all software design goal listings. JDBC is no exception.

Sun felt that the design of JDBC should be very simple, allowing for only one method of

completing a task per mechanism. Allowing duplicate functionality only serves to confuse

the users of the API.

• Use strong, static typing wherever possible


Strong typing allows for more error checking to be done at compile time; also, less error

appear at runtime.

• Keep the common cases simple

Because more often than not, the usual SQL calls used by the programmer are simple

SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should be simple to

perform with JDBC. However, more complex SQL statements should also be possible.

Finally we decided to proceed the implementation using Java Networking.

And for dynamically updating the cache table we go for MS Access database.

Java has two things: a programming language and a platform.

Java is also unusual in that each Java program is both compiled and interpreted.

With a compile you translate a Java program into an intermediate language called Java

byte codes the platform-independent code instruction is passed and run on the

computer.

Compilation happens just once; interpretation occurs each time the program is

executed. The figure illustrates how this works.

You can think of Java byte codes as the machine code instructions for the Java

Virtual Machine (Java VM). Every Java interpreter, whether it’s a Java development

tool or a Web browser that can run Java applets, is an implementation of the Java VM.

The Java VM can also be implemented in hardware.

Java byte codes help make “write once, run anywhere” possible. You can

compile your Java program into byte codes on my platform that has a Java compiler.

The byte codes can then be run any implementation of the Java VM. For example, the

same Java program can run Windows NT, Solaris, and Macintosh.

Networking

TCP/IP stack

The TCP/IP stack is shorter than the OSI one:


IP datagram’s

The IP layer provides a connectionless and unreliable delivery system. It considers each

datagram independently of the others. Any association between datagram must be supplied by

the higher layers. The IP layer supplies a checksum that includes its own header. The header

includes the source and destination addresses. The IP layer handles routing through an Internet. It

is also responsible for breaking up large datagram into smaller ones for transmission and

reassembling them at the other end.

UDPUDP is also connectionless and unreliable. What it adds to IP is a checksum for the

contents of the datagram and port numbers. These are used to give a client/server model - see

later.

TCP

TCP supplies logic to give a reliable connection-oriented protocol above IP. It provides a

virtual circuit that two processes can use to communicate.

Internet addresses

In order to use a service, you must be able to find it. The Internet uses an address scheme

for machines so that they can be located. The address is a 32 bit integer which gives the IP

address. This encodes a network ID and more addressing. The network ID falls into various

classes according to the size of the network address.

Network addressClass A uses 8 bits for the network address with 24 bits left over for other addressing.

Class B uses 16 bit network addressing. Class C uses 24 bit network addressing and class D uses

all 32.

Subnet address

Internally, the UNIX network is divided into sub networks. Building 11 is currently on

one sub network and uses 10-bit addressing, allowing 1024 different hosts.


Host address

8 bits are finally used for host addresses within our subnet. This places a limit of 256

machines that can be on the subnet.

Total address

The 32 bit address is usually written as 4 integers separated by dots.

Port addressesA service exists on a host, and is identified by its port. This is a 16 bit number. To send a

message to a server, you send it to the port for that service of the host that it is running on. This

is not location transparency! Certain of these ports are "well known".

SocketsA socket is a data structure maintained by the system to handle network connections. A

socket is created using the call socket. It returns an integer that is like a file descriptor. In fact,

under Windows, this handle can be used with Read File and Write File functions.

#include <sys/types.h>#include <sys/socket.h>int socket(int family, int type, int protocol);

Here "family" will be AF_INET for IP communications, protocol will be zero, and

type will depend on whether TCP or UDP is used. Two processes wishing to communicate

over a network create a socket each. These are similar to two ends of a pipe - but the actual pipe

does not yet exist.

JFree Chart


JFreeChart is a free 100% Java chart library that makes it easy for developers to display

professional quality charts in their applications. JFreeChart's extensive feature set includes:

A consistent and well-documented API, supporting a wide range of chart types;

A flexible design that is easy to extend, and targets both server-side and client-side applications;

Support for many output types, including Swing components, image files (including PNG

and JPEG), and vector graphics file formats (including PDF, EPS and SVG);

JFreeChart is "open source" or, more specifically, free software. It is distributed under the

terms of the GNU Lesser General Public License (LGPL), which permits use in proprietary

applications.

1. Map Visualizations

Charts showing values that relate to geographical areas. Some examples include: (a)

population density in each state of the United States, (b) income per capita for each country in

Europe, (c) life expectancy in each country of the world. The tasks in this project include:

Sourcing freely redistributable vector outlines for the countries of the world,

states/provinces in particular countries (USA in particular, but also other areas);

Creating an appropriate dataset interface (plus default implementation), a rendered, and

integrating this with the existing XYPlot class in JFreeChart;

Testing, documenting, testing some more, documenting some more.

2. Time Series Chart Interactivity

Implement a new (to JFreeChart) feature for interactive time series charts --- to display a

separate control that shows a small version of ALL the time series data, with a sliding "view"

rectangle that allows you to select the subset of the time series data to display in the main

chart.

3. Dashboards


There is currently a lot of interest in dashboard displays. Create a flexible dashboard

mechanism that supports a subset of JFreeChart chart types (dials, pies, thermometers, bars,

and lines/time series) that can be delivered easily via both Java Web Start and an applet.

4. Property Editors

The property editor mechanism in JFreeChart only handles a small subset of the

properties that can be set for charts. Extend (or re-implement) this mechanism to provide

greater end-user control over the appearance of the charts.


TESTING

TESTING


Software testing is a critical element of software quality assurance and represents the ultimate

review of specification, design and coding. In fact, testing is the one step in the software

engineering process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-planned

series of steps that result in the successful construction of software. Testing is the set of activities

that can be planned in advance and conducted systematically. The underlying motivation of

program testing is to affirm software quality with methods that can economically and effectively

apply to both strategic to both large and small-scale systems.

5.1 Testing fundamentals:

The software engineering process can be viewed as a spiral. Initially system engineering

defines the role of software and leads to software requirement analysis where the information

domain, functions, behavior, performance, constraints and validation criteria for software are

established. Moving inward along the spiral, we come to design and finally to coding. To develop

computer software we spiral in along streamlines that decrease the level of abstraction on each

turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit

testing begins at the vertex of the spiral and concentrates on each unit of the software as

implemented in source code. Testing progress by moving outward along the spiral to integration

testing, where the focus is on the design and the construction of the software architecture. Talking

another turn on outward on the spiral we encounter validation testing where requirements

established as part of software requirements analysis are validated against the software that has

been constructed. Finally we arrive at system testing, where the software and other system

elements are tested as a whole.

Testing is a process, which reveals errors in the program. It is the major quality measure

employed during software development. The testing method varies from project to project

depending on the nature and complexity of the system, working environment etc. During testing

the program is executed with a set of test cases and the output of the program for the test cases is

evaluated to determine if the program is performing as it is expected to.


There are several levels in testing phase. These are unit testing, integration testing,

system testing and acceptance testing. Initially the tests are focused on each module individually

to test whether it is functioning as a unit.

In conventional applications, unit-testing focuses on the smallest combinable program

unit the sub program (e.g. module, sub routine, procedure, and component). After testing them

individually, it is integrated into a program structure and does the remaining testing.

5.1.1 Unit Testing:

The first level of testing is unit testing. When object-oriented software is considered the concept of

unit changes. Rather than testing an individual module, the smallest testable unit is the

encapsulated class or object. Class testing for object-oriented software is the equivalent of unit

testing for conventional software. Unlike unit testing of conventional software, which tends to

focus on the algorithmic detail of a module and the data that flow across the module interface,

class testing for object oriented software is driven by the operations encapsulated by the class and

state behavior of the class.

5.1.2 Integration Testing:

This testing is second level in testing process. After completion of unit testing, which confirms the

module’s functionality, we integrated modules to form sub systems. These subsystems are tested

under this integration testing. It checks whether data lost or preserved between interface calls. In

this module whether data flowed properly across the procedures is tested. Modules are integrated

by moving downward through the control hierarchy beginning from the main control module.

The following are the types of Integration Testing:

5.1.2.1 Top-Down Integration

This method is an incremental approach to the construction of program structure.

Modules are integrated by moving downward through the control hierarchy, beginning with the

main program module. The module subordinates to the main program module are incorporated

into the structure in either a depth first of breadth-first manner.


5.1.2.2 Bottom up Integration

This method begins the construction and testing with the modules at the lowest level in

the program structure. Since the modules are integrated from the bottom up, processing required

for modules subordinate to a given level is always available and the need for stubs is elimination.

The bottom-up integration strategy may be implemented with the following steps:

The low-level modules are combined into clusters that perform a specific software

Sub-function.

A drive (i.e.,), the control program for testing is written to co-ordinate test case input and

Output.

The cluster is tested.

Drivers are removed and clusters are combined moving upward in the program structure.

5.1.3 Validation Testing

At the end of the Integration Testing, software is completely assembled as a package,

interfacing errors have been uncovered and correction testing begun. The system has been tested

and implemented successfully and thus ensured that all the requirements as listed in the software

requirements specification are completely fulfilled. In case of erroneous input corresponding error

messages are displayed.

5.1.3.1 Compiling Test

It was a good idea to do our stress testing early on, because it gave us time to fix some

of the unexpected deadlocks and stability problems that only occurred when components were

exposed to very high transaction volumes.

5.1.3.2 Execution Test

This program was successfully loaded and executed. Because of good programming

there were no execution error found.

5.1.3.3 Output Test


The successful output screens are placed in the output screens section above.

5.1.3.4 Validation Test Criteria:

Software testing and validation is achieved trough serried of black box tests that

demonstrate conformity with the requirements. A test plan outlines the classes of tests to be

conducted and a test procedure defines specific test cases that will be used to demonstrate

conformity with requirements. Both, the plan and the procedure are designed to ensure that all

functional requirements are achieved, documentation is correct and other requirements are met.

5.1.4 System testing:

System testing is responsible to ensure total software is worked as per requirements

specified in requirement documents. The main reference for this level of testing is requirement

document. This goal of this testing is to see, whether system meets its requirements or not.

5.1.4.1 Acceptance testing:

Acceptance testing was top level testing which tests with some realistic data of the

client to demonstrate that the software is working satisfactory. Testing here focuses on the external

behavior of the system.

5.2 White Box Testing

This strategy examines the logic of the program. To follow this method we developed

some test data that resulted in executing every instruction in the program and module i.e. every

path is tested. Systems are not designed as entire nor are they tested as single systems. To ensure

that the coding is perfect two types of testing is performed or for that matter is performed or that

matter is performed or for that matter is performed on all systems.

In this the test cases are generated on the logic of each module by drawing flow graphs of that

module and logical decisions are tested on all the cases.

It has been uses to generate the test cases in the following cases:


Guarantee that all independent paths have been executed.

Execute all logical decisions on their true and false sides.

Execute all loops at their boundaries and within their operational bounds.

Execute internal data structures to ensure their validity.

This is a unit testing method where a unit will be taken at a time and tested thoroughly at a

statement level to find the maximum possible errors. I tested step wise every piece of code, taking

care that every statement in the code is executed at least once. The white box testing is also called

Glass Box Testing.

5.3 Black Box Testing

In this strategy some test cases are generated as input conditions that fully execute all

functional requirements for the program. This testing has been uses to find errors in the following

categories:

• Incorrect or missing functions

• Interface errors

• Errors in data structure or external database access

• Performance errors

• Initialization and termination errors.

In this testing only the output is checked for correctness. The logical flow of the data is not

checked.

This testing method considers a module as a single unit and checks the unit at interface and

communication with other modules rather getting into details at statement level. Here the module

will be treated as a block box that will take some input and generate output. Output for a given set

of input combinations are forwarded to other modules.


This test involves the manual evaluation of the flow from one module to the other and check

accordingly for the process flow. This process of testing is with the following criteria:

Criteria Satisfied by Test Cases

Test cases that reduced by a count that is greater than one, the number of additional test

cases that much be designed to achieve reasonable testing.

Test cases that tell us something about the presence or absence of classes of errors,

rather than an error associated only with the specific test at hand.


SCREENS


Selecting a File


When sent to server


Condition of Router A


The Condition of Router B


The Condition of Router C


The Server Status


CONCLUSION

CONCLUSION

We have presented Multiple Routing Configurations as an approach to achieve fast recovery in

IP networks.MRC is based on providing the routers with additional routing configurations,


allowing them to forward packets along routes that avoid a failed component. MRC can act

promptly after failure discovery

FUTURE ENHANCEMENT

As an future enhancement we can browse the multiple files and we can send them to

destination instead of browsing individual files which is an time consuming.

We can maintain the buffer at receiver side and we can store the received files and we can

download them in future when required by the user.

Documents

MRC Complete Documentation