0% found this document useful (0 votes)

73 views94 pages

Iot Project Report

This document discusses improving security in 5G wireless networks by eliminating eavesdropping devices ("droppers") that collude to intercept communications. It proposes detecting droppers using a network layer algorithm. Extensive simulations show the scheme achieves high detection rates and low false positives while incurring low communication overhead, especially compared to centralized monitoring approaches. The scheme also works for both connected and disconnected networks.

Uploaded by

madhan_M46

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

73 views94 pages

Iot Project Report

Uploaded by

madhan_M46

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 94

Security Improvement of Dropper

Elimination Scheme for 5G Based Wireless

Networks
ABSTRACT

Eliminate the eavesdropper collusion occurred by the two or more

devices communicating via optimal relay with centralized router using
5G network. The overall delay is reduced with increase in
throughput. This project studies the important of wireless
communication under eavesdropper collusion where detecting the
dropper node. To provide knowledge about the security improvement
in wireless communication network by using Network Layer
algorithm. Extensive simulation results in both connected and
disconnected networks demonstrate that our schemes achieve high
failure detection rates (close to an upper bound) and low false positive
rates, and incur low communication overhead. Compared to
approaches that use centralized monitoring, our approach has up to
80% lower communication overhead, and only slightly lower
detection rates and slightly higher false positive rates. In addition, our
approach has the advantage that it is applicable to both connected and
disconnected networks while centralized monitoring is only
applicable to connected networks.
CHAPTER 1

INTRODUCTION

WIRELESS SENSOR NETWORK

Wireless sensor network (WSN) becomes an important topic for researchers in recent
year. IEEE 802.15.4 is the standard for WPAN which provided physical (PHY) and medium
access control (MAC) layers . This standard support a low cost, low power and low data rate
which is well-suited for WSN. IEEE 802.15.4 networks support star, mesh, and cluster-tree
network. This network consist of two types of devices; Full Function Device (FFD) (2)
Reduce Function Device (RFD). FFD can play a role of a router which can connect to other
FFD and RFD devices. On the other hand RFD can only connect to FFD devices.

ZIGBEE NETWORK:

Zigbee is an emerging worldwide standard for wireless personal area network. Under
the main goal to provide low-power, cost-effective, flexible, reliable, and scalable wireless
products, ZigBee Alliance has been developing and standardizing the ZigBee network. On
December 2004, they released the ZigBee Specification version 1.0 [1] to the public. Based
on IEEE 802.15.4, ZigBee Specification defines a network layer, application framework as
well as security services. Since ZigBee devices are designed for low cost and low data rates,
it is expected their use in home and building automation with significantly small costs.
Moreover, ZigBee networks support star and mesh topology, self-forming and self-healing as
well as more than 65000 address spaces; thus, network can be easily extended in terms of size
and coverage area.

Among many useful functions in ZigBee network layer, the tree routing algorithm
supports simple but reliable routing for any destination address. In ZigBee, network addresses
are assigned using a distributed addressing scheme that is designed to provide every potential
parent with a finite subblock of network addresses. Due to such addressing scheme, the
network constructs a tree topology; each device can manage the address space of its
descendant. If the destination address is in the address space that a node is managing, the
node forwards the packet to one of its child nodes. Otherwise, it forwards the packet to its
parent node.

Fig. 1. ZigBee protocol stack

The parent or child node which receives the packet selects the next hop node
according to the destination address in the same manner. Tree routing algorithm is thus able
to find the next hop node for a given destination address without routing tables. However, a
sender cannot know if the destination is located nearby or if it’s not in the sub-tree which the
sender is contained in, since tree routing concerns only about the parent and descendants of
the sender node. Although the tree routing is efficient in the view point of memory usage, the
routing cost is sometimes inefficient. This paper proposes the shortcut tree routing algorithm
to archive both memory efficiency and routing efficiency.

The ZigBee Alliance is an association of companies working together to enable

reliable, cost-effective, low-power, wirelessly networked, monitoring, and control products
based on open standards. It is composed of about 200 member companies including 14
promoters such as Motorola, Freescale, Philips, and Samsung. Since their release of the
ZigBee Specification version 1.0 on December 2004, a new version was announced on
September 2006 including multicast, end device mobility and routing mobility.
A. IEEE 802.15.4

The ZigBee protocol stack is described in Fig. 1. As we can see, the IEEE 802.15.4 and
the ZigBee network are tightly coupled to provide the consumer standardization for low
power and low-rate wireless communication devices.

Fig.1 shows ZigBee protocol stack. ZigBee network defines three kinds of devices
personal area network (PAN) coordinator, router, and end device
IEEE 802.15.4 PHY layer provides 16 channels for ISM 2.4 GHz, 10 channels for ISM
900 MHz, and 1 channel for 868 MHz IEEE 802.15.4 PHY provides LQI (Link Quality
Indicator) in order to characterize the quality of links between nodes, as well as data
transmission and reception.

Personal Area Network (PAN) coordinator: is a FFD device acting as the core
component of the network and responsible to initiate the network by setting network’s
parameters which contain how many nodes can join to and the types of nodes (router and
end devices) in this network. After setting up the network, PAN coordinator is responsible
to accept or reject nodes depending on network parameters also handles the routing of
packets through network nodes and chooses the routing techniques in the network. In
ZigBee network it has one coordinator which is mostly connect to the power supply.

Router device: is a FFD device that a PAN coordinator uses it as intermediate node to
carry out the multi-hops routing message through the network from source nods to the sink
node. Also router device can accept another router or end device node to join the network by
assigning network address to this new node and create a communication link between them.
This link will use to transfer data packets to sink node.

End device: is a RFD device acting as the leaf of the network with limit functionality. It is
work for the purpose of sensing data from the environment and transmits to router device
which is joined through it to the network. End device can’t accept any device to join the
network and it has limit energy for that it going to sleep mode to save its energy.

ZIGBEE NETWORK TOPOLOGY:

The application layer consists of three parts: the Application Sublayer (APS), the Application
Framework (AF), and the endpoints. The Application Sublayer interfaces the Zigbee
application layer to the Zigbee networking layer and it provides a common set of data
transport services to all the endpoints. There are also a couple of other services that the APS
provides and we’ll get into that when we discuss the app layer in more detail.

Network Formation

When the user app decides to form a network instead of joining an existing one, it will
instruct the ZDO to call the network formation function. Only a router that is coordinator-
capable can form a network and this is indicated in the application layer’s information base.
It’s just a fancy term for the app layer’s configuration table.
The Application Framework is just a glorified multiplexer and container for all of the
endpoints. All of the endpoints register themselves with the AF, and when a data frame
comes into the application layer, the AF will check its destination endpoint and forward it
there.

The endpoints are what most people associate with Zigbee. Each endpoint houses what’s
called an application object which is basically a device profile with whatever extra
functionality you decide to add. When the device is started, all the endpoints will register
themselves with the application framework and provide descriptions of their device profile
and their capabilities. Endpoint 0 is a special endpoint and always contains the Zigbee Device
Object (ZDO). This object implements the Zigbee
Device Profile which has multiple functions, one of them being the network manager.
When the network formation function is called, a list of allowed channels needs to be
supplied to which may be limited to a subset of the total available channels (16 channels @
2.4GHz). It’s usually based on certain requirements like avoiding channels that overlap with
an existing 802.11 network. Incidentally, coexistence of Zigbee with 802.11 is a major debate
point between other competing radio providers. The main issue is that they claim Zigbee is
susceptible to interference from Wi-Fi networks whereas other radios operating at non-2.4
GHz frequencies are not. I won’t inject myself into the debate here, but I’d suggest locating
any routing nodes a few feet away from an 802.11 access point. I think 3-6 feet is the magic
number that I often hear. Otherwise, just take care to avoid 802.11 channels in your channel
list.

The network formation function will call the MAC’s energy scan and active scan services and
perform scans on the supplied channel list. When the scans are finished, the MAC’s scan
confirm function will return the energy readings and network scan descriptors to the function
via the MAC’s scan confirmation. From there, the network formation function will need to
decide on the channel to join. The usual criteria is to choose a channel with the lowest energy
reading (lowest amount of traffic) and the fewest networks. If you have access to the source
code, you can also modify the channel decision function to add additional criteria.

Once the channel is decided on, the newly crowned coordinator will decide on a PAN ID and
set the channel in the radio. The final step is for the NWK layer to call the MAC start service
which configures the MAC layer. After that, confirmations go back all the way up to the user
app

Network Discovery

As the name implies, the Zigbee network discovery service is used to discover the
existing networks on the current channel. It’s mostly just used when the device is started to
find out if there are any suitable networks to join, although it can also be called at any time
via the user app.
When a network discovery is requested by the ZDO (or user app), the discovery function will
call the MAC’s active scan service which, in turn, will broadcast a beacon request. When
other devices see the beacon request, they will respond with an 802.15.4 beacon frame. If you
remember from my 802.15.4 articles, an 802.15.4 beacon frame contains MAC information
about the responding device as well as a beacon payload for generic data. Within that
payload, the responding device will include Zigbee network information such as the protocol
ID and version, amount of routers and end devices allowed to join, the device profile that is
being used, and other somewhat useful information.
Network Join

Joining a device or allowing a device to join is probably one of the most complicated
processes in Zigbee. There are actually two sides to the network join function: the child side
which sends the request and the parent side which processes the request and sends the
response. To get a thorough understanding of the join process, I’ll treat each sequence
separately. I won’t go into the details of the 802.15.4 association sequence since an
explanation of that can be found in the MAC tutorial.

Network Join – Child

The first part of the join process for the child is to do a network discovery. This is usually
done when the device is first started and is not associated with any network as mentioned
previously. Once the network discovery is finished and the potential parent has been decided
on according to the join criteria, then it’s time for the network join process to start.

When the potential parent has been chosen, a network join request is called by the ZDO. The
network join request will call the MAC’s association service and issue an association request
to the potential parent. From there, the procedure follows the MAC’s association sequence
until the association response is received from the potential parent.

When this response is received, it will get passed up to the network layer via the MAC’s
association response. If the join was successful, the device will update it’s NWK and MAC
information tables to include the new network address, PAN ID, and also update the neighbor
table to specify its parent. Once the administrative work is taken care of, the network join
confirmation is sent up to the ZDO where it can inform the application about the join status.
If the join status was unsuccessful, then the ZDO/user app will choose another potential
parent from the neighbor table and retry the join procedure until it eventually joins a network
or runs out of potential parents.

One of the last things that occur after a successful join is that the device will broadcast a
device announcement informing everyone on the network that it has joined the network as
well as it’s 16-bit network address and 64-bit IEEE address. This is important because if the
device was previously joined to the network with a different network address, the other
devices will be able to find out from it’s IEEE address and can clear all references to the old
network address. Also, the address info will be added to everyone’s address map which tracks
all the devices on the network.

Network Join – Parent

The parent side of the join process is slightly easier. When a MAC association request
arrives at the potential parent, it sends an indication to the network layer that a device is
trying to join. The potential parent will then search its neighbor table to see if the 64-bit IEEE
address already exists. If it does, then that means that the device was already previously
joined and the parent will just issue the same network address to it. If not, and the parent is
allowing devices to join it, then it will simply add the device to its neighbor table specifying
that it’s a child device and generate a new network address for it. This all gets packaged up
and sent out as a MAC association response. Again the rest goes according to the MAC’s
association service.

Classification of Routing Protocols According to the Network Structure

In WSNs, routing protocols are classified into three types such as flat routing protocol,

hierarchical routing protocol and geographic routing protocol.

Flat routing protocol

It is difficult to assign global identifiers to each node of a sensor network given the large
number of deployed nodes .This absence of a global addressing scheme with the random
deployment of sensor nodes makes it hard to select a specific set of sensor nodes that to be
queried. Therefore, data is generally transmitted from each sensor node deployed in the
region with significant redundancy. This redundancy penalizes in terms of energy
consumption. Thus, this thinking leads to the use of a routing for the selection of a group of
nodes and data. aggregation. The recipient requests by its target regions and waits to receive
data from sensors located in the selected region.

Hierarchical routing protocol

These protocols are adopted to allow the system to cover a wider area without degradation of
service. The principal aim of hierarchical routing is to reduce energy consumption and
routing cost of sensor nodes by making them within a cluster in order to perform aggregation
and reduce the number of messages transmitted to the base station. This routing is based
primarily on the gateway nodes. In fact, ordinary nodes know that if the recipient is not in
their immediate vicinity, they just send the request to the gateway. In turn, it will forward the
request to the target node.

Geographic routing protocol

Routing protocols use location-based information service for discovery of routing and data
transmission [Li et al. (2009)]. They allow the directional transmission of information to
avoid the flooded data across the network. Therefore, the routing cost will be reduced and the
routing algorithm will be more optimized. In addition, the use of network topology based on
location information of nodes provides easily control and management of network. The
disadvantage of these routing protocols is that each node must know the locations of other
nodes.

Routing Challenges in WSN

The design of routing protocol in WSN is influenced by many challenges due to several
characteristics that differentiate WSN from other wireless network. These challenges must be
overcome to achieve efficient communication in WSN. First despite the development in
microsensor technology, sensor nodes are tightly constrained because of limited resources
(energy, storage memory, transmission power) thus it require careful management and
efficient routing protocol to maximize the network lifetime and minimize energy expenditure
from the network. Second, routing scheme should be scalable to work with a large number of
nodes and response to any events happen in the phenomena or any changing in the network
topology [3]. Third, most of the applications in WSN require to transmit the data from
different source nodes to one sink node, for that routing protocol should have the ability to
handle this kind of data. Forth, when sensor nodes deploy in environment it’s happen that
some sensors generate similar value of attribute such data redundancy needs to be handle by
routing protocols to improve the performance of the network. Due to such differences, many
algorithms have been proposed to solve these problems of routing protocol in wireless sensor
networks. These routing mechanisms have considered the characteristics of sensor nodes
along with the application and architecture requirements.

CHAPTER 2

PROBLEM DEFINITION AND FEASIBILITY ANALYSIS

In this phase a detailed appraisal of the existing system is explained. This

appraisal includes how the system works and what it does. It also includes
finding out in more detail- what are the problems with the system and what user
requires from the new system or any new change in system. The output of this
phase results in the detail model of the system. The model describes the system
functions and data and system information flow. The phase also contains the
detail set of user requirements and these requirements are used to set objectives
for the new system.

2.1 EXISTING SYSTEM:

This approach assumes that there always exists a path from a node to the central
monitor, and hence is only applicable to networks with persistent connectivity.
In addition, since a node can be multiple hops away from the central monitor,
this approach can lead to a large amount of network-wide traffic, in conflict
with the constrained resources in mobile wireless networks. Another approach
is based on localized monitoring, where nodes broadcast heartbeat messages to
their one-hop neighbors and nodes in a neighborhood monitor each other
through heartbeat messages. Localized monitoring only generates localized
traffic and has been used successfully for node failure detection in static
networks.

2.2 PROBLEM DEFINITION:

 Therefore, techniques that are designed for static networks are not
applicable. Secondly, the network may not always be connected.
 Therefore, approaches that rely on network connectivity have limited
applicability.
 Thirdly, the limited resources (computation, communication and battery
life) demand that node failure detection must be performed in a resource
conserving manner.

2.3 PROPOSED SYSTEM:

In this project, we select any node as the source node from participant node in a
network. To use cache block list, we select all intermediate node for message
passing via that node. Route request send to all intermediate node by source
node. If it is get the route request packet then give response for that route
request packet. When the source node received the route response packet then
its move to RSS algorithm, which is used to detecting the dropper node. which
is split the node into two type. One is no dropper node and another one is
dropper node. If the node is No dropper type which is move to destination then
raise alarm for detecting dropper node Specifically, we propose two schemes. In
the first scheme, when a node A cannot hear from a neighboring node B, it uses
its own information about B and binary feedback from its neighbors to decide
whether B has failed or not. In the second scheme, A gathers information from
its neighbors, and uses the information jointly to make the decision (see Section
V for details). The first scheme incurs lower communication overhead than the
second scheme. On the other hand, the second scheme fully utilizes information
from the neighbors and can achieve better performance in failure detection and
false positive rates.

2.4 ADVANTAGE OF PROPOSED SYSTEM:

 In addition, since a node can be multiple hops away from the central
monitor, this approach can lead to a large amount of network-wide traffic,
in conflict with the constrained resources in mobile wireless networks.
 Another approach is based on localized monitoring, where nodes
broadcast heartbeat messages to their one-hop neighbors and nodes in a
neighborhood monitor each other through heartbeat messages.
 Localized monitoring only generates localized traffic and has been used
successfully for node failure detection in static networks.
SYSTEM STUDY

FEASIBILITY STUDY:

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

proposal is put forth with a very general plan for the project and some cost
estimates. During system analysis the feasibility study of the proposed system is
to be carried out. This is to ensure that the proposed system is not a burden to
the company. For feasibility analysis, some understanding of the major
requirements for the system is essential.

Three key considerations involved in the feasibility analysis are

 Economical feasibility

 Technical feasibility

 Social feasibility

ECONOMICAL FEASIBILITY:

This study is carried out to check the economic impact that the system
will have on the organization. The amount of fund that the company can pour
into the research and development of the system is limited. The expenditures
must be justified. Thus the developed system as well within the budget and this
was achieved because most of the technologies used are freely available. Only
the customized products had to be purchased.

TECHNICAL FEASIBILITY:

This study is carried out to check the technical feasibility, that is, the
technical requirements of the system. Any system developed must not have a
high demand on the available technical resources. This will lead to high
demands on the available technical resources. This will lead to high demands
being placed on the client. The developed system must have a modest
requirement, as only minimal or null changes are required for implementing this
system.

SOCIAL FEASIBILITY:
The aspect of study is to check the level of acceptance of the system by
the user. This includes the process of training the user to use the system
efficiently. The user must not feel threatened by the system, instead must accept
it as a necessity. The level of acceptance by the users solely depends on the
methods that are employed to educate the user about the system and to make
him familiar with it. His level of confidence must be raised so that he is also
able to make some constructive criticism, which is welcomed, as he is the final
user of the system.

CHAPTER 3

SOFTWARE REQUIREMENT SPECIFICATION

INTRODUCTION

NS2 Framework
The Microsoft NS2 Framework (pronounced dot net) is a software
framework developed by Microsoft that runs primarily on Microsoft Windows. It
includes a large class library known as Framework Class Library (FCL) and
provides language interoperability (each language can use code written in other
languages) across several programming languages. Programs written for NS2
Framework execute in a software environment (as contrasted
to hardware environment), known as Common Language Runtime (CLR),
an application virtual machine that provides services such as security, memory
management, and exception handling. FCL and CLR together constitute NS2
Framework.

FCL provides user interface, data access, database

connectivity, cryptography, web application development, numeric algorithms,
and network communications. Programmers produce software by combining their
own source code with NS2 Framework and other libraries. NS2 Framework is
intended to be used by most new applications created for Windows
platform. Microsoft also produces an integrated development environment largely for
NS2 software called Visual Studio.

HISTORY
Microsoft started development of NS2 Framework in the late 1990s, originally
under the name of Next Generation Windows Services (NGWS). By late 2000, the
first beta versions of NS2 1.0 were released.
NS2 Framework family also includes two versions for mobile or embedded
device use. A reduced version of the framework, NS2 Compact Framework, is
available on Windows CE platforms, including Windows Mobile devices such
as smartphones. Additionally, NS2 Micro Framework is targeted at severely resource-
constrained devices.

PURPOSE

COMMON LANGUAGE INFRASTRUCTURE:

Common Language Runtime (CLI) provides a language-neutral platform for
application development and execution, including functions for exception
handling, garbage collection, security, and interoperability. By implementing the core
aspects of NS2 Framework within the scope of CLI, this functionality will not be tied
to a single language but will be available across the many languages supported by the
framework. Microsoft's implementation of CLI is Common Language
Runtime (CLR). It serves as the execution engine of NS2 Framework. All NS2
programs execute under the supervision of CLR, guaranteeing certain properties and
behaviors in the areas of memory management, security, and exception handling.

For computer programs to run on CLI, they need to be compiled into Common

Intermediate Language (CIL) – as opposed to being compiled into machine code.
Upon execution, an architecture-specific Just-in-time compiler (JIT) turns the CIL
code into machine code. To improve performance, however, NS2 Framework comes
with Native Image Generator (NGEN) that performs ahead-of-time compilation.
Figure 2: visual overview of the common language infrastructure (CLI)

SCOPE
NS2 Framework includes a set of standard class libraries. The class library is
organized in a hierarchy of namespaces. Most of the built-in APIs are part of
either System.* or Microsoft.* namespaces. These class libraries implement a large
number of common functions, such as file reading and writing, graphic rendering,
database interaction, and XML document manipulation, among others. NS2 class
libraries are available to all CLI compliant languages. NS2 Framework class library is
divided into two parts: Framework Class Library (FCL) and Base Class
Library (BCL).

NS2 CORE
NS2 Core is a free and open-source partial implementation of the NS2
Framework. It consists of CoreCLR and CoreFX, which are partial forks of CLR and
BCL respectivelyNS2 Core comes with an improved JIT compiler, called RyuJIT.

ASSEMBLIES
Compiled CIL code is stored in CLI assemblies. As mandated by the
specification, assemblies are stored in Portable Executable (PE) file format, common
on Windows platform for all DLL and EXE files. Each assembly consists of one
or more files, one of which must contain a manifest bearing the metadata for the
assembly. The complete name of an assembly (not to be confused with the file name
on disk) contains its simple text name, version number, culture, and public key token.
Assemblies are considered equivalent if they share the same complete name,
excluding the revision of the version number. A private key can also be used by the
creator of the assembly for strong naming. The public key token identifies which
private key an assembly is signed with. Only the creator of the keypair (typically NS2
developer signing the assembly) can sign assemblies that have the same strong name
as a previous version assembly, since the creator is in possession of the private key.
Strong naming is required to add assemblies to Global Assembly Cache.

DESIGN TENETS

LANGUAGE INDEPENDENCE
NS2 Framework introduces a Common Type System (CTS) that defines all
possible datatypes and programming constructs supported by CLR and how they may
or may not interact with each other conforming to CLI specification. Because of this
feature, NS2 Framework supports the exchange of types and object instances between
libraries and applications written using any conforming NS2 language.

PORTABILITY
While Microsoft has never implemented the full framework on any system
except Microsoft Windows, it has engineered the framework to be platform-
agnostic, and cross-platform implementations are available for other operating
systems. Microsoft submitted the specifications for CLI (which includes the core class
libraries, CTS, and CIL), and C++/CLI to both ECMA and ISO, making them
available as official standards. This makes it possible for third parties to create
compatible implementations of the framework and its languages on other platforms.
OVERVIEW
NS2 Framework has its own security mechanism with two general
features: Code Access Security (CAS), and validation and verification. CAS is based
on evidence that is associated with a specific assembly. Typically the evidence is the
source of the assembly (whether it is installed on the local machine or has been
downloaded from the intranet or Internet). CAS uses evidence to determine the
permissions granted to the code. Other code can demand that calling code be granted a
specified permission. The demand causes CLR to perform a call stack walk: every
assembly of each method in the call stack is checked for the required permission; if
any assembly is not granted the permission a security exception is thrown.

MEMORY MANAGEMENT
CLR frees the developer from the burden of managing memory (allocating and
freeing up when done); it handles memory management itself by detecting when
memory can be safely freed. Instantiations of NS2 types (objects) are allocated from
the managed heap; a pool of memory managed by CLR. As long as there exists a
reference to an object, which might be either a direct reference to an object or via
a graph of objects, the object is considered to be in use. When there is no reference to
an object, and it cannot be reached or used, it becomes garbage, eligible for collection.
NS2 Framework includes a garbage collector which runs periodically, on a
separate thread from the application's thread, that enumerates all the unusable objects
and reclaims the memory allocated to them and this is more effcient then the java.

SIMPLIFIED DEPLOYMENT
NS2 Framework includes design features and tools which help manage the
installation of computer software to ensure that it does not interfere with previously
installed software, and that it conforms to security requirements.

PRODCUT FUNCTIONS:
Microsoft NS2 is a set of Microsoft software technologies for rapidly building
and integrating XML Web services, Microsoft Windows-based applications, and Web
solutions. The NS2 Framework is a language-neutral platform for writing programs
that can easily and securely interoperate. There’s no language barrier with NS2: there
are numerous languages available to the developer including Managed C++, TCL,
Visual Basic and Java Script. The NS2 framework provides the foundation for
components to interact seamlessly, whether locally or remotely on different platforms.
It standardizes common data types and communications protocols so that components
created in different languages can easily interoperate.

“NS2” is also the collective name given to various software components built
upon the NS2 platform. These will be both products (Visual StudioNS2 and
WindowsNS2 Server, for instance) and services (like Passport, NS2 My Services, and
so on).

THE NS2 FRAMEWORK

The NS2 Framework has two main parts:

1. The Common Language Runtime (CLR).

2. A hierarchical set of class libraries.

The CLR is described as the “execution engine” of NS2. It provides the

environment within which programs run. The most important features are

 Conversion from a low-level assembler-style language, called

Intermediate Language (IL), into code native to the platform being
executed on.
 Memory management, notably including garbage collection.
 Checking and enforcing security restrictions on the running code.
 Loading and executing programs, with version control and other such
features.
 The following features of the NS2 framework are also worth
description:

Managed Code:

The code that targets NS2, and which contains certain extra Information-
“metadata” - to describe itself. Whilst both managed and unmanaged code can run in
the runtime, only managed code contains the information that allows the CLR to
guarantee, for instance, safe execution and interoperability.

Managed Data

With Managed Code comes Managed Data. CLR provides memory

allocation and Deal location facilities, and garbage collection. Some NS2 languages
use Managed Data by default, such as TCL, Visual BasicNS2 and JScriptNS2,
whereas others, namely C++, do not. Targeting CLR can, depending on the language
you’re using, impose certain constraints on the features available. As with managed
and unmanaged code, one can have both managed and unmanaged data in NS2
applications - data that doesn’t get garbage collected but instead is looked after by
unmanaged code.

Common Type System

The CLR uses something called the Common Type System (CTS) to strictly
enforce type-safety. This ensures that all classes are compatible with each other, by
describing types in a common way. CTS define how types work within the runtime,
which enables types in one language to interoperate with types in another language,
including cross-language exception handling. As well as ensuring that types are only
used in appropriate ways, the runtime also ensures that code doesn’t attempt to access
memory that hasn’t been allocated to it.
Common Language Specification

The CLR provides built-in support for language interoperability. To ensure

that you can develop managed code that can be fully used by developers using any
programming language, a set of language features and rules for using them called the
Common Language Specification (CLS) has been defined. Components that follow
these rules and expose only CLS features are considered CLS-compliant.

THE CLASS LIBRARY

NS2 provides a single-rooted hierarchy of classes, containing over 7000

types. The root of the namespace is called System; this contains basic types like Byte,
Double, Boolean, and String, as well as Object. All objects derive from System.
Object. As well as objects, there are value types. Value types can be allocated on the
stack, which can provide useful flexibility. There are also efficient means of
converting value types to object types if and when necessary.

The set of classes is pretty comprehensive, providing collections, file,

screen, and network I/O, threading, and so on, as well as XML and database
connectivity.

The class library is subdivided into a number of sets (or namespaces),

each providing distinct areas of functionality, with dependencies between the
namespaces kept to a minimum.

OVERLOADING

Overloading is another feature in TCL. Overloading enables us to define

multiple procedures with the same name, where each procedure has a different set
of arguments. Besides using overloading for procedures, we can use it for
constructors and properties in a class.
MULTITHREADING:

TCLNS2 also supports multithreading. An application that supports

multithreading can handle multiple tasks simultaneously, we can use multithreading
to decrease the time taken by an application to respond to user interaction.

STRUCTURED EXCEPTION HANDLING

TCLNS2 supports structured handling, which enables us to detect and remove

errors at runtime. In TCLNS2, we need to use Try…Catch…Finally statements to
create exception handlers. Using Try…Catch…Finally statements, we can create
robust and effective exception handlers to improve the performance of our
application.

THE NS2 FRAMEWORK

The NS2 Framework is a new computing platform that simplifies application

development in the highly distributed environment of the Internet.

OBJECTIVES OF. NET FRAMEWORK

1. To provide a consistent object-oriented programming environment whether

object codes is stored and executed locally on Internet-distributed, or executed
remotely.

2. To provide a code-execution environment to minimizes software deployment and

guarantees safe execution of code.

3. Eliminates the performance problems.

There are different types of application, such as Windows-based applications and

Web-based applications.
MICROSOFT SQL SERVER

Microsoft SQL Server is a relational database management system developed

by Microsoft. As a database, it is a software product whose primary function is to
store and retrieve data as requested by other software applications, be it those on the
same computer or those running on another computer across a network (including the
Internet). There are at least a dozen different editions of Microsoft SQL Server aimed
at different audiences and for workloads ranging from small single-machine
applications to large Internet-facing applications with many concurrent users. Its
primary query languages are T-SQL and ANSI SQL.

HISTORY:

GENESIS
Prior to version 7.0 the code base for MS SQL Server was sold by Sybase SQL
Server to Microsoft, and was Microsoft's entry to the enterprise-level database market,
competing against Oracle, IBM, and, later, Sybase. Microsoft, Sybase and Ashton-
Tate originally worked together to create and market the first version named SQL
Server 1.0 for OS/2 (about 1989) which was essentially the same as Sybase SQL
Server 3.0 on Unix,VMS, etc.

Since the release of SQL Server 2000, advances have been made in performance, the
client IDE tools, and several complementary systems that are packaged with SQL
Server 2005. These include:

 an extract-transform-load (ETL) tool (SQL Server Integration Services or SSIS)

 a Reporting Server
 an OLAP and data mining server (Analysis Services)

Common Language Runtime (CLR) integration was introduced with this

version, enabling one to write SQL code as Managed Code by the CLR. For relational
data, T-SQL has been augmented with error handling features (try/catch) and support
for recursive queries with CTEs (Common Table Expressions). SQL Server 2005 has
also been enhanced with new indexing algorithms, syntax and better error recovery
systems.

FEATURES SQL SERVER:

The OLAP Services feature available in SQL Server version 7.0 is now called
SQL Server 2000 Analysis Services. The term OLAP Services has been replaced with
the term Analysis Services. Analysis Services also includes a new data mining
component. The Repository component available in SQL Server version 7.0 is now
called Microsoft SQL Server 2000 Meta Data Services. References to the component
now use the term Meta Data Services. The term repository is used only in reference to
the repository engine within Meta Data Services

SQL-SERVER database consist of six type of objects,

They are,

1. TABLE

2. QUERY

3. FORM

4. REPORT

5. MACRO

TABLE:

A database is a collection of data about a specific topic.

VIEWS OF TABLE:

We can work with a table in two types,

1. Design View

2. Datasheet View
Design View

To build or modify the structure of a table we work in the table design view.
We can specify what kind of data will be hold.

Datasheet View

To add, edit or analyses the data itself we work in tables datasheet view mode.

QUERY:

A query is a question that has to be asked the data. Access gathers data that
answers the question from one or more table. The data that make up the answer is
either dynaset (if you edit it) or a snapshot (it cannot be edited).Each time we run
query, we get latest information in the dynaset. Access either displays the dynaset or
snapshot for us to view or perform an action on it, such as deleting or updating.
CHAPTER 3

IMPLEMENTATION

Implementation is the stage of the project when the theoretical

design is turned out into a working system. Thus it can be considered to be the
most critical stage in achieving a successful new system and in giving the user,
confidence that the new system will work and be effective.

The implementation stage involves careful planning, investigation of the

existing system and it’s constraints on implementation, designing of methods to
achieve changeover and evaluation of changeover methods.

3.1 MODULES:
We consider both connected and disconnected net-works. For a connected
network, we assume there exists a manager node; alarms of node failures will be
sent to the manager node. For a disconnected network, we assume a node
carries information of node failures and uploads the information
opportunistically to a sink. There may exist multiple sinks, which are connected
to a manager node. The sinks relay information to the manager node.

1) Calculating Failure Probability

2) Upper Bound of Failure Detection Rate

3.1.1 Calculating Failure Probability:

In the basic case, a node sends a single heartbeat packet at each time. When
node A cannot hear from B, one of the following conditions must hold: node B
has failed; node B is not failed but A is out of the transmission range of B; or
node B has not failed and A is in the transmission range of B, but the packet
sent from B is lost. Let R denote the event that A is in the transmission range of
B at time t + 1.

3.1.2 Upper Bound of Failure Detection Rate:

Consider an arbitrary node, A, that fails at time t +1. When using our approach,
a necessary condition for the failure of A to be detected is that there exists at
least one live node in the transmission range of A at time t (so that there exists a
node that hears A at t but no longer hears from A at t +1). Let M be a random
variable that denotes the number of nodes that are in A’s transmission range at
time t. Then the probability that the failure of node A is detected successfully is
no more than Pr(M > 0).
CHAPTER 4

LITERATURE SURVEY

4.1 OVERVIEW:

A literature review is an account of what has been published on a topic by

accredited scholars and researchers. Occasionally you will be asked to write one
as a separate assignment, but more often it is part of the introduction to an
essay, research report, or thesis. In writing the literature review, your purpose is
to convey to your reader what knowledge and ideas have been established on a
topic, and what their strengths and weaknesses are. As a piece of writing, the
literature review must be defined by a guiding concept (e.g., your research
objective, the problem or issue you are discussing or your argumentative thesis).
It is not just a descriptive list of the material available, or a set of summaries

Besides enlarging your knowledge about the topic, writing a literature

review lets you gain and demonstrate skills in two areas

1. INFORMATION SEEKING: the ability to scan the literature

efficiently, using manual or computerized methods, to identify a set of
useful articles and books

2. CRITICAL APPRAISAL: the ability to apply principles of analysis to

identify unbiased and valid studies.

4.2 A PERFORMANCE COMPARISON OF MULTI-HOP WIRELESS

AD HOC NETWORK ROUTING PROTOCOLS
Mobile ad-hoc networks are characterised by constant topology changes, the
absence of fixed infrastructure and lack of any centralised control. Traditional
routing algorithms prove to be inefficient in such a changing environment. Ad-
hoc routing protocols such as dynamic source routing (DSR), ad-hoc on-
demand distance vector routing (AODV) and destination-sequence distance
vector (DSDV) have been proposed to solve the multi hop routing problem in
ad-hoc networks. Performance studies of these routing protocols have assumed
constant bit rate (CBR) traffic. Real-time multimedia traffic generated by video-
on demand and teleconferencing services are mostly variable bit rate (VBR)
traffic. Most of these multimedia traffic is encoded using the MPEG standard.
(ISO moving picture expert group). When video traffic is transferred over
MANETs a series of performance issues arise. In this paper we present a
performance comparison of three ad-hoc routing protocols - DSR, AODV and
DSDV when streaming MPEG4 traffic. Simulation studies show that DSDV
performs better than AODV and DSR. However all three protocols fail to
provide good performance in large, highly mobile network environments.
Further study is required to improve the performance of these protocols in
mobile ad-hoc networks offering VBR services.

4.3 UNRELIABLE FAILURE DETECTORS FOR RELIABLE

DISTRIBUTED SYSTEMS

Understanding distributed computing is not an easy task. This is due to the

many facets of uncertainty one has to cope with and master in order to produce
correct distributed software. Considering the uncertainty created by asynchrony
and process crash failures in the context of message-passing systems, the book
focuses on the main abstractions that one has to understand and master in order
to be able to produce software with guaranteed properties. These fundamental
abstractions are communication abstractions that allow the processes to
communicate consistently (namely the register abstraction and the reliable
broadcast abstraction), and the consensus agreement abstractions that allows
them to cooperate despite failures. As they give a precise meaning to the words
"communicate" and "agree" despite asynchrony and failures, these abstractions
allow distributed programs to be designed with properties that can be stated and
proved. Impossibility results are associated with these abstracti ns. Hence, in
order to circumvent these impossibilities, the book relies on the failure detector
approach, and, consequently, that approach to fault-tolerance is central to the
book. Table of Contents: List of Figures / The Atomic Register Abstraction /
Implementing an Atomic Register in a Crash-Prone Asynchronous System / The
Uniform Reliable Broadcast Abstraction / Uniform Reliable Broadcast
Abstraction Despite Unreliable Channels / The Consensus Abstraction /
Consensus Algorithms for Asynchronous Systems Enriched with Various
Failure Detectors / Constructing Failure Detectors.

4.4 TOWARDS MOBILE PHONE LOCALIZATION WITHOUT WAR-

DRIVING

This paper identifies the possibility of using electronic compasses and

accelerometers in mobile phones, as a simple and scalable method of
localization without war-driving. The idea is not fundamentally different from
ship or air navigation systems, known for centuries. Nonetheless, directly
applying the idea to human-scale environments is non-trivial. Noisy phone
sensors and complicated human movements present practical research
challenges. We cope with these challenges by recording a person's walking
patterns, and matching it against possible path signatures generated from a local
electronic map. Electronic maps enable greater coverage, while eliminating the
reliance on WiFi infrastructure and expensive war-driving. Measurements on
Nokia phones and evaluation with real users confirm the anticipated benefits.
Results show a location accuracy of less than 11m in regions where today's
localization services are unsatisfactory or unavailable.
CHAPTER 5

5.1 METHODOLOGY

DETECTION ALGORITHM

We evaluate the performance of our schemes through exten-sive simulations

using a purpose-built simulator. The simulator is built using Matlab. The main
reason for using the purpose-built simulator instead of other simulators is
because it provides much more flexibility in implementing the node failure
detection algorithms that are proposed in the paper.
5.2 OJECTIVE AND MOTIVATION

OJECTIVE

In public cloud computing, the clients store their massive data in the remote
public cloud servers. Since the stored data is outside of the control of the clients,
it entails the security risks in terms of confidentiality, integrity and availability
of data and service. Remote data integrity checking is a primitive which can be
used to convince the cloud clients that their data are kept intact. In some special
cases, the data owner may be restricted to access the public cloud server, the
data owner will delegate the task of data processing and uploading to the third
party, for example the proxy. On the other side, the remote data integrity
checking protocol must be efficient in order to make it suitable for capacity-
limited end devices. Thus, based on identity-based public cryptography and
proxy public key cryptography, we will study ID-PUIC protocol.

MOTIVATION:

In public cloud environment, most clients upload their data to PCS and check
their remote data’s integrity by Internet. When the client is an individual
manager, some practical problems will happen. If the manager is suspected of
being involved into the commercial fraud, he will be taken away by the police.
During the period of investigation, the manager will be restricted to access the
network in order to guard against collusion.
In public cloud, remote data integrity checking is an important security
problem. Since the clients’ massive data is outside of their control, the clients’
data may be corrupted by the malicious cloud server regardless of intentionally
or unintentionally. In order to address the novel security problem, some
efficient models are presenter.
CHAPTER 6

SYSTEM SPECIFICATION

The purpose of system requirement specification is to produce the

specification analysis of the task and also to establish complete information
about the requirement, behavior and other constraints such as functional
performance and so on. The goal of system requirement specification is to
completely specify the technical requirements for the product in a concise and
unambiguous manner.

6.1 HARDWARE REQUIREMENTS

 System : Pentium IV 2.4 GHz.

 Hard Disk : 40 GB.
 Floppy Drive : 1.44 Mb.
 Monitor : 15 VGA Colour.
 Mouse : Logitech.
 Ram : 512 Mb.

6.2 SOFTWARE REQUIREMENTS

 Operating system : Windows XP/7.

 Coding Language : TCL
 Tool : Network Simulator

CHAPTER 8

INPUT DESIGN AND OUTPUT DESIGN

INPUT DESIGN

The input design is the link between the information system and the user. It
comprises the developing specification and procedures for data preparation and
those steps are necessary to put transaction data in to a usable form for
processing can be achieved by inspecting the computer to read data from a
written or printed document or it can occur by having people keying the data
directly into the system. The design of input focuses on controlling the amount
of input required, controlling the errors, avoiding delay, avoiding extra steps
and keeping the process simple. The input is designed in such a way so that it
provides security and ease of use with retaining the privacy. Input Design
considered the following things:’

 What data should be given as input?

 How the data should be arranged or coded?
 The dialog to guide the operating personnel in providing input.
 Methods for preparing input validations and steps to follow when error
occur.

OBJECTIVES

1.Input Design is the process of converting a user-oriented description of the

input into a computer-based system. This design is important to avoid errors in
the data input process and show the correct direction to the management for
getting correct information from the computerized system.

2. It is achieved by creating user-friendly screens for the data entry to handle

large volume of data. The goal of designing input is to make data entry easier
and to be free from errors. The data entry screen is designed in such a way that
all the data manipulates can be performed. It also provides record viewing
facilities.

3.When the data is entered it will check for its validity. Data can be entered with
the help of screens. Appropriate messages are provided as when needed so that
the user

will not be in maize of instant. Thus the objective of input design is to create an
input layout that is easy to follow

OUTPUT DESIGN

A quality output is one, which meets the requirements of the end user and
presents the information clearly. In any system results of processing are
communicated to the users and to other system through outputs. In output
design it is determined how the information is to be displaced for immediate
need and also the hard copy output. It is the most important and direct source
information to the user. Efficient and intelligent output design improves the
system’s relationship to help user decision-making.

1. Designing computer output should proceed in an organized, well thought out

manner; the right output must be developed while ensuring that each output
element is designed so that people will find the system can use easily and
effectively. When analysis design computer output, they should Identify the
specific output that is needed to meet the requirements.

2.Select methods for presenting information.

3.Create document, report, or other formats that contain information produced

by the system.
The output form of an information system should accomplish one or more of the
following objectives.

 Convey information about past activities, current status or projections of

the
 Future.
 Signal important events, opportunities, problems, or warnings.
 Trigger an action.
 Confirm an action.
CHAPTER 9

OBJECT ORIENTED DESIGN

ARCHITECTURE:

DATA FLOW DIAGRAM:

1. The DFD is also called as bubble chart. It is a simple graphical formalism

that can be used to represent a system in terms of input data to the system,
various processing carried out on this data, and the output data is
generated by this system.
2. The data flow diagram (DFD) is one of the most important modeling
tools. It is used to model the system components. These components are
the system process, the data used by the process, an external entity that
interacts with the system and the information flows in the system.
3. DFD shows how the information moves through the system and how it is
modified by a series of transformations. It is a graphical technique that
depicts information flow and the transformations that are applied as data
moves from input to output.
4. DFD is also known as bubble chart. A DFD may be used to represent a
system at any level of abstraction. DFD may be partitioned into levels
that represent increasing information flow and functional detail.
UML DIAGRAMS

UML stands for Unified Modeling Language. UML is a standardized

general-purpose modeling language in the field of object-oriented software
engineering. The standard is managed, and was created by, the Object
Management Group.
The goal is for UML to become a common language for creating models
of object oriented computer software. In its current form UML is comprised of
two major components: a Meta-model and a notation. In the future, some form
of method or process may also be added to; or associated with, UML.
The Unified Modeling Language is a standard language for specifying,
Visualization, Constructing and documenting the artifacts of software system,
as well as for business modeling and other non-software systems.
The UML represents a collection of best engineering practices that have
proven successful in the modeling of large and complex systems.
The UML is a very important part of developing objects oriented
software and the software development process. The UML uses mostly
graphical notations to express the design of software projects.

GOALS:
The Primary goals in the design of the UML are as follows:
1. Provide users a ready-to-use, expressive visual modeling Language so
that they can develop and exchange meaningful models.
2. Provide extendibility and specialization mechanisms to extend the core
concepts.
3. Be independent of particular programming languages and development
process.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of OO tools market.
6. Support higher level development concepts such as collaborations,
frameworks, patterns and components.
7. Integrate best practices.

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.
OBJECT ORIENTED ANALYSIS

CLASS DIAGRAM:

In software engineering, a class diagram in the Unified Modeling Language

(UML) is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, operations (or
methods), and the relationships among the classes. It explains which class
contains information.
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 diagrams, event scenarios, and timing diagrams.
ACTIVITY DIAGRAM:

Activity diagrams are graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and concurrency. In the
Unified Modeling Language, activity diagrams can be used to describe the
business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control.
CHAPTER 12

SOURCE CODE

Receiving path:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using SystemNS2;
using SystemNS2.Sockets;
using System.IO;
using System.Security.Cryptography;

namespace Destination
{
public partial class Form1 : Form
{
Destination obj = new Destination();
public Form1()
{
InitializeComponent();

private void Form1_Load(object sender, EventArgs e)

{
backgroundWorker1.RunWorkerAsync();
}

private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)

{
obj.StartServer();
}

private void timer1_Tick(object sender, EventArgs e)

{

private void button3_Click(object sender, EventArgs e)

{

private void button1_Click_1(object sender, EventArgs e)

{
FolderBrowserDialog fbd = new FolderBrowserDialog();
if (fbd.ShowDialog() == DialogResult.OK)
{
if (Directory.Exists(fbd.SelectedPath.ToString()))
{
textBox1.Text = fbd.SelectedPath.ToString();
Destination.receivedPath = textBox1.Text;
}
else
{
MessageBox.Show("choose valid path");
}
}
else
{
MessageBox.Show("choose a path to save file");
}
}
}
class Destination
{
IPEndPoint ipEnd;
Socket sock;
public Destination()
{
string hostName = Dns.GetHostName();
IPAddress IpAddr = Dns.GetHostEntry(hostName).AddressList[0];
ipEnd = new IPEndPoint(IpAddr, 5656);
sock = new Socket(ipEnd.AddressFamily, SocketType.Stream,
ProtocolType.IP);
sock.Bind(ipEnd);
}
public static string receivedPath;
public static string curMsg = "waiting...";
public void StartServer()
{
try
{
//curMsg = "Starting...";
sock.Listen(100);

//curMsg = "Running and waiting to receive file.";

Socket clientSock = sock.Accept();
//curMsg = "";

byte[] clientData = new byte[1024 * 5000];

int receivedBytesLen = clientSock.Receive(clientData);

curMsg = "Receiving data...";

int fileNameLen = BitConverter.ToInt32(clientData, 0);

string fileName = Encoding.ASCII.GetString(clientData, 4,
fileNameLen);

BinaryWriter bWrite = new BinaryWriter(File.Open(receivedPath + "/" +

fileName, FileMode.Append));
bWrite.Write(clientData, 4 + fileNameLen, receivedBytesLen - 4 -
fileNameLen);
if (receivedPath == "")
{
MessageBox.Show("No Path was selected to Save the File");
}
else
{
curMsg = "Saving file...";

bWrite.Close();
clientSock.Close();

curMsg = "File Received ...";

MessageBox.Show("File recieved");
}

StartServer();

}
catch (Exception ex)
{
curMsg = "File Receving error." + ex.ToString();
}

}
}

Router form:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using SystemNS2;
using SystemNS2.Sockets;

namespace Router
{
public partial class Form1 : Form
{
bool seed;
byte[] dest;
public static bool tim1;
Router1 obj = new Router1();

public Form1()
{
InitializeComponent();
}

private void Form1_Load(object sender, EventArgs e)

{
invisible();
backgroundWorker1.RunWorkerAsync();
}
public void tim()
{
timer1.Enabled = false;
timer2.Enabled = true;
timer3.Enabled = true;
}
public void dynamic()
{

MessageBox.Show("sending probe packets");

if (pictureBox1.Visible == true)
{
pictureBox1.Image = Router.Properties.Resources.mobviolet;
pictureBox17.Visible = true;
pictureBox18.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox2.Visible == true)
{
pictureBox2.Image = Router.Properties.Resources.mobviolet;
pictureBox3.Image = Router.Properties.Resources.mobviolet;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox21.Visible = true;
pictureBox19.Visible = true;
pictureBox20.Visible = true;
pictureBox22.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox3.Visible == true)
{
pictureBox4.Image = Router.Properties.Resources.mobviolet;
pictureBox5.Image = Router.Properties.Resources.mobviolet;
pictureBox6.Image = Router.Properties.Resources.mobviolet;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox28.Visible = true;
pictureBox27.Visible = true;
pictureBox26.Visible = true;
pictureBox25.Visible = true;
pictureBox24.Visible = true;
pictureBox23.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox6.Visible == true)
{
pictureBox13.Image = Router.Properties.Resources.mobviolet;
pictureBox14.Image = Router.Properties.Resources.mobviolet;
pictureBox15.Image = Router.Properties.Resources.mobviolet;
pictureBox16.Image = Router.Properties.Resources.mobviolet;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox29.Visible = true;
pictureBox30.Visible = true;
pictureBox31.Visible = true;
pictureBox32.Visible = true;
pictureBox33.Visible = true;
pictureBox34.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox16.Visible == true)
{
pictureBox7.Image = Router.Properties.Resources.mobviolet;
pictureBox8.Image = Router.Properties.Resources.mobviolet;
pictureBox9.Image = Router.Properties.Resources.mobviolet;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox35.Visible = true;
pictureBox36.Visible = true;
pictureBox37.Visible = true;
pictureBox38.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox9.Visible == true)
{
pictureBox10.Image = Router.Properties.Resources.mobviolet;
pictureBox11.Image = Router.Properties.Resources.mobviolet;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox39.Visible = true;
pictureBox40.Visible = true;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox11.Visible == true)
{
pictureBox12.Image = Router.Properties.Resources.mobviolet;
}
MessageBox.Show("sending probe packets complete");
invisible();
//Reversing of Probe Packets
if (pictureBox12.Visible == true)
{
pictureBox39.Visible = true;
pictureBox39.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox40.Visible = true;
pictureBox40.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox10.Visible == true)
{
pictureBox35.Visible = true;
pictureBox35.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox36.Visible = true;
pictureBox36.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox11.Visible == true)
{
pictureBox37.Visible = true;
pictureBox37.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox38.Visible = true;
tim();
pictureBox38.Image = Router.Properties.Resources.ll_trans_rev;
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox7.Visible == true)
{
pictureBox29.Visible = true;
pictureBox29.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox30.Visible = true;
pictureBox30.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox8.Visible == true)
{
pictureBox31.Visible = true;
pictureBox31.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox32.Visible = true;
pictureBox32.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox9.Visible == true)
{
pictureBox33.Visible = true;
pictureBox33.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox34.Visible = true;
pictureBox34.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox16.Visible == true)
{
pictureBox23.Visible = true;
pictureBox23.Image = Router.Properties.Resources.lr_trans_reverse;
}
if (pictureBox15.Visible == true)
{
pictureBox25.Visible = true;
pictureBox25.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox24.Visible = true;
pictureBox24.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox14.Visible == true)
{
pictureBox27.Visible = true;
pictureBox27.Image = Router.Properties.Resources.lr_trans_reverse;
pictureBox26.Visible = true;
pictureBox26.Image = Router.Properties.Resources.ll_trans_rev;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox13.Visible == true)
{
pictureBox28.Visible = true;
pictureBox28.Image = Router.Properties.Resources.ll_trans_rev;
}
if (pictureBox4.Visible == true)
{
pictureBox21.Visible = true;
pictureBox21.Image = Router.Properties.Resources.ll_trans_rev;
pictureBox19.Visible = true;
pictureBox19.Image = Router.Properties.Resources.lr_trans_reverse;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox5.Visible == true)
{
pictureBox20.Visible = true;
pictureBox20.Image = Router.Properties.Resources.ll_trans_rev;
pictureBox22.Visible = true;
pictureBox22.Image = Router.Properties.Resources.lr_trans_reverse;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox2.Visible == true)
{
pictureBox17.Visible = true;
pictureBox17.Image = Router.Properties.Resources.ll_trans_rev;
pictureBox18.Visible = true;
pictureBox18.Image = Router.Properties.Resources.lr_trans_reverse;
tim();
Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
invisible();
Random rn = new Random();
int r = rn.Next(1, 4);

if (r == 1)
{
Errpath1();
reset();
path2();
}
else if (r == 2)
{
Errpath2();
reset();
path3();
}
else if (r == 3)
{
Errpath3();
reset();
path4();
}
else if (r == 4)
{
Errpath4();
reset();
path1();
}
else
{

}
public void stat()
{

pictureBox1.Enabled = true;
if (pictureBox1.Enabled == true)
{
pictureBox1.Image = Router.Properties.Resources.mobgreen;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox41.Visible = true;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox41.Visible = false;
}
if (pictureBox1.Visible == true)
{
pictureBox17.Visible = true;
pictureBox17.Image = Router.Properties.Resources.rgc;
pictureBox18.Visible = true;
pictureBox18.Image = Router.Properties.Resources.lrl;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
}
if (pictureBox17.Visible == true)
{
pictureBox2.Image = Router.Properties.Resources.mobgreen;
pictureBox3.Image = Router.Properties.Resources.mobgreen;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox42.Visible = true;
pictureBox47.Visible = true;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox42.Visible = false;
pictureBox47.Visible = false;

}
if (pictureBox2.Visible == true)
{
pictureBox21.Visible = true;
pictureBox21.Image = Router.Properties.Resources.rgc;
pictureBox19.Visible = true;
pictureBox19.Image = Router.Properties.Resources.lrl;

pictureBox20.Visible = true;
pictureBox20.Image = Router.Properties.Resources.rgc;
pictureBox22.Visible = true;
pictureBox22.Image = Router.Properties.Resources.lrl;
}
if (pictureBox22.Visible == true)
{
pictureBox4.Visible = true;
pictureBox4.Image = Router.Properties.Resources.mobgreen;
pictureBox5.Visible = true;
pictureBox5.Image = Router.Properties.Resources.mobgreen;
pictureBox6.Visible = true;
pictureBox6.Image = Router.Properties.Resources.mobgreen;
tim(); Application.DoEvents();
System.Threading.Thread.Sleep(1000);
pictureBox43.Visible = true;
pictureBox52.Visible = true;
pictureBox48.Visible = true;