Web Content Display Web Content Display

Project Project

 

     PROJECT REPORT

 

On

 

    "Dynamic Source Routing-2"

 

 

 

Submitted in partial fulfillment of the requirement  

for the award of the degree

 

 

BACHELOR OF TECHNOLOGY

 

 

in

 

 

Information Technology

 

 

 

Maharshi Dayanand University, Rohtak

 

 

 

 

Under the Guidence of                                                                      Submitted By:

Mrs.Megha Goel                                                                               Devesh Agrwal(15466)

(Associate Professor)                                                                        Divya Singla(15469)

Deptt. Of  Information Technology                                                  Himanshi Grover(15474)                                    

 

 

 

SESSION 2012-2016

 

Dronacharya College of Engineering

Khentawas ,Farrukh Nagar,Gurgaon

 

 

 

Certificate

 

 

 

This is to certify that this project report entitled "Dynamic Source Routing-2" by Devesh Agrawal (15466), Divya Singla (15469), Himanshi Grover (15474) submitted in partial fulfillment of the requirements for the degree of Bachelor of Technology in Information Technology of the Maharshi Dayanand University,Rohtak, Haryana, during the academic year 2012-16, is a bonafide record of work carried out under my guidance and supervision.

 

 

 

 

 

 
 

Prof. Yashvardhan Soni

HOD (IT)

 

 

 

Megha Goel

Associate Professor

                                                                                              

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Acknowledgement

 

I would like to express my sincere gratitude to my project guide "Megha Goel" for giving me the opportunity to work on this topic. It would never be possible for us to take this project to this level without his innovative ideas and his relentless support and encouragement.

 

I would also like to express my sincere gratitude to my Head of Department Prof. Megha Goel for constant support and motivation. It would never be possible for us to take this project to this level without his innovative ideas and his relent less support and encouragement.

 

 

 

 

 

 

   Devesh Agrawal (15466)

   Divya Singla (15469)

   Himanshi Grover (15474)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LIST OF FIGURES

 

 

 

FIGURE NO.

  NAME OF THE FIGURE

PAGE NO

       Figure 3.1:

  Structure

14

        Figure 4.1:

  Route Discovery

22

       Figure 4.2:

  Packet Forwarding

23

       Figure 4.3:

  Accuracy of Routes                                                              

24

       Figure 4.4:

  Storing New Paths

25

       Figure 4.5:

  Sequence Diagram

26

       Figure 4.6:

  Route Discovery Flowchart

27

       Figure 4.7:

  Accuracy of Routes Flowcharts

28

       Figure 4.8:

  Packet Forwarding Flowcharts

29

       Figure 4.9:

  Use-case Diagram

30

 

       Figure 4.10:

  Collaboration Diagrams

31

       Figure 4.11:

  Route Discovery-1

45

       Figure 4.12:

  Route Discovery-2

46

       Figure 4.13:

  Route Discovery-3

46

       Figure 4.14:

  Accuracy of Routes

47

       Figure 4.15:

  Example of Caching in DSR

50

 

 

 

 

 

 

 

CONTENTS

                                                                                                PAGE

Abstract                                                                                                              i

Acknowledgement                                                                                       ii

List of figures                                                                                                 iii

CHAPTER NO

                        TITLE

PAGE NO

 

Chapter 1               INTRODUCTION                                                             01

Chapter 2               LITERATURE SURVEY                                                  03

                            2.1     Java                                                                                      04

                            2.2     Java Swings                                                                         05

                            2.3     Java Socket Programming                                                08              

                            2.4     Dynamic Source Routing                                                   09

                            2.5     Summary                                                                             11

      Chapter 3               SCOPE OF PRESENT WORK                                        12

                            3.1     Proposed Structure                                                            14

      Chapter 4               PRESENT WORK                                                             15

                            4.1     Requirement Analysis                                                        16

                            4.1.1 Existing System                                                                    16

                            4.1.2 Proposed System                                                                16

                            4.1.3 Advantages of Proposed System                            17

                4.1.4 Functional Requirements                                                  17

                            4.1.5 Non-Functional Requirements                                          18

                            4.1.6 Hardware Requirements                                                  18

                            4.1.7 Software Requirements                                                    19   

                           

    4.2   Design                                                                                    19

                            4.2.1 Design Overview                                                                  19

                            4.2.2 Dataflow Diagram                                                              21

                            4.2.3 Sequence Diagram                                                              26

                            4.2.4 Flowcharts                                                                           27

                            4.2.5 Context Analysis Diagram                                                 30     

                            4.3     Implementation                                                                   32

                            4.3.1 Software Tools Used                                                           32

                            4.3.2 Java                                                                                       32

                            4.3.3 Java-Network Related Class Description                        38

                            4.3.4 Programming Terminology                                              44

                            4.4     System Testing                                                                    51

                            4.4.1 Testing Objectives                                                              51

                            4.4.2 Testing Principles                                                               51

                            4.4.3 Testing Design                                                                     51

                            4.4.4 Testing Strategies                                                               52

    Chapter 5                 RESULTS                                                                            54

    Chapter 6                 CONCLUSION                                                                   61

    Chapter 7                 SCOPE FOR FUTURE WORK                                        63

                                      BIBLIOGRAPHY                                                              65                                                                                           

 

 

CHAPTER – 1

INTRODUCTION

1. INTRODUCTION

This project is about studying routing problems in networks that require guaranteed reliability against multiple correlated link failures. We consider two different routing objectives: The first ensures "local reliability", i.e., the goal is to route in such a way that each connection in the network is as reliable as possible. The second ensures "global reliability," i.e., the goal is to route in such a way that as few connections as possible are affected by any failure.

 

In mobile ad hoc networks, nodes move arbitrarily. Frequent topology changes present the fundamental challenge to routing protocols. Routing protocols can be classified into two major types: proactive and on-demand.

 

Proactive protocols attempt to maintain up-to-date routing information to all nodes by periodically disseminating topology updates throughout the network. On-demand protocols attempt to discover a route only when a node generates a packet. To reduce the overhead and the latency of initiating a route discovery for each packet, on-demand routing protocols use route caches. Due to mobility, cached routes easily become stale. Using stale routes causes packet loss and increases latency and overhead.  To address the cache staleness issue in DSR (the Dynamic Source Routing protocol)  prior work  used adaptive timeout mechanisms. Such mechanisms use heuristics with ad hoc parameters to predict the lifetime of a link or a route.

 

However, a predetermined choice of ad hoc parameters for certain scenarios may not work well for others. Scenarios in the real world are different from those used in simulations. Moreover, heuristics cannot accurately predict timeouts because topology changes are unpredictable. As a result, either valid routes will be removed or stale routes will be kept in caches.

 

CHAPTER – 2

LITERATURE SURVEY

2. LITERATURE SURVEY

2.1 JAVA

HISTORY OF JAVA

Java language was developed by James Gosling and his team at sun Microsystems and released formally in 1995. It was developed under the name of ‘Oak'. Open source version of Java Development Kit 1.0 was released in 1996, to popularize java and is freely available on Internet.

OVERVIEW OF JAVA

Java is loosely based on C++ syntax, and is meant to be Object-Oriented. The structure of java is midway between an interpreted and a compiled language. The java compiler translates the source programs into Byte Codes, which are secure and portable across different platforms. These byte codes are essentially instructions, encapsulated in single type, to what is known as Java Virtual Machine (JVM).

JVM is available for almost all OS. JVM converts these byte codes into machine specific instructions at runtime.

Java is actually a platform consisting of three components:

  • Java programming language.
  • Java library of classes and interfaces.
  • Java Virtual Machine.

 

FEATURES OF JAVA

Java is an object-oriented language and hence, supports encapsulation, inheritance, polymorphism and dynamic binding, but does not support multiple inheritance. Everything in java is an object except some primitive data types.

Java is portable and architecture neutral, i.e, java programs once compiled can be executed on any machine that contains a JVM.

Java is distributed in its approach and used for Internet programming. D Java is robust, secured, high performing and dynamic in nature.

Java supports multithreading. Therefore, different parts of the program can be executed at the same time.

2.2 JAVA SWINGS

This introduction to using Swing in Java will walk you through the basics of Swing. This covers topics of how to create a window, add controls, position the controls, and handle events from the controls.

The Main Window

Almost all GUI applications have a main or top-level window. In Swing, such window is usually instance of JFrame or JWindow. The difference between those two classes is in simplicity – JWindow is much simpler than JFrame (most noticeable are visual differences - JWindow does not have a title bar, and does not put a button in the operating system task bar). So, your applications will almost always start with a JFrame.

 Though you can instantiate a JFrame and add components to it, a good practice is to encapsulate and group the code for a single visual frame in a separate class. Usually, we subclass the JFrame and initialize all visual elements of that frame in the constructor.

Always pass a title to the parent class constructor – that String will be displayed in the title bar and on the task bar. Also, remember to always initialize frame size (by calling setSize(width, height)), or your frame will not be noticeable on the screen. For Example:

packagecom.neuri.handsonswing.ch1;

importjavax.swing.JFrame;

publicclassMainFrameextendsJFrame

{

   publicMainframe()

  {

      super("Mytitle");

      setSize(300,300);

   }

}

Now you have created your first frame, and it is time to display it. Main frame is usually displayed from the main method – but resist the urge to put the main method in the frame class. Always try to separate the code that deals with visual presentation from the code that deals with application logic – starting and initializing the application is part of application logic, not a part of visual presentation. A good practice is to create an Application class that will contain initialization code. For Example:

packagecom.neuri.handsonswing.ch1;

publicclass Application {

Public static void main (String [] args)

{

      // perform any initialization

MainFrame mf = new MainFrame();

mf.show();

}  }

If you run the code now, you will see an empty frame. When you close it, something not quite obvious will happen. The application will not end. Remember that the Frame is just a visual part of application, not application logic – if you do not request application termination when the window closes, your program will still run in the background. To avoid this problem, add the following line to the Mainframe constructor:

SetDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);

Adding Components

Now is the time to add some components to the window. In Swing (and the Swing predecessor, AWT) all visual objects are subclasses of Component class. The Composite pattern was applied here to group visual objects into Containers, special components that can contain other components. Containers can specify the order, size and position of embedded components (and this can all be automatically calculated, which is one of the best features of Swing).

            JButton is a component class that represents a general purpose button – it can have a text caption or an icon, and can be pressed to invoke an action. Add imports for javax.swing.* and java.awt.* to the MainFrame source code so that you can use all the components. When you work with JFrame, you want to put objects into it's content pane – special container intended to hold the window contents. Obtain the reference to that container with the getContentPane () method. For Example:

Containercontent= getContentPane ();

Content. add (new JButton ("Button 1"));

If you try to add more buttons to the frame, most likely only the last one added will be displayed. That is because the default behavior of JFrame content pane is to display a single component, resized to cover the entire area.

Grouping Components

To put more than one component into a place intended for a single component, group them into a container. JPanel is a general purpose container that is perfect for grouping a set of components into a "larger" component. For Example:

JPanel panel=new JPanel ();

panel.add (new JButton ("Button 1"));

panel.add (new JButton ("Button 2"));

panel.add (new JButton ("Button 3"));

content. add (panel);

2.3 JAVA SOCKET PROGRAMMING

URLs and URL Connections provide a relatively high-level mechanism for accessing resources on the Internet. Sometimes your programs require lower-level network communication, for example, when you want to write a client-server application.

In client-server applications, the server provides some service, such as processing database queries or sending out current stock prices. The client uses the service provided by the server, either by displaying database query results to the user or by making stock purchase recommendations to an investor. The communication that occurs between the client and the server must be reliable. That is, no data can be dropped and it must arrive on the client side in the same order in which the server sent it.

TCP provides a reliable, point-to-point communication channel that the client-server applications on the Internet use to communicate with each other. To communicate over TCP, a client program and a server program establish a connection to one another. Each program binds a socket to its end of the connection. To communicate, the client and the server each reads from and writes to the socket bound to the connection.

Definition:  A socket is one endpoint of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the TCP layer can identify the application that data is destined to be sent.

 

2.4 DYNAMIC SOURCE ROUTING  

Dynamic Source Routing (DSR) is a routing protocol for wireless mesh networks. It is similar to AODV in that it forms a route on-demand when a transmitting computer requests one. However, it uses source routing instead of relying on the routing table at each intermediate device. Many successive refinements have been made to DSR, including DSRFLOW.

Determining source routes requires accumulating the address of each device between the source and destination during route discovery. The accumulated path information is cached by nodes processing the route discovery packets. The discovered paths are used to route packets. To accomplish source routing, the routed packets contain the address of each device the packet will traverse. This may result in high overhead for long paths or large addresses, like IPv6. To avoid using source routing, DSR optionally defines a flow id option that allows packets to be forwarded on a hop-by-hop basis.

This protocol is truly based on source routing whereby all the routing information is maintained (continually updated) at mobile nodes. It has only 2 major phases which are Route Discovery and Route Maintenance. Route Reply would only be generated if the message has reached the intended destination node (route record which is initially contained in Route Request would be inserted into the Route Reply).

To return the Route Reply, the destination node must have a route to the source node. If the route is in the Destination Node's route cache, the route would be used. Otherwise, the node will reverse the route based on the route record in the Route Reply message header (this requires that all links are symmetric).

In the event of fatal transmission, the Route Maintenance Phase is initiated whereby the Route Error packets are generated at a node. The erroneous hop will be removed from the node's route cache, and all routes containing the hop are truncated. Again, the Route Discovery Phase is initiated to determine the most viable route.

Dynamic source routing protocol (DSR) is an on-demand protocol designed to restrict the bandwidth consumed by control packets in ad hoc wireless networks by eliminating the periodic table-update messages required in the table-driven approach. The major difference between this and the other on-demand routing protocols is that it is beacon-less and hence, does not require periodic hello packet (beacon) transmissions, which are used by a node to inform its neighbors of its presence. The basic approach of this protocol (and all other on-demand routing protocols) during the route construction phase is to establish a route by flooding Route-Request packets in the network. The destination node, on receiving a Route-Request packet, responds by sending a Route-Reply packet back to the source, which carries the route traversed by the Route-Request packet received.

Consider a source node that does not have a route to the destination. When it has data packets to be sent to that destination, it initiates a Route-Request packet. This Route-Request is flooded throughout the network. Each node, upon receiving a Route-Request packet, rebroadcasts the packet to its neighbors if it has not forwarded it already, provided that the node is not the destination node and that the packet's time to live (TTL) counter has not been exceeded. Each Route-Request carries a sequence number generated by the source node and the path it has traversed. A node, upon receiving a Route-Request packet, checks the sequence number on the packet before forwarding it. The packet is forwarded only if it is not a duplicate Route-Request. The sequence number on the packet is used to prevent loop formations and to avoid multiple transmissions of the same Route-Request by an intermediate node that receives it through multiple paths. Thus, all nodes except the destination forward a Route-Request packet during the route construction phase. A destination node, after receiving the first Route-Request packet, replies to the source node through the reverse path the Route-Request packet had traversed. Nodes can also learn about the neighboring routes traversed by data packets if operated in the promiscuous mode (the mode of operation in which a node can receive the packets that are neither broadcast nor addressed to itself). This route cache is also used during the route construction phase. If an intermediate node receiving a Route-Request has a route to the destination node in its route cache, then it replies to the source node by sending a Route-Reply with the entire route information from the source node to the destination node.

2.5 SUMMARY

Commercial services depend on high speed network, so it is extremely important to provide reliable connections to the end users. In circuit-switched networks, connections are established by reserving resources along end-to-end paths. Such networks are called all-optical networks. In all-optical networks, connections are established through light-paths and several light-paths are multiplexed in the same optical fiber that can carry data at rates of the magnitude of Terabits/sec. In these networks, reliable communications are even more crucial since a short network outage can lead to massive data losses and can affect many connections.

            Traditional methods for ensuring reliable transmissions in circuit-switched networks rely on the pre-computation of a backup path for every working path or for every network link. These methods work fine as long as the network experiences only single link failures. They do not guarantee undisturbed communication, however, in the case of multiple link failures. Such failures seldom occur and often are correlated: a single failure in the physical network (a cut in the conduit carrying wiring or fibers used for several links) results in several failures in the abstract network layer.

This type of link failures can be modeled using the notion of generalized failure events. A single generalized failure leads to the failure of several links in the network. Links that belong to the same failure are also said to be in the same shared risk link group. Recent research has focused on the problem of computing, for a given pair of nodes, two risk-disjoint paths, i.e., two paths that do not share links that belong to the same generalized failure event.

This is the so-called "diverse routing problem." This problem and variations of it have been studied.

 

 

 

 

 

 

 

 

CHAPTER – 3

SCOPE OF PRESENT WORK

3. SCOPE OF THE PRESENT WORK

Based on the literature survey, the different problems associated with the current implementation of routing protocols are as follows:

 

  • The Stale routes causes packet losses if packets cannot be salvaged by intermediate nodes
  • The stale routes increases packet delivery latency, since the MAC layer goes through multiple retransmissions before concluding a link failure
  • Use Adaptive time out mechanisms
  • If the cache size is set large, more stale routes will stay in caches because FIFO replacement becomes less effective.

 

To rectify the above mentioned problems we propose:

 

  • A solution to proactively update route caches in an adaptive manner.
  • To define a new cache structure called a cache table to maintain the information necessary for cache updates.
  •  To present a distributed cache update algorithm that uses the local information kept by each node to notify all reachable nodes that have cached a broken link. This algorithm will enable DSR to adapt quickly to topology changes

 

 

3.1 PROPOSED STRUCTURE

 

     
 
 
 

New route adding

 

 

 

 

 

 

 

 

 

 

Fig. 3.1 Structure

                                                                                        

Phase

Task

Description

Phase 1

Analysis

Analyzing the core of the IEEE paper and provide Literature review based on analysis.

Phase 2

Design

Object designing and  Functional description

Phase 3

Implementation

Implement the code based on the object specification

Phase 4

Integration

Integration of  code segments

Phase 5

Testing

Test the project according to  Test Specification

 

 

 

 

 

 

 

 

 

 

 

 

CHAPTER – 4

PRESENT WORK

4. PRESENT WORK

4.1 REQUIREMENT ANALYSIS

 

4.1.1 EXISTING SYSTEM

  • Existing schemes do not consider a long-range dependence property which is an important characteristic of the current internet traffic.
  • If we calculate the effective bandwidth just based on the parameters of long-range dependent traffic considering some QoS, such as loss probability, the utilization of the bandwidth can be very low, due to huge rate fluctuation.
  • TCP performance degrades significantly in Mobile Ad hoc Networks due to the packet losses. Most of these packet losses result from the Route failures due to network mobility.
  • TCP assumes, such losses occur because of congestion, thus invokes congestion control mechanisms such as decreasing congestion windows, raising timeout, etc, thus greatly reducing TCP throughput.
  • However, after a link failure is detected, several packets will be dropped from the network interface queue; TCP will time out because of these packet losses, as well as for Acknowledgement losses caused by route failures.
  • There is no intimation regarding the failure of the links to the node from its neighboring nodes. So the Source Node cannot make the Route Decision's at the time of data transfer.

 

4.1.2 PROPOSED SYSTEM

  • Prior work in LSR used heuristics with ad hoc parameters to predict the lifetime of a link or a route. However, heuristics cannot accurately estimate timeouts because topology changes are unpredictable.
  • Prior researches have proposed to provide link failure feedback to TCP, so that TCP can avoid responding to route failures as if congestion had occurred.
  • We propose proactively disseminating the broken link information to the nodes that have that link in their caches. We define a new cache structure called a cache table and present a distributed cache update algorithm. Each node maintains in its cache table the information necessary for cache updates.
  • The Source Node has the information regarding about the Destination and the Intermediate Node links failure, So that it is useful from Packet loss and reduce the latency time while data transfer throughout the Network.

 

4.1.3 ADVANTAGES OF PROPOSED SYSTEM

  • We have defined a new cache structure called a cache table to maintain the information necessary for cache updates.
  • We have presented a distributed cache update algorithm that uses the local information kept by each node to send message through the route which has maximum bandwidth available.
  •  The algorithm enables LSR to adapt quickly to topology changes.
Ø  Fully distributed operation.
Ø  Less flooding of traffic during the dynamic route discovery process.
Ø  Explicit exploitation of uni-directional links that would otherwise be unused.
Ø  Broken routes could be repaired locally without rediscovery.
Ø  Sub-optimal routes could be shortened as they are used.

 

4.1.4 FUNCTIONAL REQUIREMENTS

Functional Requirements are those that refer to the functionality of the system, i.e., what services it will provide to the user.

  • Request discovery
  • Accuracy of routes
  • Packet forwarding
  • Storing new paths

 

 

 

4.1.5 NON-FUNCTIONAL REQUIREMENTS

Nonfunctional (supplementary) requirements pertain to other information needed to produce the correct system and are detailed separately. These are requirements that are not functional in nature, that is, these are constraints within which the system must work.

  1. The program must be self-contained so that it can easily be moved from one Computer to another. It is assumed that JDK (Java Development Kit) will be available on the computer on which the program resides.
  2. Capacity, scalability and availability.

            The system shall achieve 100 per cent availability at all times.

            The system shall be scalable to support additional clients and volunteers.

      3)   Maintainability.

 The system should be optimized for supportability, or ease of maintenance as far as possible. This may be achieved through the use documentation of coding standards, naming conventions, class libraries and abstraction.

     4)     Randomness, verifiability and load balancing.

          It should have randomness to check the nodes and should be load balanced.

4.1.6 HARDWARE REQUIREMENTS

  • PROCESSOR             :           PENTIUM IV 2.6 GHz
  • RAM                           :           512 MB DD RAM
  • MONITOR                 :           15" COLOR
  • HARD DISK              :           20 GB
  • FLOPPY DRIVE        :           1.44 MB
  • CD DRIVE                 :           LG 52X

4.1.7 SOFTWARE REQUIREMENTS

  • JDK 1.6
  • JAVA SWING
  • MS-ACCESS

 

4.2 DESIGN

4.2.1 DESIGN OVERVIEW

On-demand Route Maintenance results in delayed awareness of mobility, because a node is not notified when a cached route breaks, until it uses the route to send packets. We classify a cached route into three types:

  1.  pre-active, if a route has not been used;
  2. active, if a route is being used;
  3. post-active, if a route was used before but now is not.

It is not necessary to detect whether a route is active or post-active, but these terms help clarify the cache staleness issue. Stale pre-active and post-active routes will not be detected until they are used. Due to the use of responding to Route-Requests with cached routes, stale routes may be quickly propagated to the caches of other nodes. Thus, pre-active and post-active routes are important sources of cache staleness.

When a node detects a link failure, our goal is to notify all reachable nodes that have cached that link to update their caches. To achieve this goal, the node detecting a link failure needs to know which nodes have cached the broken link and needs to notify such nodes efficiently. This goal is very challenging because of mobility and the fast propagation of routing information.

Our solution is to keep track of topology propagation state in a distributed manner. Topology propagation state refers to information regarding which node has cached which link. In a cache table, a node not only stores routes but also maintain two types of information for each route:

(1)  How well routing information is synchronized among nodes on a route.

(2) Which neighbor has learned which links through a Route-Reply. Each node gathers such information during route discoveries and data transmission.

The two types of information are sufficient because each node knows for each cached link which neighbors have that link in their cache.

When forwarding a Route-Reply, a node caches only the downstream links; thus, its downstream nodes did not cache the first downstream link through this Route-Reply. When receiving the first data packet, the node knows that upstream nodes have cached all downstream links. The node adds the upstream links to the route consisting of the downstream links. Thus, when a downstream link is broken, the node knows which upstream node needs to be notified.

If the node can successfully deliver the packet, it is highly likely that the downstream nodes will cache the first downstream link; otherwise, they will not cache the link through forwarding packets with this route. Thus, if the route is the same as the source route in the packet encountering a link failure, the downstream nodes do not cache the link. However, if the route is different from the source route in the packet, downstream nodes would have cached the link when the first data packet traversed the route. Thus, when an entry contains a broken link, the node will know which neighbor needs to be notified. The algorithm uses the information kept by each node to achieve distributed cache updating.

The algorithm notifies the closest upstream and/or downstream nodes and the neighbors that learned the broken link through ROUTE REPLIES. When a node receives a notification, the algorithm notifies selected neighbors: upstream and/or downstream neighbors, and other neighbors that have cached the broken link through ROUTE REPLIES. Thus, the broken link information will be quickly propagated to all reachable nodes that have that link in their caches.

 

The Definition of a Cache Table

We design a cache table that has no capacity limit. Without capacity limit allows DSR to store all discovered routes and thus reduces route discoveries. The cache size increases as new routes are discovered and decreases as stale routes are removed.

 

There are five fields in a cache table entry:

 Destination: It is the destination node to which packet is to be delivered.

 Path: It records the routes available for forwarding the packet in order to make sure that the packet follows the right path to reach the destination.

 Number of Packets: This field may contain the count for the packets transmitted.

Root Status: It indicates the status of the link or node, whether it is available or not.

Bandwidth: It is the capacity of the link available.

 

4.2.2 DATAFLOW DIAGRAM

A data flow diagram (DFD) is graphic representation of the "flow" of data through business functions or processes. More generally, a data flow diagram is used for the visualization of data processing. It illustrates the processes, data stores, external entities, data flows in a business or other system and the relationships between them

 

 

Route discovery

 

 

 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4.1 Route Discovery

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Packet forwarding

 

 

 

 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4.2 Packet Forwarding

 

 
 

Receiver

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Accuracy of routes

 

 

 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4.3 Accuracy of Routes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Storing new paths

 

 

 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4.4 Storing New Paths

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 4.2.3 SEQUENCE DIAGRAM

 

Fig. 4.5 Sequence Diagram

 

 

 

 

 

 

 

 

 

 

 

4.2.4 FLOWCHARTS

  • Request discovery

 

Update Cache table with Route Error

Flowchart: Decision: If Receive Ack from DestinationFlowchart: Decision: If path available in cache table

 

Fig. 4.6 Route Discovery Flowchart

 

 

 

  • Accuracy of routes

 

 

Send Route Request to neighbor nodes

 

 

Fig. 4.7 Accuracy of Routes Flowchart

 

 

 

 

 

 

  • Packet Forwarding

 

 

 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4.8 Packet Forwarding Flowchart

 

 

 

 

 

 

 

 

 

 

 

 

4.2.5 CONTEXT ANALYSIS DIAGRAM

 Use case Diagram

 

 

Fig. 4.9 Usecase Diagram

 

 

 

 

 

 

Collaboration Diagram

Fig. 4.10 Collaboration Diagrams

4.3 IMPLEMENTATION

4.3.1 SOFTWARE TOOLS USED

  • FRONT END                  :    JAVA, SWING
  • TOOLS USED                :    JFRAME BUILDER
  • OPERATING SYSTEM:    WINDOWS XP

4.3.2 JAVA

The Java language is a remarkable example of programming language evolution. Java builds on the familiar and useful features of C++ while removing its complex, dangerous, and superfluous elements. The result is a language that is safer, simpler, and easier to use. The following subsections describe Java in contrast to C++. 

Java Is Familiar and Simple

If you have ever programmed in C++, you will find Java's appeal to be instantaneous. Since Java's syntax mirrors that of C++, you will be able to write Java programs within minutes. Your first programs will come quickly and easily, with very little programming overhead.

You will have the feeling that you have eliminated a lot of clutter from your programs-and you will have. All the cryptic header files and preprocessor statements of C and C++ are gone. All the #define statements and type dens have been taken away. You will no longer have to delve through several levels of header files to correctly reference API calls. And no one will have to suffer to figure out how to use your software.

Java programs simply import the software packages they need. These packages may be in another directory, on another drive, or on a machine on the other side of the Internet. The Java compiler and interpreter figure out what objects are referenced and supply the necessary linkage.

 

Java Is Object-Oriented

If you think C++ is an object-oriented programming language, you are in for a big surprise. After using Java to write a few programs, you'll get a better feeling for what object-oriented software is all about.

Java deals with classes and objects, pure and simple. They aren't just more data structures that are available to the programmer, they are the basis for the entire programming language.

In C++, you can declare a class, but you don't have to. You can declare a structure or a union instead. You can declare a whole bunch of loosely associated variables and use them with C-style functions. In Java, classes and objects are at the centre of the language. Everything else revolves around them. You can't declare functions and procedures. They don't exist. You can't use structures, unions, or typedefs.

Java provides all the luxuries of object-oriented programming: class hierarchy, inheritance, encapsulation, and polymorphism-in a context that is truly useful and efficient. The main reason for developing object-oriented software, beside clarity and simplicity, is the reusability of objects you have developed. Java not only encourages software reuse, it demands it. To write any sort of Java program, no matter how simple, you must build on the classes and methods of the Java API.

Once you have begun developing software in Java, you have two choices:

1. Build on the classes you have developed, thereby reusing them.

2. Rewrite your software from scratch, copying useful parts of existing software.

With Java, the temptation to start from scratch is no longer appealing. Java's object-oriented structure forces you to develop more useful, more tailorable, and much simpler software the first time around.

 

Java Is Safer and More Reliable

Java is safer to use than C++ because it keeps you from doing the things that you do badly, while making it easier to do the things that you do well.

Java won't automatically convert data types. You have to explicitly convert from one class to another. C++, under the most undesirable conditions, will automatically convert one type to another. It has all the flexibility of assembly code.

C++ pointers don't exist in Java. You can no longer access objects indirectly or by chance. You declare objects and reference those objects directly. Complex pointer arithmetic is avoided. If you need an indexed set of objects, you can use an array of objects. The concept of "the address of an object" is eliminated from the programming model, and another assembly language dinosaur is laid to rest. As a result, it becomes much easier to do things correctly in Java.

Java's reliability extends beyond the language level to the compiler and the runtime system. Compile-time checks identify many programming errors that go undetected in other programming languages. These checks go beyond syntactic checking to ensure that statements are semantically correct.

Runtime checks are also more extensive and effective. The Java linker understands class types and performs compiler-level type checking, adding redundancy to reliability. It also performs bounds checking and eliminates indirect object access, even under error conditions.

Java Is Secure

If you gave a skilled hacker a program written in C or C++ and told him to find any security flaws, there are half a dozen things that he would immediately look for: gaining access to the operating system, causing an unexpected return of control, overwriting critical memory areas, acquiring the ability to spoof or modify other programs, browsing for security information, and gaining unauthorized access to the file system.

Why is C or C++ more vulnerable than Java? When a programmer develops software, he or she usually focuses on how to get the software to work correctly and efficiently. C and C++ do not constrain the programmer from meeting these goals and provide a number of flexible features that enable the programmer to meet his end. The hacker is also able to take advantage of these features and use them in ways that weren't originally intended, causing the undesirable consequences identified in the previous paragraph. In short, C and C++ provide a great offense, but no defense. Java, on the other hand, is defensive by nature. Every time a Java-enabled browser downloads a compiled Java class, such as an applet, it runs the risk of running Trojan horse code. Because of this ever-present threat, it subjects the code to a series of checks that ensure that it is correct and secure.

The Java runtime system is designed to enforce a security policy that prevents execution of malicious code. It does this by remembering how objects are stored in memory and enforcing correct and secure access to those objects according to its security rules. It performs bytecode verification by passing compiled classes through a simple theorem prover that either proves that the code is secure or prevents the code from being loaded and executed. The class is Java's basic execution unit and security is implemented at the class level.

The Java runtime system also segregates software according to its origin. Classes from the local system are processed separately from those of other systems. This prevents remote systems from replacing local system software with code that is less trustworthy.

Java-enabled browsers, such as HotJava, allow the user to control the accesses that Java software may make of the local system. When a Java applet needs permission to access local resources, such as files, a security dialog box is presented to the user, requesting explicit user permission. This approach ensures that the user always has the final say in the security of his system.

Java Is Multithreaded

Java, like Ada, and unlike other languages, provides built-in language support for multithreading. Multithreading allows more than one thread of execution to take place within a single program. This allows your program to do many things at once, seemingly all at the same time. Multithreading is an important asset because it allows the programmer to write programs as independent threads, rather than as a convoluted gaggle of intertwined activities. Multithreading also allows Java to use idle CPU time to perform necessary garbage collection and general system maintenance, enabling these functions to be performed with less impact on program performance.

Java provides the support necessary to make multithreading work safely and correctly. Java supports multithreading by providing synchronization capabilities that ensure that threads share information and execution time in a way that is thread safe.

Java Is Interpreted and Portable

While it is true that compiled code will almost always run more quickly than interpreted code, it is also true that interpreted code can usually be developed and fielded more inexpensively, more quickly, and in a more flexible manner. It is also usually much more portable.

Java, in order to be a truly platform-independent programming language, must be interpreted. It does not run as fast as compiled native code, but it doesn't run much slower, either.

The advantages of being interpreted outweigh any performance impacts. Because Java is interpreted, it is much more portable. If an operating system can run the Java interpreter and support the Java API, then it can faithfully run all Java programs.

Interpreted programs are much more easily kept up-to-date. You don't have to recompile them for every change. In Java, recompilation is automatic. The interpreter detects the fact that a program's bytecode file is out-of-date with respect to its source code file and recompiles it as it is loaded.

Because of Java's interpreted nature, linking is also more powerful and flexible. Java's runtime system supports dynamic linking between local class files and those that are downloaded from across the Internet. This feature provides the basis for Web programming.

Java has become the de facto programming language of the Web. It is being licensed by nearly every major software company. It has some offshoots and potential competition, such as JavaScript, VBScript, and Bell Labs's Inferno, but it remains the first Web programming language and the most powerful language for developing platform-independent software.

Java is also evolving beyond the Web and becoming a key component in distributed application development. Sun's release of the NEO and JOE products emphasizes Java's importance to distributed object-based software development. Several other vendors have introduced products that enable Java to be integrated into the Common Object Request Broker Architecture (CORBA), which is the framework for distributed object communication.

The Java API

The Java API is what makes Java attractive and useful. It consists of a set of packages that are distributed with the JDK as class libraries. These packages provide a common interface for developing Java programs on all Java platforms. The Java API furnishes all the capabilities needed to develop console programs, window programs, client and server networking software, applets, and other applications. It is the difference that takes Java from being a really good programming language to making it a very powerful and efficient programming environment.

The Java API consists of eight major development packages and a supporting debug package. For example, there are separate packages for developing window programs, applets, and networking software.

 

 

 

 

4.3.3 JAVA - NETWORK RELATED CLASSES DESCRIPTION

The Internet Protocol Suite

The java.net package provides a set of classes that support network programming using the communication protocols employed by the Internet. These protocols are known as the Internet protocol suite and include the Internet Protocol (IP), the Transport Control Protocol (TCP), and the User Datagram Protocol (UDP) as well as other, less-prominent supporting protocols.

What Is the Internet and How Does It Work?

The Internet is defined as the collection of all computers that are able to communicate, using the Internet protocol suite, with the computers and networks registered with the Internet Network Information Center (InterNIC). This definition includes all computers to which you can directly (or indirectly through a firewall) send Internet Protocol packets.

Computers on the Internet communicate by exchanging packets of data, known as Internet Protocol, or IP, packets. IP is the network protocol used to send information from one computer to another over the Internet. All computers on the Internet communicate using IP. IP moves information contained in IP packets. The IP packets are routed via special routing algorithms from a source computer that sends the packets to a destination computer that receives them. The routing algorithms figure out the best way to send the packets from source to destination.

In order for IP to send packets from a source computer to a destination computer, it must have some way of identifying these computers. All computers on the Internet are identified using one or more IP addresses. A computer may have more than one IP address if it has more than one interface to computers that are connected to the Internet.

IP addresses are 32-bit numbers. They may be written in decimal, hexadecimal, or other formats, but the most common format is dotted decimal notation. This format breaks the 32-bit address up into four bytes and writes each byte of the address as unsigned decimal integers separated by dots. For example, one of my IP addresses is 0xccD499C1. Because 0xcc = 204, 0xD4 = 212, 0x99 = 153, and 0xC1 = 193, my address in dotted decimal form is 204.212.153.193.

IP addresses are not easy to remember, even using dotted decimal notation. The Internet has adopted a mechanism, referred to as the Domain Name System (DNS), whereby computer names can be associated with IP addresses. These computer names are referred to as domain names. The DNS has several rules that determine how domain names are constructed and how they relate to one another.

The mapping of domain names to IP addresses is maintained by a system of domain name servers. These servers are able to look up the IP address corresponding to a domain name. They also provide the capability to look up the domain name associated with a particular IP address, if one exists.

IP enables communication between computers on the Internet by routing data from a source computer to a destination computer. However, computer-to-computer communication only solves half of the network communication problem. In order for an application program, such as a mail program, to communicate with another application, such as a mail server, there needs to be a way to send data to specific programs within a computer.

Ports are used to enable communication between programs. A port is an address within a computer. Port addresses are 16-bit addresses that are usually associated with a particular application protocol. An application server, such as a Web server or an FTP server, listens on a particular port for service requests, performs whatever service is requested of it, and returns information to the port used by the application program requesting the service.

 

 

 

Popular Internet application protocols are associated with well-known ports. The server programs implementing these protocols listen on these ports for service requests. The well-known ports for some common Internet application protocols are

Port                Protocol

21        File Transfer Protocol

23        Telnet Protocol

25        Simple Mail Transfer Protocol

80        Hypertext Transfer Protocol

Transport protocols are used to deliver information from one port to another and thereby enable communication between application programs. They use either a connection-oriented or connectionless method of communication. TCP is a connection-oriented protocol and UDP is a connectionless transport protocol.

The TCP connection-oriented protocol establishes a communication link between a source port/IP address and a destination port/IP address. The ports are bound together via this link until the connection is terminated and the link is broken. An example of a connection-oriented protocol is a telephone conversation. A telephone connection is established, communication takes place, and then the connection is terminated.

The reliability of the communication between the source and destination programs is ensured through error-detection and error-correction mechanisms that are implemented within TCP. TCP implements the connection as a stream of bytes from source to destination. This feature allows the use of the stream I/O classes provided by java.io.

The UDP connectionless protocol differs from the TCP connection-oriented protocol in that it does not establish a link for the duration of the connection. An example of a connectionless protocol is postal mail. To mail something, you just write down a destination address (and an optional return address) on the envelope of the item you're sending and drop it in a mailbox. When using UDP, an application program writes the destination port and IP address on a datagram and then sends the datagram to its destination. UDP is less reliable than TCP because there are no delivery-assurance or error-detection and -correction mechanisms built into the protocol.

Application protocols such as FTP, SMTP, and HTTP use TCP to provide reliable, stream-based communication between client and server programs. Other protocols, such as the Time Protocol, use UDP because speed of delivery is more important than end-to-end reliability.

Client/Server Computing and the Internet

The Internet provides a variety of services that contribute to its appeal. These services include e-mail, newsgroups, file transfer, remote login, and the Web. Internet services are organized according to a client/server architecture. Client programs, such as Web browsers and file transfer programs, create connections to servers, such as Web and FTP servers. The clients make requests of the server, and the server responds to the requests by providing the service requested by the client.

The Web provides a good example of client/server computing. Web browsers are the clients and Web servers are the servers. Browsers request HTML files from Web servers on your behalf by establishing a connection with a Web server and submitting file requests to the server. The server receives the file requests, retrieves the files, and sends them to the browser over the established connection. The browser receives the files and displays them to your browser window.

Sockets and Client/Server Communication

Clients and servers establish connections and communicate via sockets. Connections are communication links that are created over the Internet using TCP. Some client/server applications are also built around the connectionless UDP. These applications also use sockets to communicate.

Sockets are the endpoints of Internet communication. Clients create client sockets and connect them to server sockets. Sockets are associated with a host address and a port address. The host address is the IP address of the host where the client or server program is located. The port address is the communication port used by the client or server program. Server programs use the well-known port number associated with their application protocol.

A client communicates with a server by establishing a connection to the socket of the server. The client and server then exchange data over the connection. Connection-oriented communication is more reliable than connectionless communication because the underlying TCP provides message-acknowledgment, error-detection, and error-recovery services.

When a connectionless protocol is used, the client and server communicate by sending datagrams to each other's socket. The UDP is used for connectionless protocols. It does not support reliable communication like TCP.

Overview of java.net

The java.net package provides several classes that support socket-based client/server communication.

The InetAddress class encapsulates Internet IP addresses and supports conversion between dotted decimal addresses and hostnames.

The Socket, ServerSocket, and DatagramSocket classes implement client and server sockets for connection-oriented and connectionless communication. The SocketImpl class and the SocketImplFactory interface provide hooks for implementing custom sockets.

The URL, URLConnection, and URLEncoder classes implement high-level browser-server Web connections. The ContentHandler and URLStreamHandler classes are abstract classes that provide the basis for the implementation of Web content and stream handlers. They are supported by the ContentHandlerFactory and URLStreamHandlerFactory interfaces.

 

 

The InetAddress Class

The InetAddress class encapsulates Internet addresses. It supports both numeric IP addresses and hostnames.

The InetAddress class has no public variables or constructors. It provides eight access methods that support common operations on Internet addresses. Three of these methods are static.

The getLocalHost() method is a static method that returns an InetAddress object representing the Internet address of the local host computer. The static getByName() method returns an InetAddress object for a specified host. The static getAllByName() method returns an array of all Internet addresses associated with a particular host.

The getAddress() method gets the numeric IP address of the host identified by the InetAddress object, and the getHostName() method gets its domain name.

The Socket Class

The Socket class implements client connection-based sockets. These sockets are used to develop applications that utilize services provided by connection-oriented server applications.

The Socket class provides four constructors that create sockets and connect them to a destination host and port. The access methods are used to access the I/O streams and connection parameters associated with a connected socket.

The getInetAddress() and getPort() methods get the IP address of the destination host and the destination host port number to which the socket is connected. The getLocalPort() method returns the source host local port number associated with the socket. The getInputStream() and getOutputStream() methods are used to access the input and output streams associated with a socket. The close() method is used to close a socket.

 

 

The ServerSocket Class

The ServerSocket class implements a TCP server socket. It provides two constructors that specify the port to which the server socket is to listen for incoming connection requests. An optional count parameter may be supplied to specify the amount of time that the socket should listen for an incoming connection.

The accept() method is used to cause the server socket to listen and wait until an incoming connection is established. It returns an object of class Socket once a connection is made. This Socket object is then used to carry out a service for a single client. The getInetAddress() method returns the address of the host to which the socket is connected. The getLocalPort() method returns the port on which the server socket listens for an incoming connection. The toString() method returns the socket's address and port number as a string in preparation for printing.

The close() method closes the server socket.

 

4.3.4 PROGRAMMING TERMINOLOGY

Tables Used

Table Name: cache

Fields:

  • Dest                 :           varchar
  • Path                 :           varchar
  • No_Packets     :           number
  • Route_Sts       :           varchar
  • Bandwidth      :           number

 

Modules Used

Module 1: Request discovery

In order for an Request discovery module to send a message to another node the intermittent nodes must know what route the message takes to get to the receiver node. The process of finding the route is known as Route Discovery. The steps required for a successful Route Discovery, are demonstrated in the graphics with R3 requesting a Route to R6:

The sending node invokes Route Discovery by sending a broadcast Route Request Packet. The Route Request contains the following pertinent information:

  1. Route Request ID (sequence number)
  2. Destination Network Address
  3. Path Cost Field (metric for measuring quality of a route)
  4. Source Network Address

 

 

Fig 4.11 Route Discovery-1

 

First the receiving node creates an entry in its Route Discovery Table. The receiving node responds to the Route Request Packet by sending a Unicast Route Reply Packet (with an updated Path Cost Value). The Route Reply Packet contains:

  1. Route Request ID (sequence number)
  2. Destination Network Address
  3. Path Cost Field (metric for measuring quality of a route)
  4. Source Network Address

Fig 4.12 Route Discovery-2

If the Destination node receives another Route Request Packet it will check if the Path Cost field is better than the value already stored. If so, it will send a second Route Reply back along the new route and then update its Route Discovery Table with the new route. If the Path Cost is worse on the second Route Request Packet then it will discard the second Route Request.

Fig 4.13 Route Discovery-3

After Route Discovery, the route is stored in the Routing Tables of the nodes. On future transmissions to R6, R3 will transmit the data, via the Coordinator and R4 without performing a Route Discovery.

When a source node wants to send packets to a destination to which it does not have a route, it initiates a Route by broadcasting a ROUTE DISCOVERY. The node receiving a ROUTE DISCOVERY checks whether it has a route to the destination in its cache. If it has, it sends a ROUTE REPLY to the source including a source route, which is the concatenation of the source route in the ROUTE REQUEST and the cached route.

 

Module 2: Accuracy of routes

 

 

Fig 4.14 Accuracy of Routes

 

  1. Dynamically maintain the knowledge of necessary neighbourhood information
    • Information from link layer   
    • Information from information dissemination in support of routing
    • Information from data transmission
  2. Properly initialize route information under relevant constraints when a network is deployed or a new routing domain is configured
    • Constraints can include time, overhead, energy, stealth
    • Prior information useful and resources required to configure initialization is typically available when a tactical network is deployed.
  3. Properly update route information to address dynamics
  • Mechanisms:
    • Triggering conditions
    • Event-driven: time-out, threshold on route quality, demand-driven
    • Periodic
    • Specific actions
  1. Route discovery
  2. Information dissemination

 

 

 

  1. Failure Response:Respond to the detected loss of a link due to failure, mobility, or jamming
  • Mechanisms:
    • Active: properly update the route information to repair affected routes or compute alternative routes (TBRBF).
    • Passive: remove invalid route information due to the failure (AODV or DSR).
    • Mixed

The Message transfer relates with that the sender node wants to send a message to the destination node after the path is selected and status of the destination node through is true. The receiver node receives the message completely and then it send the acknowledgement to the sender node through the router nodes where it is received the message.

 

Module 3:Packet forwarding

When route request is made, link state routing begins. In this case, the route is selected based on the bandwidth available.  The link state protocol sends the request to all nodes and gets the route back as reply based on bandwidth available. Whichever route has more bandwidth, that route is selected for message transfer.

  • Every node in the network must broadcast a Hello message and every receiving node must process it. Routing overhead is controlled by the total number of nodes.
  • If a route breaks a message must be sent to each node using that route, eventually reaching the source.

 

Module 4: Storing new paths

Fig 4.15 An Example of Caching in DSR     

We show an example of the cache staleness issue. In the figure, assume that route ABCDE is active, route FGCDH is post-active, and route IGCDJ is pre-active. Thus, node C has cached both the upstream and the downstream links for the active and post-active routes, but only the downstream links, CDJ, for the pre-active route. When forwarding a packet for source A, node C detects that link CD is broken. It removes stale routes from its cache and sends a ROUTE ERROR to node A. However, the downstream nodes, D and E, will not know about the broken link. Moreover, node C does not know that other nodes also have cached the broken link, including all the nodes on the post-active route, F, G, D, and H, and the upstream nodes on the pre-active route, I and G. Stale routes have several adverse effects: Using stale routes causes packet losses if packets cannot be salvaged by intermediate nodes; Using stale routes increases packet delivery latency, since the MAC layer goes through multiple retransmissions before concluding a link failure; Using stale routes increases routing overhead, since the node detecting a link failure will send a ROUTE ERROR to the source node; Using stale routes degrades TCP performance, since TCP will invoke congestion control mechanisms for packet losses caused by route failures.

 

 

4.4 SYSTEM TESTING

4.4.1 TESTING 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.

 

4.4.2 TESTING PRINCIPLES

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

 

4.4.3 TESTING DESIGN

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

 

White box Testing

        White Box Testing is a testing in which 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.

 

4.4.4 TESTING STRATERGIES

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.

Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program inputs produce 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 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 that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.

Integration Testing

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 software applications at the company level, interact without error.

Integration testing for Server Synchronization:

  • Testing the IP Address to communicate with the other Nodes
  • Check the Route status in the Cache Table after the status information is received by the Node
  • The Messages are displayed throughout the end of the application

 

Functional test

Functional tests provide a systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation, and user manuals.

Functional testing is centred 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 be exercised.

System/Procedure   : interfacing systems or procedures must be invoked.

             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 Test

            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.

 

 

 

 

 

 

CHAPTER – 5

RESULTS

  1. RESULTS

In this project, we have presented a solution to proactively update route caches in an adaptive manner. We defined a new cache structure called a cache table to maintain the information necessary for cache updates. We presented a distributed cache update algorithm that uses the local information kept by each node to notify all reachable nodes that have cached a broken link. The algorithm enables DSR to adapt quickly to topology changes.

The results are displayed in the form of screenshots as shown below:

 

Showing server status

                  

 

 

 

 

Port establishment

      

Showing all nodes

                                                                                                                                      

                                          

 

 

 

 

 

 

Message sending

        

Message Encryption

 

 

 

 

 

 

 

 

Path request

Received message

 

 

 

 

 

Cache table for first node

Cache table for all nodes

 

 

 

 

 

 

 

 

Second node deactivated

        

Cache table when second node is deactivated

       

 

 

 

 

 

 

CHAPTER – 6

CONCLUSION

6. CONCLUSION

In this project, we have presented a solution to proactively update route caches in an adaptive manner. We defined a new cache structure called a cache table to maintain the information necessary for cache updates. We presented a distributed cache update algorithm that uses the local information kept by each node to notify all reachable nodes that have cached a broken link. The algorithm enables DSR to adapt quickly to topology changes.

The central challenge to routing protocols is how to efficiently handle topology changes. Proactive protocols periodically exchange topology updates among all nodes, incurring significant overhead. Our approach successfully handles topology changes by notifying all reachable nodes whenever the topology changes and reduces update overhead by exchanging update information only when a packet is generated. 

Although the results were obtained under a certain type of mobility and traffic models, we believe that the results can be applied  to other models, as the algorithm quickly removes stale routes no matter how nodes move and which traffic model is used.

 

 

 

 

 

 

 

CHAPTER – 7

SCOPE FOR FUTURE WORK

7. SCOPE FOR FUTURE WORK

As with other applications, there is certainly a scope for improvement in this application too. New modules are in pipeline which increases the compatibility of the project.  Below are some of decision's to make our project effectively and efficiently in the future

 

  • Implement Non-Adaptive Routing or Dynamic Routing while Message Transfer-This includes establishing alternative routes during link failure, when packets are already been forwarded from the source node.

 

  • Establish Key agreement process between the Source and the Destination nodes-This enables authentication, privacy, confidentiality etc.

 

  • Implement the Bidirectional route information between the source and the destination nodes- messages can be forwarded in both direction (from source to destination and destination to source).

 

  • The message can be split before transmitting-splitting of messages before transmitting reduces latency, overhead, traffic overflow.

 

  • It can be modified for image and music files.

 

 

 

 

 

BIBLIOGRAPHY

BIBLIOGRAPHY

  • Ashish Shukla, "Ensuring Cache Freshness in On-demand Routing Protocols for Mobile Ad Hoc Network" IEEE CCNC 2007 proceedings.
  •  M. Medard, R. A. Barry, S. G. Finn, W. He, and S. Lumetta, "Generalized loop-back recovery in optical mesh networks," IEEE/ACM Trans. Networking, vol. 10, no. 1, pp. 153–164, Feb. 2002.
  •  M. E. Kramer and J. van Leeuwen, "The complexity of wire routing and finding the minimum area layouts for arbitrary VLSI circuits," in Advances in Computing Research; VLSI Theory, F. P. Preparata, Ed. Greenwich, CT: JAI Press, 1984, vol. 2, pp. 129–146.
  •  R. Ramaswami and K. N. Sivarajan, Optical Networks: A Practical Perspective, 2nd ed. San Francisco, CA: Morgan Kaufmann, 2002.
  •  Stamatis Stefanakos , "Reliable Routings in Networks with Generalized Link Faliure Events" In IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 16, No. 6, Pp-1331-1339, December 2008.
  •  T. Erlebach and D. Vukadinovic, "New results for path problems in generalized stars, complete graphs, and brick wall graphs," in Proc. 13th Int. Symp. Fundamentals Computation Theory (FCT'01), 2001, ser. LNCS 2138, pp. 483–494.