dynamic routing docdrthyfj gyujg

7/29/2019 Dynamic Routing Docdrthyfj gyujg

1/121

Dynamic Routing with Security Considerations

ABSTRACT:

Security has become one of the major issues for data communication

over wired and wireless networks. Different from the past work on the

designs of cryptography algorithms and system infrastructures, we will

propose a dynamic routing algorithm that could randomize delivery paths for

data transmission. The algorithm is easy to implement and compatible with

popular routing protocols, such as the Routing Information Protocol in wired

networks and Destination-Sequenced Distance Vector protocol in wireless

networks, without introducing extra control messages. An analytic study on

the proposed algorithm is presented, and a series of simulation experiments

are conducted to verify the analytic results and to show the capability of the

proposed algorithm.


2/121

1. INTRODUCTION

IN the past decades, various security-enhanced measures have been

proposed to improve the security of data transmission over public networks.

Existing work on security-enhanced data transmission includes the designs

of cryptography algorithms and system infrastructures and security-

enhanced routing methods. Their common objectives are often to defeat

various threats over the Internet, including eavesdropping, spoofing, session

hijacking, etc.

Among many well-known designs for cryptography based systems,

the IP Security (IPSec) [23] and the Secure Socket Layer (SSL) [21] are

popularly supported and implemented in many systems and platforms.

Although IPSec and SSL do greatly improve the security level for data

transmission, they unavoidably introduce substantial overheads especially on

gateway/host performance and effective network bandwidth. For example,

the data transmission overhead is 5 cycles/byte over an Intel Pentium II with

the Linux IP stack alone, and the overhead increases to 58 cycles/byte when

Advanced Encryption Standard (AES) is adopted for encryption/decryption

for IPSec.

Another alternative for security-enhanced data transmission is to

dynamically route packets between each source and its destination so that


3/121

the chance for system break-in, due to successful interception of consecutive

packets for a session, is slim. The intention of security-enhanced routing is

different from the adopting of multiple paths between a source and a

destination to increase the throughput of data transmission .In particular,

Lou et al. proposed a secure routing protocol to improve the security of end-

to-end data transmission based on multiple path deliveries. The set of

multiple paths between each source and its destination is determined in an

online fashion, and extra control message exchanging is needed. Bohacek et

al. proposed a secure stochastic routing mechanism to improve routing

security. Similar to the work proposed by Lou et ala set of paths is

discovered for each source and its destination in an online fashion based on

message flooding. Thus, a mass of control messages is needed. Yang and

Papavassiliou explored the trading of the security level and the traffic

dispersion. They proposed a traffic dispersion scheme to reduce the

probability of eavesdropped information along the used paths provided that

the set of data delivery paths is discovered in advance. Although excellent

research results have been proposed for security-enhanced dynamic routing,

many of them rely on the discovery of multiple paths either in an online or

offline fashion. For those online path searching approaches, the discovery of

multiple paths involves a significant number of control signals over the

Internet. On the other hand, the discovery of paths in an offline fashion

might not be suitable to networks with a dynamic changing configuration.

Therefore, we will propose a dynamic routing algorithm to provide security

enhanced data delivery without introducing any extra control messages.


4/121

OBJECTIVE:

The objective of this work is to explore a security enhanced dynamic

routing algorithm based on distributed routing information widely supported

in existing wired and wireless networks. We aim at the randomization of

delivery paths for data transmission to provide considerably small path

similarity (i.e., the number of common links between two delivery paths) of

two consecutive transmitted packets. The proposed algorithm should be easy

to implement and compatible with popular routing protocols, such as the

Routing Information Protocol (RIP) for wired networks and Destination-

Sequenced Distance Vector (DSDV) protocol for wireless networks, over

existing infrastructures. These protocols shall not increase the number of

control messages if the proposed algorithm is adopted. An analytic study

will be presented for the proposed routing algorithm, and a series of

simulation study will be conducted to verify the analytic results and to show

the capability of the proposed algorithm.


5/121

HARDWARE AND SOFTWARE SPECIFICATIONS

HARDWARE SPECIFICATION

The hardware used for the development of the project is:

SYSTEM : Pentium IV 2.4 GHz

HARD DISK : 40 GB

FLOPPY DRIVE : 1.44 MB

MONITOR : 15 VGA colour

MOUSE : Logitech.

RAM : 256 MB

KEYBOARD : 110 keys enhanced.

SOFTWARE REQUIREMENTS

The software used for the development of the project is:

Operating system : Windows XP Professional

Front End : JAVA

Back End : MS-Access


6/121

DESIGN OVERVIEW:

Design involves identification of classes, their

relationships as well as their collaboration. In objectory, classes are

divided into entity classes, interface classes and control classes. The

Computer Aided Software Engineering(CASE) tools that are available

commercially do not provide any assistance in this transition. CASE

tools take advantage of meta modeling that are helpful only after the

construction of the class diagram. In the Fusion method, some object-

oriented approaches like Object Modeling Technique(OMT), Classes,

Responsibilities, Collaborators(CRC),etc, are used. Objectory used the

term agents to represent some of the hardware and software systems

.In Fusion method, there is no requirement phase, where a user will

supply the initial requirement document. Any software project is

worked out by both the analyst and the designer. The analyst creates

the use case diagram. The designer creates the class diagram. But the

designer can do this only after the analyst creates the use case

diagram. Once the design is over, it is essential to decide which

software is suitable for the application.


7/121

Problem Analysis:

IN the past decades, various security-enhanced measures have

been proposed to improve the security of data transmission over

public networks. Existing work on security-enhanced data

transmission includes the designs of cryptography algorithms and

system infrastructures and security-enhanced routing methods. Their

common objectives are often to defeat various threats over the

Internet, including eavesdropping, spoofing, session hijacking, etc.

Among many well-known designs for cryptography based systems,

the IP Security (IPSec) and the Secure Socket Layer (SSL) are


Although IPSec and SSL do greatly improve the security level for

data transmission, they unavoidably introduce substantial overheads

especially on gateway/host performance and effective network

bandwidth. For example, the data transmission overhead is 5

cycles/byte over an Intel Pentium II with the Linux IP stack alone, and

the overhead increases to 58 cycles/byte when Advanced Encryption

Standard (AES) is adopted for encryption/decryption for IPSec .

The objective of this work is to explore a security-enhanced

dynamic routing algorithm based on distributed routing information

widely supported in existing networks. In general, routing protocols

over networks could be classified roughly into two kinds: distance-

vector algorithms and link-state algorithms. Distance-vector

algorithms rely on the exchanging of distance information among

neighboring nodes for the seeking of routing paths. Examples of

distance-vector-based routing algorithms include RIP and DSDV.

Link-state algorithms used in the Open Shortest Path First protocol


8/121

are for global routing in which the network topology is known by all

nodes. Our goal is to propose a distance-vector-based algorithm for

dynamic routing to improve the security of data transmission.

Proposed Solution:

The DDRA proposed in this paper consists of two parts: 1) a

randomization process for packet deliveries and 2) maintenance of the

extended routing table.

Consider the delivery of a packet with the destination t at a node Ni.

In order to minimize the probability that packets are eavesdropped

over a specific link, a randomization process for packet deliveries

shown in Procedure 1 is adopted. In this process, the previous next

hop hs (defined in HN t of Table 1b) for the source node s is identified

in the first step of the process. Then, the process randomly picks up a

neighboring node in CNi t excluding hs as the next hop for the current

packet transmission. The exclusion of hs for the next hop selection

avoids transmitting two consecutive packets in the same link, and the

randomized pickup prevents attackers from easily predicting routing

paths for the coming transmitted packets.

Let every node in the network be given a routing table and a

link table. We assume that the link table of each node is constructed

by an existing link discovery protocol, such as the Hello protocol in.

On the other hand, the An Example of the Routing Table for the Node

Ni (a) The routing table for the original distance-vector-based routing


9/121

algorithm. (b) The routing table for the proposed security-enhanced

routing algorithm.

Construction and maintenance of routing tables are revised based on

the well-known Bellman-Ford algorithm [4] and described as follows:

By exchanging distance vectors between neighboring nodes, the

routing table of Ni is accordingly updated. Note that the exchanging

for distance vectors among neighboring nodes can be based on a

predefined interval. The exchanging can also be triggered by the

change of link cost or the failure of the link/node. In this paper, we

consider cases when Ni receives a distance vector from a neighboring

node Nj. Each element of a distance vector received from a

neighboring nodeNj includes a destination node t and a delivery

costWNj; t from the nodeNj to the destination node t.

Let hs be the used next hop for the previous packet delivery for the

source node s.

2: if hs < |CN| t then

3: if j < |CNi| t j > 1 then

4: Randomly choose a node x from (CNi t _ hs) as a next hop, and

send the packet pkt to the node x.

5: hs


10/121

10: Randomly choose a node y from CNi

t as a next hop, and send the packet pkt to the node y.

11: hs y, and update the routing table of Ni.

12: end if

The number of entries in the history record for packet deliveries to

destination nodes is jNj in the worst case. In order to efficiently look

up the history record for a destination node, we maintain the history

record for each node in a hash table. Before the current packet is sent

to its destination node, we must randomly pick up a neighboring node

excluding the used node for the previous packet. Once a neighboring

node is selected, by the hash table, we need O1 to determine

whether the selected neighboring node for the current packet is the

same as the one used by the previous packet. Therefore, the time

complexity of searching a proper neighboring node is ologn


11/121

1.2. ORGANIZATION PROFILE

SOFTWARE SOLUTIONS

EdwareUK Ltd is an IT solution provider for a dynamic environment

where business and technology strategies converge. Their approach focuses

on new ways of business combining IT innovation and adoption while also

leveraging an organizations current IT assets. Their work with large global

corporations and new products or services and to implement prudent

business and technology strategies in todays environment.

EdwareUK LTD S RANGE OF EXPERTISE INCLUDES:

Software Development Services

Engineering Services

Systems Integration

Customer Relationship Management

Product Development

Electronic Commerce

Consulting

IT Outsourcing

We apply technology with innovation and responsibility to achieve two

broad objectives:

Effectively address the business issues our customers face today.

Generate new opportunities that will help them stay ahead in the

future.


12/121

THIS APPROACH RESTS ON:

A strategy where we architect, integrate and manage technology

services and solutions - we call it AIM for success.

A robust offshore development methodology and reduced demand on

customer resources.

A focus on the use of reusable frameworks to provide cost and times

benefits.

They combine the best people, processes and technology to achieve

excellent results - consistency. We offer customers the advantages of:

SPEED:

They understand the importance of timing, of getting there before the

competition. A rich portfolio of reusable, modular frameworks helps jump-start projects. Tried and tested methodology ensures that we follow a

predictable, low - risk path to achieve results. Our track record is testimony

to complex projects delivered within and evens before schedule.

EXPERTISE:

Our teams combine cutting edge technology skills with rich domain

expertise. Whats equally important - they share a strong customer

orientation that means they actually start by listening to the customer.

Theyre focused on coming up with solutions that serve customer

requirements today and anticipate future needs.


13/121

A FULL SERVICE PORTFOLIO:

They offer customers the advantage of being able to Architect,

integrate and manage technology services. This means that they can rely on

one, fully accountable source instead of trying to integrate disparate multi

vendor solutions.

SERVICES:

EdwareUK LTD is providing its services to companies which are in

the field of production, quality control etc With their rich expertise and

experience and information technology they are in best position to provide

software solutions to distinct business requirements.


14/121

PROBLEM ANALYSIS

3.1 EXISTING SYSTEM

IN the past decades, various security-enhanced measures have been

proposed to improve the security of data transmission over public networks.

Existing work on security-enhanced data transmission includes the designs

of cryptography algorithms and system infrastructures and security-

enhanced routing methods. Their common objectives are often to defeat

various threats over the Internet, including eavesdropping, spoofing, session

hijacking, etc. Among many well-known designs for cryptography based

systems, the IP Security (IPSec) and the Secure Socket Layer (SSL) are


Although IPSec and SSL do greatly improve the security level for data

transmission, they unavoidably introduce substantial overheads especially on

gateway/host performance and effective network bandwidth.

Disadvantages:

Number of Retransmission is high.

Cost is high to implement a cryptographic technique.

eavesdropping is easily occur.


15/121

Proposed System:

The objective of this work is to explore a security enhanced dynamic

routing algorithm based on distributed routing information widely supported

in existing wired and wireless networks. We aim at the randomization of

delivery paths for data transmission to provide considerably small path

similarity (i.e., the number of common links between two delivery paths) of

two consecutive transmitted packets. The proposed algorithm should be easyto implement and compatible with popular routing protocols, such as the

Routing Information Protocol (RIP) for wired networks and Destination-

Sequenced Distance Vector (DSDV) protocol for wireless networks over

existing infrastructures. These protocols shall not increase the number of

control messages if the proposed algorithm is adopted. An analytic study

will be presented for the proposed routing algorithm, and a series of

simulation study will be conducted to verify the analytic results and to show

the capability of the proposed algorithm.

Advantages:

Cost is low compare to cryptographic technique.

Its applicable for wired and wireless networks.

Number of retransmission is less.


16/121

2. MODULES

Topology Construction:

In this module, we construct a topology structure.

Here we use mesh topology because of its unstructured nature.

Topology is constructed by getting the names of the nodes and the

connections among the nodes as input from the user.

While getting each of the nodes, their associated port and ip address is

also obtained.

For successive nodes, the node to which it should be connected is also

accepted from the user.

While adding nodes, comparison will be done so that there would be

no node duplication.

Then we identify the source and the destinations.


17/121

Node

Check

AvailableNodeInfo

Update NodeInfo

AlreadyAvailable

Random Path Selection Algorithm:

Randomization Process Consider the delivery of a packet with the

destination t at a node Ni. In order to minimize the probability that packets

are eavesdropped over a specific link, a randomization process for packet

deliveries shown in Procedure 1 is adopted. In this process, the previous next

hop hs (defined in HNi t of Table 1b) for the source node s is identified in


18/121

the first step of the process (line 1). Then, the process randomly picks up a

neighboring node in CNi t excluding hs as the next hop for the current

packet transmission. The exclusion of hs for the next hop selection avoids

transmitting two consecutive packets in the same link, and the randomized

pickup prevents attackers from easily predicting routing paths for the

coming transmitted packets.

The number of entries in the history record for packet deliveries to

destination nodes is jNj in the worst case. In order to efficiently look up the

history record for a destination node, we maintain the history record for each

node in a hash table. Before the current packet is sent to its destination node,

we must randomly pick up a neighboring node excluding the used node for

the previous packet. Once a neighboring node is selected, by the hash table,

we need O1 to determine whether the selected neighboring node for the

current packet is the same as the one used by the previous packet.


19/121

Select Random Path :

NodeLogin

select

Destination

choose

nexthposnexthhops

compare

with previouspaths

equalnot equal

update


20/121

MESSAGE TRANSMISSION:

In this module we transmit the message to the destination. Based on

the random path selection algorithm here we transmit the message. For each

packet transmission the path and the packets are updated in the routing table.

Nodelogin

select

Destination

randompath paths

transmit

message


21/121

ROUTING TABLE MAINTENANCE:

In this module we can maintain the routing table; here we add one

more column to maintain the packet delivery ratio. In this one we can

maintain how many packets are transmitted over each path. It will be useful

for to identify any path can handle number packets. We can stop

transmission some amount of time period over that path. So the hacker

cannot identify in which path the message is transmitted and also we can

easily transmit the data securely.

Login

Message

transmission

update

path destils DB


22/121

SYSTEM ANALYSIS

2.1 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 somecost 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


23/121

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


24/121

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.

SOFTWARE PROFILE

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


25/121

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

calledJava 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.

FIGURE 2- WORKING OF JAVA

You can think of Java bytecodes as the machine code instructions for

theJava Virtual Machine (Java VM). Every Java interpreter, whether its a

development tool or a Web browser that can run applets, is an

implementation of the Java VM. Java bytecodes help make write once, run

anywhere possible. You can compile your program into bytecodes on any

platform that has a Java compiler. The bytecodes 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.


26/121

The Java Platform

A platform is the hardware or software environment in which a

program runs. Weve 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 its a software-only

platform that runs on top of other hardware-based platforms.

The Java platform has two components:

TheJava Virtual Machine (Java VM)

TheJava Application Programming Interface (Java API)

Youve already been introduced to the Java VM. Its 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 thats running on the Java

platform. As the figure shows, the Java API and the virtual machine insulate

the program from the hardware.

FIGURE 3- THE JAVA PLATFORM


27/121

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 bytecode 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 youve surfed the Web, youre

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.


28/121

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

packages of software components that provide 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.


29/121

FIGURE 4 JAVA 2 SDK

SWING

The Swing toolkit includes a rich set of components for

building GUIs and adding interactivity to Java applications. Swing includes

all the components you would expect from a modern toolkit: table controls,

list controls, tree controls, buttons, and labels. Swing is far from a simple

component toolkit, however. It includes rich undo support, a highlycustomizable text package, integrated internationalization and accessibility

support. To truly leverage the cross-platform capabilities of the Java

platform, Swing supports numerous look and feels, including the ability to

create your own look and feel. The ability to create a custom look and feel is

made easier with Synth, a look and feel specifically designed to be

customized. Swing wouldn't be a component toolkit without the basic user

interface primitives such as drag and drop, event handling, customizable

painting, and window management.


30/121

Swing is part of the Java Foundation Classes (JFC). The JFC also include

other features important to a GUI program, such as the ability to add rich

graphics functionality and the ability to create a program that can work in

different languages and by users with different input devices.

The Swing toolkit includes a rich array of components: from basic

components, such as buttons and check boxes, to rich and complex

components, such as tables and text. Even deceptively simple components,

such as text fields, offer sophisticated functionality, such as formatted text

input or password field behavior. There are file browsers and dialogs to suit

most needs, and if not, customization is possible. If none of Swing's

provided components are exactly what you need, you can leverage the basic

Swing component functionality to create your own.

Swing components contain a pluggable look and feel (PL & F). This

allows all applications to run with the native look and feel on different

platforms. PL & F allows applications to have the same behaviour on

various platforms. JFC contains operating system neutral look and feel.

Swing components do not contain peers. Swing components allow

mixing AWT heavyweight and Swing lightweight components in an

application.

The major difference between lightweight and heavyweight

components is that lightweight components can have transparent pixels

while heavyweight components are always opaque. Lightweight

components can be non-rectangular while heavyweight components are

always rectangular.


31/121

Swing components are JavaBean compliant. This allows

components to be used easily in a Bean aware application building

program. The root of the majority of the Swing hierarchy is the

JComponent class. This class is an extension of the AWT Container

class.

Swing components comprise of a large percentage of the JFC

release. The Swing component toolkit consists of over 250 pure Java

classes and 75 Interfaces contained in about 10 Packages. They are used

to build lightweight user interfaces. Swing consists of User Interface (UI)

classes and non- User Interface classes. The non-User Interface classes

provide services and other operations for the UI classes.

Swing offers a number of advantages, which include

Wide variety of Components

Pluggable Look and Feel

MVC Architecture

Keystroke Handling

Action Objects

Nested Containers

Virtual Desktops

Compound Borders

Customized Dialogues

Standard Dialog Classes

Structured Table and Tree Components


32/121

Powerful Text Manipulation

Generic Undo Capabilities

Accessibility Support

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 muchmore 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


33/121

database. The physical database referred to by a data source can reside

anywhere on the LAN.

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.

From a programming perspective, the beauty of ODBC is that the

application can be written to use the same set of function calls to interface

with any data source, regardless of the database vendor. The source code of

the application doesnt change whether it talks to Oracle or SQL Server. We

only mention these two as an example. There are ODBC drivers available

for several dozen popular database systems. Even Excel spreadsheets and

plain text files can be turned into data sources. The operating system uses

the Registry information written by ODBC Administrator to determine

which low-level ODBC drivers are needed to talk to the data source (such as

the interface to Oracle or SQL Server). The loading of the ODBC drivers is

transparent to the ODBC application program. In a client/server

environment, the ODBC API even handles many of the network issues for

the application programmer.

The advantages of this scheme are so numerous that you are probably

thinking there must be some catch. The only disadvantage of ODBC is that it

isnt as efficient as talking directly to the native database interface. ODBC


34/121

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

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, ordrivers. 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 JDBCs 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.


35/121

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:

1. 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 JDBCs complexities from the end user.

2. 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.


36/121

3. 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.

4. Provide a Java interface that is consistent with the rest of the Java

system

Because of Javas acceptance in the user community thus far, the designers

feel that they should not stray from the current design of the core Java

system.

5. 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.

6. 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.

7. Keep the common cases simple

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

programmer are simple SELECTs, INSERTs, DELETEs and UPDATEs,

these queries should be simple to perform with JDBC. However, more

complex SQL statements should also be possible.


37/121

Networking

TCP/IP stack

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

FIGURE 5 TCP/IP STACK

TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a

connectionless protocol.

IP datagrams

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


38/121

Internet. It is also responsible for breaking up large datagram into smaller

ones for transmission and reassembling them at the other end.

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 address

Class 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.


39/121

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

FIGURE 6 - IP ADDRESSING

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

Port addresses

A 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".

Sockets

A 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.


40/121

#include

#include

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.

Create a server socket that listens for a client to connect

socket(int af, int type, int protocol)

This method creates the socket

bind(SOCKET s, const struct sockaddr FAR * name, int namelen)

Associates a local address with a socket. This routine is used on an

unconnected datagram or stream socket, before subsequent connects or

listens. When a socket is created with socket, it exists in a name space

(address family), but it has no name assigned. bind establishes the localassociation (host address/port number) of the socket by assigning a local

name to an unnamed socket. In the Internet address family, a name consists

of several components. ForSOCK_DGRAM and SOCK_STREAM, the name

consists of three parts: a host address, the protocol number (set implicitly to

UDP or TCP, respectively), and a port number which identifies the

application. If an application does not care what address is assigned to it, it

may specify an Internet address equal to INADDR_ANY, a port equal to 0, or

both. If the Internet address is equal to INADDR_ANY, any appropriate

network interface will be used; this simplifies application programming in

the presence of multi- homed hosts. If the port is specified as 0, the


41/121

Windows Sockets implementation will assign a unique port to the

application with a value between 1024 and 5000. The application may use

getsockname afterbind to learn the address that has been assigned to it,

but note that getsockname will not necessarily fill in the Internet address

until the socket is connected, since several Internet addresses may be valid if

the host is multi-homed. If no error occurs, bind returns 0. Otherwise, it

returns SOCKET_ERROR, and a specific error code may be retrieved by

calling WSAGetLastError.

listen(SOCKET s, int backlog )

Establishes a socket to listen to a incoming connection To accept

connections, a socket is first created with socket, a backlog for incoming

connections is specified with listen, and then the connections are

accepted with accept. listen applies only to sockets that support

connections, i.e. those of type SOCK_STREAM. The socket s is put into

"passive'' mode where incoming connections are acknowledged and queued

pending acceptance by the process. This function is typically used by servers

that could have more than one connection request at a time: if a connection

request arrives with the queue full, the client will receive an error with an

indication of WSAECONNREFUSED. listen attempts to continue to

function rationally when there are no available descriptors. It will accept

connections until the queue is emptied. If descriptors become available, a

later call to listen oraccept will re-fill the queue to the current or mostrecent "backlog'', if possible, and resume listening for incoming connections.

accept (SOCKET s, struct sockaddr FAR * addr, int FAR * addrlen)

This routine extracts the first connection on the queue of pending

connections on s, creates a new socket with the same properties as s and


42/121

returns a handle to the new socket. If no pending connections are present on

the queue, and the socket is not marked as non- blocking, accept blocks

the caller until a connection is present. If the socket is marked non-blocking

and no pending connections are present on the queue, accept returns an

error as described below. The accepted socket may not be used to accept

more connections. The original socket remains open. The argument addr is

a result parameter that is filled in with the address of the connecting entity,

as known to the communications layer. The exact format of the addr

parameter is determined by the address family in which the communication

is occurring.

The addrlen is a value-result parameter; it should initially contain the

amount of space pointed to by addr; on return it will contain the actual

length (in bytes) of the address returned. This call is used with connection-

based socket types such as SOCK_STREAM. If addr and/oraddrlen are

equal to NULL, then no information about the remote address of the accepted

socket is returned.

closesocket(SOCKET s)

closes a socket

Making client connection with server

In order to create a socket that connects to an other socket uses most of the

functions from the previous code with the exception of a struct called

HOSTENT .

HOSTENT:

This struct is used to tell the This struct is used to tell the socket to which

computer and port to connect to. These struct can appear as LPHOSTENT,

but it actually means that they are pointer to HOSTENT.


43/121

Client key function

Most of the functions that have been used for the client to connect to the

server are the same as the server with the exception of a few. I will just go

through the different functions that have been used for the client.

gethostbyname(const char* FAR name)

gethostbyname returns a pointer to a hostent structure as described

undergethostbyaddr. The contents of this structure correspond to the

hostname name. The pointer which is returned points to a structure which is

allocated by the Windows Sockets implementation. The application must

never attempt to modify this structure or to free any of its components.Furthermore, only one copy of this structure is allocated per thread, and so

the application should copy any information which it needs before issuing

any other Windows Sockets API calls. A gethostbyname

implementation must not resolve IP address strings passed to it. Such a

request should be treated exactly as if an unknown host name were passed.

An application with an IP address string to resolve should use inet_addr

to convert the string to an IP address, then gethostbyaddr to obtain the

hostent structure.

Part 2 - Send / recieve

Up to this point we have managed to connect with our client to the server.

Clearly this is not going to be enough in a real-life application. In this

section we are going to look into more details how to use the send/recv

functions in order to get some communication going between the two

applications.

Factually this is not going to be difficult because most of the hard work has

been done setting up the server and the client app. before going into the code


44/121

we are going to look into more details the two functions send(SOCKET s,

const char FAR * buf, int len, int flags) send is used on connected

datagram or stream sockets and is used to write outgoing data on a socket.

For datagram sockets, care must be taken not to exceed the maximum IP

packet size of the underlying subnets, which is given by the iMaxUdpDg

element in the WSAData structure returned by WSAStartup.

If the data is too long to pass atomically through the underlying protocol the

errorWSAEMSGSIZE is returned, and no data is transmitted.

recv(SOCKET s, const char FAR * buf, int len, int flags)

For sockets of type SOCK_STREAM, as much information as is currently

available up to the size of the buffer supplied is returned. If the socket has

been configured for in- line reception of out-of-band data (socket option

SO_OOBINLINE) and out-of-band data is unread, only out-of-band data

will be returned. The application may use the ioctlsocket

SIOCATMARK to determine whether any more out-of-band data remains to

be read.

part 3 - Read unknow size of data from client

Us mentioned earlier in part 2, we are going to expand on the way that we

receive data. The problem we had before is that if we did not know the size

of data that we where expecting, then the would end up with problems.

In order to fix this here we create a new function that receive a pointer to the

client socket, and then read a char at the time, placing each char into a vector

until we find the '\n' character that signifies the end of the message.

This is early not a robust or industrial way the read data from one socket to

an other, because but its a way to start reading unknown length strings. The

function will be called after the accept method.


45/121

5.4. TABLE DESIGN

Tables are logical structures maintained by the databasemanager. Tables are made up of columns and rows.

At the intersection of every column and row is a specific data

item called a value. A column is a set of values of the same type

or one of its subtypes. A row is a sequence of values arranged

so that the nth value is a value of the nth column of the table.

An application program can determine the order in which the

rows are populated into the table, but the actual order of rows is

determined by the database manager, and typically cannot be

controlled. Multidimensional clustering (MDC) provides some

sense of clustering, but not actual ordering between the rows.

When designing tables, you need to be familiar with certain

concepts, determine the space requirements for tables and user

data, and determine whether you will take advantage of certain

features, such as space compression and optimistic locking.

When designing partitioned tables, you need to be familiar with the

partitioning concepts, such as:

Data organization schemes

Table partitioning keys

Keys used for distributing data across data partitions

Keys used for MDC dimensions


46/121

ARCHITECTURE OF JDBC:

JDBC Architecture contains three layers:

Application Layer: Java program wants to get a connection to a database. It

needs the information from the database to display on the screen or to

modify the existing data or to insert the data into the table.

Driver Manager: The layer is the backbone of the JDBC architecture. When

it receives a connection-request form.

The JDBC Application Layer: It tries to find the appropriate driver by

iterating through all the available drivers, which are currently registered with

Device Manager. After finding out the right driver it connects the

application to appropriate database.

JDBC Driver layers: This layer accepts the SQL calls from the application

and converts them into native calls to the database and vice-versa. A JDBC

Driver is responsible for ensuring that an application has consistent and

uniform access to any database.When a request received by the application,

JDBC Application

JDBC Drivers

JDBC Drivers


47/121

the JDBC driver passes the request to the ODBC driver, the ODBC driver

communicates with the database and sends the request and gets the results.

The results will be passed to the JDBC driver and in turn to the application.

So, the JDBC driver has no knowledge about the actual database, it knows

how to pass the application request o the ODBC and get the results from the

ODBC.

The JDBC and ODBC interact with each other, how? The reason is

both the JDBC API and ODBC are built on an interface called Call LevelInterface (CLI). Because of this reason the JDBC driver translates the

request to an ODBC call. The ODBC then converts the request again and

presents it to the database. The results of the request are then fed back

through the same channel in reverse.

Structured Query Language (SQL):

SQL (Pronounced Sequel) is the programming language that defines and

manipulates the database. SQL databases are relational databases; this means

simply the data is store in a set of simple relations. A database can have one

or more table. You can define and manipulate data in a table with SQL

commands. You use the data definition language (DDL) commands to

creating and altering databases and tables.


48/121

You can update, delete or retrieve data in a table with data manipulation

commands (DML). DML commands include commands to alter and fetch

data.

The most common SQL commands include commands is the SELECT

command, which allows you to retrieve data from the database.

In addition to SQL commands, the oracle server has a procedural

language called PL/SQL. PL/SQL enables the programmer to program SQL

statement. It allows you to control the flow of a SQL program, to use

variables, and to write error-handling procedures


49/121

SYSTEM ARCHITECTURE:

The process of the design implemented with the system architecture

view comprises of the parts of the project work that encapsulates all

modules ranging from module to module communication, setting

initializations and system.


50/121

Data Flow Diagram:

The Data Flow diagram is a graphic tool used for expressing system

requirements in a graphical form. The DFD also known as the bubble

chart has the purpose of clarifying system requirements and

identifying major transformations that to become program in system

design.

Thus DFD can be stated as the starting point of the design phase that

functionally decomposes the requirements specifications down to the

lowest level of detail.

The DFD consists of series of bubbles joined by lines. The bubbles

represent data transformations and the lines represent data flows in the

system. A DFD describes what data flow is rather than how they are

processed, so it does not depend on hardware, software, data structure

or file organization.


51/121

Source

Choose

Destination

RandomPath Check DatabaseData

Store

Transfer

Message

5.6 Use case diagram:

A use case diagram in the Unified Modeling Language (UML) is a

type of behavioral diagram defined by and created from a Use-case

analysis. Its purpose is to present a graphical overview of the

functionality provided by a system in terms of actors, their goals

(represented as use cases), and any dependencies between those use

cases.

The main purpose of a use case diagram is to show what system

functions are performed for which actor. Roles of the actors in the

system can be depicted.


52/121

Dynamic Security

Topology Construction

RandomPath Selection

Message Transmission

Routing Table Maintance


53/121

Class Diagram:

Class diagrams are the mainstay of object-oriented analysis and

design. Class diagrams show the classes of the system, their

interrelationships (including inheritance, aggregation, and association), and

the operations and attributes of the classes. Class diagrams are used for a

wide variety of purposes, including both conceptual/domain modeling and

detailed design modeling.

TopologyConstruction

nodeName

nodeIp

nodePort

getNodeInfo()

updateNodeInfo()

RandomPathSelection

destName

prevPath

getAvailPaths()

selectRandomPaths()

routingTableUpdation()

TransmitMessage

destName

destIp

destPort

prevPath

removePreviousPath()

messageTransmission()

getAck()


54/121

Sequence Diagram:

A sequence diagram in Unified Modeling Language (UML) is a kind

of interaction diagram that shows how processes operate with one

another and in what order. It is a construct of a Message Sequence

Chart.

Sequence diagrams are sometimes called Event-trace diagrams, event

scenarios, and timing diagrams.

A sequence diagram shows, as parallel vertical lines (lifelines),

different processes or objects that live simultaneously, and, as

horizontal arrows, the messages exchanged between them, in the order

in which they occur. This allows the specification of simple runtime

scenarios in a graphical manner.


55/121

SourceSource Select

Destination

Select

Destination

Routing TableRouting Table Random PathRandom Path Message

Transmisson

Message

Transmisson

select

path selection

Random Path

compare with previous path

Transmit mess age


56/121

Colloboration Diagram

Source Select

Destination

Routing

Table

Random

Path

Message

Transmisson

3: Random Path4: compare

1: select 2: path selection

5: Transmit


57/121

Activity Diagram:

Activity diagrams are typically used for business process modeling, for

modeling the logic captured by a single use case or usage scenario, or for

modeling the detailed logic of abusiness rule. Although UML activity

diagrams could potentially model the internal logic of a complex operation it

would be far better to simply rewrite the operation so that it is simple

enough that you dont require an activity diagram. In many ways UML

activity diagrams are the object-oriented equivalent offlow charts and data

flow diagrams (DFDs) from structured development.
http://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/businessRule.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/businessRule.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htm


58/121

Login

select

destination

select

random path

next

neighbour

compare

Transmit

goto

selection

yes

No


59/121

6. TESTING AND IMPLEMENTATION

TESTING PROCESS

The purpose of testing is to discover errors. Testing is the process of

trying to discover every conceivable fault or weakness in a work product. It

provides a way to check the functionality of components, sub assemblies,assemblies and/or a finished product It is the process of exercising software

with the intent of ensuring that the Software system meets its requirements

and user expectations and does not fail in an unacceptable manner. There are

various types of test. Each test type addresses a specific testing requirement.

TYPES OF TESTS

UNIT TESTING

Unit testing involves the design of test cases that validate that the

internal program logic is functioning properly, and that program input

produces valid outputs. All decision branches and internal code flow should

be validated. It is the testing of individual software units of the application

.it is done after the completion of an individual unit before integration. This

is a structural testing, that relies on knowledge of its construction and is

invasive. Unit tests perform basic tests at component level and test a specific

business process, application, and/or system configuration. Unit tests ensure


60/121

that each unique path of a business process performs accurately to the

documented specifications and contains clearly defined inputs and expected

results.

INTEGRATION TESTING

Integration tests are designed to test integrated software components

to determine if they actually run as one program. Testing is event driven

and is more concerned with the basic outcome of screens or fields.

Integration tests demonstrate that although the components were

individually satisfaction, as shown by successfully unit testing, the

combination of components is correct and consistent. Integration testing is

specifically aimed at exposing the problems that arise from the

combination of components.

FUNCTIONAL TESTING

Functional tests provide systematic demonstrations that functions

tested are available as specified by the business and technical requirements,

system documentation and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must beexercised

Systems/Procedures : interfacing systems or procedures must be invoked.


61/121

Organization and preparation of functional tests is focused on

requirements, key functions, or special test cases. In addition, systematic

coverage pertaining to identify Business process flows; data fields,

predefined processes, and successive processes must be considered for

testing. Before functional testing is complete, additional tests are identified

and the effective value of current tests is determined.

SYSTEM TESTING

System testing ensures that the entire integrated software system meets

requirements. It tests a configuration to ensure known and predictable

results. An example of system testing is the configuration oriented system

integration test. System testing is based on process descriptions and flows,

emphasizing pre-driven process links and integration points.

BOX TESTING

White Box Testing is a testing in which the software tester has

knowledge of the inner workings, structure and language of the software, or

at least its purpose. It is used to test areas that cannot be reached from a

black box level.

BLACK BOX TESTING

Black Box Testing is testing the software without any knowledge of

the inner workings, structure or language of the module being tested. Black

box tests, as most other kinds of tests, must be written from a definitive

source document, such as specification or requirements document, such as


62/121

specification or requirements document. It is a testing in which the software

under test is treated, as a black box .you cannot see into it. The test

provides inputs and responds to outputs without considering how the

software works.

UNIT TESTING

Unit testing is usually conducted as part of a combined code and unit

test phase of the software lifecycle, although it is not uncommon for coding

and unit testing to be conducted as two distinct phases.

TEST STRATEGY AND APPROACH

Field testing will be performed manually and functional tests will be

written in detail.

Test objectives

All field entries must work properly.

Pages must be activated from the identified link.

The entry screen, messages and responses must not be delayed.

Features to be tested

Verify that the entries are of the correct format

No duplicate entries should be allowed

All links should take the user to the correct page.

Integration Testing


63/121

Software integration testing is the incremental integration testing of

two or more integrated software components on a single platform to produce

failures caused by interface defects.

The task of the integration test is to check that components or

software applications, e.g. components in a software system or one step up

software applications at the company level interact without error.

Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires

significant participation by the end user. It also ensures that the system

meets the functional requirements.

Test Results

All the test cases mentioned above passed successfully. No defects

encountered.


64/121

IMPLEMENTATION DISCUSSION

IMPLEMENTATION

Routing is the task of finding a path from a sender to a desired destination.

In the IP "Catenet model" this reduces primarily to a matter of finding

gateways between networks. As long as a message remains on a single

network or subnet, any routing problems are solved by technology that is

specific to the network. For example, the Ethernet and the ARPANET each

define a way in which any sender can talk to any specified destination within

that one network. IP routing comes in primarily when messages must go

from a sender on one such network to a destination on a different one. In that

case, the message must pass through gateways connecting the networks. If

the networks are not adjacent, the message may pass through several

intervening networks, and the gateways connecting them. Once the message

gets to a gateway that is on the same network as the destination, that

network's own technology is used to get to the destination.

Throughout this section, the term "network" is used generically to cover a

single broadcast network (e.g., an Ethernet), a point to point line, or theARPANET. The critical point is that a network is treated as a single entity

by IP. Either no routing is necessary (as with a point to point line), or that

routing is done in a manner that is transparent to IP, allowing IP to treat the

entire network as a single fully-connected system (as with an Ethernet or the

ARPANET). Note that the term "network" is used in a somewhat different

way in discussions of IP addressing. A single IP network number may be

assigned to a collection of networks, with "subnet" addressing being used to

describe the individual networks. In effect, we are using the term "network"

here to refer to subnets in cases where subnet addressing is in use.

A number of different approaches for finding routes between networks are

possible. One useful way of categorizing these approaches is on the basis of

the type of information the gateways need to exchange in order to be able to

find routes. Distance vector algorithms are based on the exchange of only a

small amount of information. Each entity (gateway or host) that participates

in the routing protocol is assumed to keep information about all of the


65/121

destinations within the system. Generally, information about all entities

connected to one network is summarized by a single entry, which describes

the route to all destinations on that network. This summarization is possible

because as far as IP is concerned, routing within a network is invisible. Each

entry in this routing database includes the next gateway to which datagrams

destined for the entity should be sent. In addition, it includes a "metric"

measuring the total distance to the entity. Distance is a somewhat

generalized concept, which may cover the time delay in getting messages to

the entity, the dollar cost of sending messages to it, etc. Distance vector

algorithms get their name from the fact that it is possible to compute optimal

routes when the only information exchanged is the list of these distances.

Furthermore, information is only exchanged among entities that are adjacent,

that is, entities that share a common network.

Although routing is most commonly based on information about networks, itis sometimes necessary to keep track of the routes to individual hosts. The

RIP protocol makes no formal distinction between networks and hosts. It

simply describes exchange of information about destinations, which may be

either networks or hosts. (Note however, that it is possible for an

implementor to choose not to support host routes. See section 3.2.) In fact,

the mathematical developments are most conveniently thought of in terms of

routes from one host or gateway to another. When discussing the algorithm

in abstract terms, it is best to think of a routing entry for a network as an

abbreviation for routing entries for all of the entities connected to that

network. This sort of abbreviation makes sense only because we think of

networks as having no internal structure that is visible at the IP level. Thus,

we will generally assign the same distance to every entity in a given

network.

We said above that each entity keeps a routing database with one entry for

every possible destination in the system. An actual implementation is likely

to need to keep the following information about each destination:

address: in IP implementations of these algorithms, this will be the IPaddress of the host or network.

gateway: the first gateway along the route to the destination.

interface: the physical network which must be used to reach the first

gateway.

metric: a number, indicating the distance to the destination.

timer: the amount of time since the entry was last updated.


66/121

In addition, various flags and other internal information will probably be

included. This database is initialized with a description of the entities that

are directly connected to the system. It is updated according to information

received in messages from neighboring gateways.

The most important information exchanged by the hosts and gateways is that

carried in update messages. Each entity that participates in the routing

scheme sends update messages that describe the routing database as it

currently exists in that entity. It is possible to maintain optimal routes for the

entire system by using only information obtained from neighboring entities.

The algorithm used for that will be described in the next section.

As we mentioned above, the purpose of routing is to find a way to get

datagrams to their ultimate destinations. Distance vector algorithms are

based on a table giving the best route to every destination in the system. Ofcourse, in order to define which route is best, we have to have some way of

measuring goodness. This is referred to as the "metric".

In simple networks, it is common to use a metric that simply counts how

many gateways a message must go through. In more complex networks, a

metric is chosen to represent the total amount of delay that the message

suffers, the cost of sending it, or some other quantity which may be

minimized. The main requirement is that it must be possible to represent the

metric as a sum of "costs" for individual hops.

Formally, if it is possible to get from entity i to entity j directly (i.e., without

passing through another gateway between), then a cost, d(i,j), is associated

with the hop between i and j. In the normal case where all entities on a given

network are considered to be the same, d(i,j) is the same for all destinations

on a given network, and represents the cost of using that network. To get the

metric of a complete route, one just adds up the costs of the individual hops

that make up the route. For the purposes of this memo, we assume that the

costs are positive integers.

Let D(i,j) represent the metric of the best route from entity i to entity j. It

should be defined for every pair of entities. d(i,j) represents the costs of the

individual steps. Formally, let d(i,j) represent the cost of going directly from

entity i to entity j. It is infinite if i and j are not immediate neighbors. (Note

that d(i,i) is infinite. That is, we don't consider there to be a direct


67/121

connection from a node to itself.) Since costs are additive, it is easy to show

that the best metric must be described by

D(i,i) = 0, all i

D(i,j) = min [d(i,k) + D(k,j)], otherwise

k

and that the best routes start by going from i to those neighbors k for which

d(i,k) + D(k,j) has the minimum value. (These things can be shown by

induction on the number of steps in the routes.) Note that we can limit the

second equation to k's that are immediate neighbors of i. For the others,

d(i,k) is infinite, so the term involving them can never be the minimum.

It turns out that one can compute the metric by a simple algorithm based on

this. Entity i gets its neighbors k to send it their estimates of their distancesto the destination j. When i gets the estimates from k, it adds d(i,k) to each

of the numbers. This is simply the cost of traversing the network between i

and k. Now and then i compares the values from all of its neighbors and

picks the smallest.

A proof is given in [2] that this algorithm will converge to the correct

estimates of D(i,j) in finite time in the absence of topology changes. The

authors make very few assumptions about the order in which the entities

send each other their information, or when the min is recomputed. Basically,

entities just can't stop sending updates or recomputing metrics, and thenetworks can't delay messages forever. (Crash of a routing entity is a

topology change.) Also, their proof does not make any assumptions about

the initial estimates of D(i,j), except that they must be non-negative. The fact

that these fairly weak assumptions are good enough is important. Because

we don't have to make assumptions about when updates are sent, it is safe to

run the algorithm asynchronously. That is, each entity can send updates

according to its own clock. Updates can be dropped by the network, as long

as they don't all get dropped. Because we don't have to make assumptions

about the starting condition, the algorithm can handle changes. When the

system changes, the routing algorithm starts moving to a new equilibrium,

using the old one as its starting point. It is important that the algorithm will

converge in finite time no matter what the starting point. Otherwise certain

kinds of changes might lead to non-convergent behavior.


68/121

The statement of the algorithm given above (and the proof) assumes that

each entity keeps copies of the estimates that come from each of its

neighbors, and now and then does a min over all of the neighbors. In fact

real implementations don't necessarily do that. They simply remember the

best metric seen so far, and the identity of the neighbor that sent it. They

replace this information whenever they see a better (smaller) metric. This

allows them to compute the minimum incrementally, without having to store

data from all of the neighbors.

There is one other difference between the algorithm as described in texts and

those used in real protocols such as RIP: the description above would have

each entity include an entry for itself, showing a distance of zero. In fact this

is not generally done. Recall that all entities on a network are normally

summarized by a single entry for the network. Consider the situation of a

host or gateway G that is connected to network A. C represents the cost ofusing network A (usually a metric of one). (Recall that we are assuming that

the internal structure of a network is not visible to IP, and thus the cost of

going between any two entities on it is the same.) In principle, G should get

a message from every other entity H on network A, showing a cost of 0 to

get from that entity to itself. G would then compute C + 0 as the distance to

H. Rather than having G look at all of these identical messages, it simply

starts out by making an entry for network A in its table, and assigning it a

metric of C. This entry for network A should be thought of as summarizing

the entries for all other entities on network A. The only entity on A that can't

be summarized by that common entry is G itself, since the cost of going

from G to G is 0, not C. But since we never need those 0 entries, we can

safely get along with just the single entry for network A. Note one other

implication of this strategy: because we don't need to use the 0 entries for

anything, hosts that do not function as gateways don't need to send any

update messages. Clearly hosts that don't function as gateways (i.e., hosts

that are connected to only one network) can have no useful information to

contribute other than their own entry D(i,i) = 0. As they have only the one

interface, it is easy to see that a route to any other network through them will

simply go in that interface and then come right back out it. Thus the cost ofsuch a route will be greater than the best cost by at least C. Since we don't

need the 0 entries, non- gateways need not participate in the routing protocol

at all.

Let us summarize what a host or gateway G does. For each destination in the

system, G will keep a current estimate of the metric for that destination (i.e.,


69/121

the total cost of getting to it) and the identity of the neighboring gateway on

whose data that metric is based. If the destination is on a network that is

directly connected to G, then G simply uses an entry that shows the cost of

using the network, and the fact that no gateway is needed to get to the

destination. It is easy to show that once the computation has converged to

the correct metrics, the neighbor that is recorded by this technique is in fact

the first gateway on the path to the destination. (If there are several equally

good paths, it is the first gateway on one of them.) This combination of

destination, metric, and gateway is typically referred to as a route to the

destination with that metric, using that gateway.

The method so far only has a way to lower the metric, as the existing metric

is kept until a smaller one shows up. It is possible that the initial estimate

might be too low. Thus, there must be a way to increase the metric. It turns

out to be sufficient to use the following rule: suppose the current route to adestination has metric D and uses gateway G. If a new set of information

arrived from some source other than G, only update the route if the new

metric is better than D. But if a new set of information arrives from G itself,

always update D to the new value. It is easy to show that with this rule, the

incremental update process produces the same routes as a calculation that

remembers the latest information from all the neighbors and does an explicit

minimum. (Note that the discussion so far assumes that the network

configuration is static. It does not allow for the possibility that a system

might fail.)

To summarize, here is the basic distance vector algorithm as it has been

developed so far. (Note that this is not a statement of the RIP protocol. There

are several refinements still to be added.) The following procedure is carried

out by every entity that participates in the routing protocol. This must

include all of the gateways in the system. Hosts that are not gateways may

participate as well.

Keep a table with an entry for every possible destination in the

system. The entry contains the distance D to the destination, and thefirst gateway G on the route to that network. Conceptually, there

should be an entry for the entity itse

dynamic routing docdrthyfj gyujg

Documents