SNO CONTENTS PAGE NO

1 INTRODUCTION

2 ABSTRACT

3 ORGANIZATION PROFILE

4 SYSTEM ANALYSIS

4.1 EXISTING SYSTEM

4.2 PROPOSED SYSTEM

5 SYSTEM SPECIFICATION

5.1 SOFTWARE SPECIFICATION

5.2 HARDWARE SPECIFICATION

5.3 SOFTWARE DESCRIPTION

6 SYSTEM DESIGN

6.1 SYSTEM ARCHITECTURE

6.2 DATA FLOW DIAGRAM

6.3 UML DIAGRAMS

7 MODULES DESCRIPTION

8 SOFTWARE TESTING

8.1 UNIT TESTING

8.2 INTEGRATION TESTING

8.3 REGRESSION TESTING

8.4 ACCEPTANCE TESTING

9 CONCLUSION

11 REFERENCES

12 APPENDICES

12.1 SAMPLE CODINGS

12.2 SCREEN SHOTS

JAMMING-AWARE TRAFFIC ALLOCATION FOR MULTIPLE-
PATH ROUTING USING PORTFOLIO SELECTION

1. INTRODUCTION

JAMMING point-to-point transmissions in a wireless mesh network or

underwater acoustic network can have debilitating effects on data transport through the
network. The effects of jamming at the physical layer resonate through the protocol stack,
providing an effective denial-of-service (DoS) attack on end-to-end data communication.
The simplest methods to defend a network against jamming attacks comprise physical
layer solutions such as spread-spectrum or beamforming, forcing the jammers to expend
a greater resource to reach the same goal. However, recent work has demonstrated that
intelligent jammers can incorporate cross-layer protocol information into jamming
attacks, reducing resource expenditure by several orders of magnitude by targeting
certain link layer and MAC implementations as well as link layer error detection and
correction protocols. Hence, more sophisticated antijamming methods and defensive
measures must be incorporated into higher layer protocols, for example channel surfing
or routing around jammed regions of the network. The majority of antijamming
techniques make use of diversity. For example, antijamming protocols may employ
multiple frequency bands, different MAC channels, or multiple routing paths. Such
diversity techniques help to curb the effects of the jamming attack by requiring the
jammer to act on multiple resources simultaneously. In this paper, we consider the
antijamming diversity based on the use of multiple routing paths. Using multiple-path
variants of source routing protocols such as Dynamic Source Routing (DSR) or Ad Hoc
On-Demand Distance Vector (AODV), for example the MP-DSR protocol, each source
node can request several routing paths to the destination node for concurrent use. To
make effective use of this routing diversity, however, each source node must be able to
make an intelligent allocation of traffic across the available paths while considering the
potential effect of jamming on the resulting data throughput. In order to characterize the
effect of jamming on throughput, each source must collect information on the impact of
the jamming attack in various parts of the network. However, the extent of jamming at
each network node depends on a number of unknown parameters, including the strategy
used by the individual jammers and the relative location of the jammers with respect to
each transmitter–receiver pair. Hence, the impact of jamming is probabilistic from the
perspective of the network and the characterization of the jamming impact is further
complicated by the fact that the jammers strategies may be dynamic and the jammers
themselves may be mobile. In order to capture the nondeterministic and dynamic effects
of the jamming attack, we model the packet error rate at each network node as a random
process. At a given time, the randomness in the packet error rate is due to the uncertainty
in the jamming parameters, while the time variability in the packet error rate is due to the
jamming dynamics and mobility. Since the effect of jamming at each node is
probabilistic, the end-to-end throughput achieved by each source–destination pair will
also we assume that the network does not rely on a jamming detection, localization, or
tracking infrastructure. We note that factors other than jamming that similarly impact
throughput can be included as well. We focus on jamming in this work as it is likely the
prominent source of packet loss be nondeterministic and hence, must be studied using a
stochastic framework. In this paper, we thus investigate the ability of network nodes to
characterize the jamming impact and the ability of multiple source nodes to compensate
for jamming in the allocation of traffic across multiple routing paths. Our contributions to
this problem are as follows. We formulate the problem of allocating traffic across
multiple routing paths in the presence of jamming as a lossy network flow optimization
problem. We map the optimization problem to that of asset allocation using portfolio
selection theory. We formulate the centralized traffic allocation problem for multiple
source nodes as a convex optimization problem. We show that the multisource multiple-
path optimal traffic allocation can be computed at the source nodes using a distributed
algorithm based on decomposition in network utility maximization (NUM). We propose
methods that allow individual network nodes to locally characterize the jamming impact
and aggregate this information for the source nodes. We demonstrate that the use of
portfolio selection theory allows the data sources to balance the expected data throughput
with the uncertainty in achievable traffic rates.
 2. ABSTRACT

Multiple-path source routing protocols allow a data source node to distribute the
total traffic among available paths. In this paper, we consider the problem of jamming-aware
source routing in which the source node performs traffic allocation based on empirical jamming
statistics at individual network nodes. We formulate this traffic allocation as a lossy network
flow optimization problem using portfolio selection theory from financial statistics. We show
that in multisource networks, this centralized optimization problem can be solved using an anti
jamming technique. We demonstrate the network’s ability to estimate the impact of jamming and
incorporate these estimates into the traffic allocation problem. Finally, we simulate the
achievable throughput using our proposed traffic allocation method in several scenarios.

3. SYSTEM ANALYSIS
3.1. EXISTING SYSTEM:
In the existing system the occurrence of the traffic in the network is
unpredicteable and the data transferable data is also unpredictable. So that the data transferable
in the network is reduced due to data traffic. The effects of jamming at the physical layer
resonate through the protocol stack, providing an effective denial-of-service (DoS) attack on
end-to-end data communication. The simplest methods to defend a network against jamming
attacks comprise physical layer solutions such as spread-spectrum or beamforming, forcing the
jammers to expend a greater resource to reach the same goal. However, recent work has
demonstrated that intelligent jammers can incorporate cross-layer protocol information into
jamming attacks, reducing resource expenditure by several orders of magnitude by targeting
certain link layer and MAC implementations as well as link layer error detection and correction
protocols .

DISADVANTAGE

 The occurrence of the traffic in the network is unpredictable and the data transferable
data is also unpredictable.
 The data transferable in the network is reduced due to data traffic.
PROPOSED SYSTEM

In this paper, we consider the anti jamming diversity based on the use of multiple routing
paths. Using multiple-path variants of source routing protocols such as Dynamic Source Routing
(DSR) or Ad Hoc On-Demand Distance Vector (AODV), for example the MP-DSR protocol,
each source node can request several routing paths to the destination node for concurrent use. In
order to characterize the effect of jamming on throughput, each source must collect information
on the impact of the jamming attack in various parts of the network. In this paper, we thus
investigate the ability of network nodes to characterize the jamming impact and the ability of
multiple source nodes to compensate for jamming in the allocation of traffic across multiple
routing paths. Our contributions to this problem are as follows. We formulate the problem of
allocating traffic across multiple routing paths in the presence of jamming as a lossy network
flow optimization problem. We map the optimization problem to that of asset allocation using
portfolio selection theory. We formulate the centralized traffic allocation problem for multiple
source nodes as a convex optimization problem. We show that the multisource multiple-path
optimal traffic allocation can be computed at the source nodes using an anti jamming technique.
We propose methods that allow individual network nodes to locally characterize the jamming
impact and aggregate this information for the source nodes. We demonstrate that the use of
portfolio selection theory allows the data sources to balance the expected data throughput with
the uncertainty in achievable traffic rates.

ADVANTAGES

 Effect of jamming at each node is probabilistic.

 End to End throughput achieved by each source- destination pair.
 Intelligent allocation of traffic across multiple routing paths.
 4. SYSTEM SPECIFICATION
4.1. SOFTWARE REQUIREMENTS:
 Front end : jdk6

 Back end : SQL SERVER 2000

 Operating system : win xp professional (service pack 2)

4.2. HARDWARE REQUIREMENTS:

 Hard disk : 10 GB and above

 Ram : 512 MB and above

 Processor : Pentium 4 and above

4.3. SOFTWARE DESCRIPTION

ABOUT JAVA

Java is a programming language originally developed by Sun Microsystems and released in

1995 as a core component of Sun Microsystems' Java platform. The language derives much of its
syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java
applications are typically compiled to bytecode that can run on any Java virtual machine (JVM)
regardless of computer architecture.

One characteristic of Java is portability, which means that computer programs written in the Java
language must run similarly on any supported hardware/operating-system platform. One should
be able to write a program once, compile it once, and run it anywhere.

This is achieved by compiling the Java language code, not to machine code but to Java bytecode
– instructions analogous to machine code but intended to be interpreted by a virtual machine
(VM) written specifically for the host hardware. End-users commonly use a JRE installed on
their own machine, or in a Web browser.

Standardized libraries provide a generic way to access host specific features such as graphics,
threading and networking. In some JVM versions, bytecode can be compiled to native code,
either before or during program execution, resulting in faster execution.

A major benefit of using bytecode is porting. However, the overhead of interpretation means that
interpreted programs almost always run more slowly than programs compiled to native
executables would, and Java suffered a reputation for poor performance. This gap has been
narrowed by a number of optimization techniques introduced in the more recent JVM
implementations.

One such technique, known as (just-in-time compilation) JIT, translates Java bytecode into
native code the first time that code is executed, then caches it. This result in a program that starts
and executes faster than pure interpreted code can, at the cost of introducing occasional
compilation overhead during execution. More sophisticated VMs also use dynamic
recompilation, in which the VM analyzes the behavior of the running program and selectively
recompiles and optimizes parts of the program. Dynamic recompilation can achieve
optimizations superior to static compilation because the dynamic compiler can base
optimizations on knowledge about the runtime environment and the set of loaded classes, and
can identify hot spots - parts of the program, often inner loops, that take up the most execution
time. JIT compilation and dynamic recompilation allow Java programs to approach the speed of
native code without losing portability.
Another technique, commonly known as static compilation, or ahead-of-time (AOT)
compilation, is to compile directly into native code like a more traditional compiler. Static Java
compilers translate the Java source or bytecode to native object code. This achieves good
performance compared to interpretation, at the expense of portability; the output of these
compilers can only be run on a single architecture. AOT could give Java something like
performance, yet it is still not portable since there are no compiler directives, and all the pointers
are indirect with no way to micro manage garbage collection.

Java's performance has improved substantially since the early versions, and performance of JIT
compilers relative to native compilers has in some tests been shown to be quite similar. The
performance of the compilers does not necessarily indicate the performance of the compiled
code; only careful testing can reveal the true performance issues in any system.

One of the unique advantages of the concept of a runtime engine is that errors (exceptions)
should not 'crash' the system. Moreover, in runtime engine environments such as Java there exist
tools that attach to the runtime engine and every time that an exception of interest occurs they
record debugging information that existed in memory at the time the exception was thrown
(stack and heap values). These Automated Exception Handling tools provide 'root-cause'
information for exceptions in Java programs that run in production, testing or development
environments.

SWINGS:

Swing is a platform-independent, Model-View-Controller GUI framework for Java. It follows a

single-threaded programming model, and possesses the following traits:

PLATFORM INDEPENDENCE:

Swing is platform independent both in terms of its expression (Java) and its implementation
(non-native universal rendering of widgets).

EXTENSIBILITY:
Swing is a highly partitioned architecture, which allows for the "plugging" of various custom
implementations of specified framework interfaces: Users can provide their own custom
implementation(s) of these components to override the default implementations. In general,
Swing users can extend the framework by extending existing (framework) classes and/or
providing alternative implementations of core components.

COMPONENT-ORIENTED:

Swing is a component-based framework. The distinction between objects and components is a

fairly subtle point: concisely, a component is a well-behaved object with a known/specified
characteristic pattern of behaviour. Swing objects asynchronously fire events, have "bound"
properties, and respond to a well-known set of commands (specific to the component.)
Specifically, Swing components are Java Beans components, compliant with the Java Beans
Component Architecture specifications.

CUSTOMIZABLE:

Given the programmatic rendering model of the Swing framework, fine control over the details
of rendering of a component is possible in Swing. As a general pattern, the visual representation
of a Swing component is a composition of a standard set of elements, such as a "border", "inset",
decorations, etc. Typically, users will programmatically customize a standard Swing component
(such as a JTable) by assigning specific Borders, Colors, Backgrounds, opacities, etc., as the
properties of that component. The core component will then use these property (settings) to
determine the appropriate renderers to use in painting its various aspects. However, it is also
completely possible to create unique GUI controls with highly customized visual representation.

CONFIGURABLE:

Swing's heavy reliance on runtime mechanisms and indirect composition patterns allows it to
respond at runtime to fundamental changes in its settings. For example, a Swing-based
application can change its look and feel at runtime. Further, users can provide their own look and
feel implementation, which allows for uniform changes in the look and feel of existing Swing
applications without any programmatic change to the application code.
LIGHTWEIGHT UI:

Swing's configurability is a result of a choice not to use the native host OS's GUI controls for
displaying itself. Swing "paints" its controls programmatically through the use of Java 2D APIs,
rather than calling into a native user interface toolkit. Thus, a Swing component does not have a
corresponding native OS GUI component, and is free to render itself in any way that is possible
with the underlying graphics APIs.

However, at its core every Swing component relies on an AWT container, since (Swing's)
JComponent extends (AWT's) Container. This allows Swing to plug into the host OS's GUI
management framework, including the crucial device/screen mappings and user interactions,
such as key presses or mouse movements. Swing simply "transposes" its own (OS agnostic)
semantics over the underlying (OS specific) components. So, for example, every Swing
component paints its rendition on the graphic device in response to a call to component.paint(),
which is defined in (AWT) Container. But unlike AWT components, which delegated the
painting to their OS-native "heavyweight" widget, Swing components are responsible for their
own rendering.

This transposition and decoupling is not merely visual, and extends to Swing's management and
application of its own OS-independent semantics for events fired within its component
containment hierarchies. Generally speaking, the Swing Architecture delegates the task of
mapping the various flavors of OS GUI semantics onto a simple, but generalized, pattern to the
AWT container. Building on that generalized platform, it establishes its own rich and complex
GUI semantics in the form of the JComponent model. A review of the source of Container. java
and JComponent.java classes is recommended for further insights into the nature of the interface
between Swing's lightweight components and AWT's heavyweight widgets.

LOOSELY-COUPLED/MVC:

The Swing library makes heavy use of the Model/View/Controller software design pattern,
which conceptually decouples the data being viewed from the user interface controls through
which it is viewed. Because of this, most Swing components have associated models (which are
specified in terms of Java interfaces), and the programmer can use various default
implementations or provide their own. The framework provides default implementations of
model interfaces for all of its concrete components.

Typically, Swing component model objects are responsible for providing a concise interface
defining events fired, and accessible properties for the (conceptual) data model for use by the
associated JComponent. Given that the overall MVC pattern is a loosely-coupled collaborative
object relationship pattern, the model provides the programmatic means for attaching event
listeners to the data model object. Typically, these events are model centric (ex: a "row inserted"
event in a table model) and are mapped by the JComponent specialization into a meaningful
event for the GUI component.

For example, the JTable has a model called TableModel that describes an interface for how a
table would access tabular data. A default implementation of this operates on a two-dimensional
array.

The view component of a Swing JComponent is the object used to graphically "represent" the
conceptual GUI control. A distinction of Swing, as a GUI framework, is in its reliance on
programmatically-rendered GUI controls (as opposed to the use of the native host OS's GUI
controls). This distinction is a source of complications when mixing AWT controls, which use
native controls, with Swing controls in a GUI.

Finally, in terms of visual composition and management, Swing favors relative layouts (which
specify the positional relationships between components) as opposed to absolute layouts (which
specify the exact location and size of components). This bias towards "fluid"' visual ordering is
due to its origins in the applet operating environment that framed the design and development of
the original Java GUI toolkit. (Conceptually, this view of the layout management is quite similar
to that which informs the rendering of HTML content in browsers, and addresses the same set of
concerns that motivated the former.)
LOOK AND FEEL:

Swing allows one to specialize the look and feel of widgets, by modifying the default (via
runtime parameters), deriving from an existing one, by creating one from scratch, or, beginning
with J2SE 5.0, by using the skinnable synth Look and Feel (see Synth Look and Feel), which
is configured with an XML property file. The look and feel can be changed at runtime, and early
demonstrations of Swing frequently provided a way to do this.

RELATIONSHIP TO AWT:

Since early versions of Java, a portion of the Abstract Window Toolkit (AWT) has provided
platform-independent APIs for user interface components. In AWT, each component is rendered
and controlled by a native peer component specific to the underlying windowing system.

By contrast, Swing components are often described as lightweight because they do not require
allocation of native resources in the operating system's windowing toolkit. The AWT
components are referred to as heavyweight components.

Much of the Swing API is generally a complementary extension of the AWT rather than a direct
replacement. In fact, every Swing lightweight interface ultimately exists within an AWT
heavyweight component because all of the top-level components in Swing ( JApplet, JDialog,
JFrame, and JWindow) extend an AWT top-level container. However, the use of both lightweight
and heavyweight components within the same window is generally discouraged due to Z-order
incompatibilities.

The core rendering functionality used by Swing to draw its lightweight components is provided
by Java 2D, another part of JFC.

NETWORKING BASICS:

Ken Thompson and Dennis Ritchie developed UNIX in concert with the C language at
Bell Telephone Laboratories, Murray Hill, New Jersey, in 1969. In 1978, Bill Joy was leading a
project at Cal Berkeley to add many new features to UNIX, such as virtual memory and full-
screen display capabilities. By early 1984, just as Bill was leaving to found Sun Microsystems,
he shipped 4.2BSD, commonly known as Berkeley UNIX.4.2BSD came with a fast file system,
reliable signals, interprocess communication, and, most important, networking. The networking
support first found in 4.2 eventually became the de facto standard for the Internet. Berkeley’s
implementation of TCP/IP remains the primary standard for communications with the Internet.
The socket paradigm for inter process and network communication has also been widely adopted
outside of Berkeley.

SOCKET OVERVIEW:

A network socket is a lot like an electrical socket. Various plugs around the
network have a standard way of delivering their payload. Anything that understands the standard
protocol can “plug in” to the socket and communicate.

Internet protocol (IP) is a low-level routing protocol that breaks data into small
packets and sends them to an address across a network, which does not guarantee to deliver said
packets to the destination.

Transmission Control Protocol (TCP) is a higher-level protocol that manages to

reliably transmit data. A third protocol, User Datagram Protocol (UDP), sits next to TCP and
can be used directly to support fast, connectionless, unreliable transport of packets.

CLIENT/SERVER

A server is anything that has some resource that can be shared. There are compute
servers, which provide computing power; print servers, which manage a collection of printers;
disk servers, which provide networked disk space; and web servers, which store web pages. A
client is simply any other entity that wants to gain access to a particular server.

In Berkeley sockets, the notion of a socket allows as single computer to serve

many different clients at once, as well as serving many different types of information. This feat is
managed by the introduction of a port, which is a numbered socket on a particular machine. A
server process is said to “listen” to a port until a client connects to it. A server is allowed to
accept multiple clients connected to the same port number, although each session is unique. To
mange multiple client connections, a server process must be multithreaded or have some other
means of multiplexing the simultaneous I/O.

RESERVED SOCKETS:

Once connected, a higher-level protocol ensues, which is dependent on which port

you are using. TCP/IP reserves the lower, 1,024 ports for specific protocols. Port number 21 is
for FTP, 23 is for Telnet, 25 is for e-mail, 79 is for finger, 80 is for HTTP, 119 is for Netnews-
and the list goes on. It is up to each protocol to determine how a client should interact with the
port.

JAVA AND THE NET:

Java supports TCP/IP both by extending the already established stream I/O interface.
Java supports both the TCP and UDP protocol families. TCP is used for reliable stream-based
I/O across the network. UDP supports a simpler, hence faster, point-to-point datagram-oriented
model.

INETADDRESS:

The InetAddress class is used to encapsulate both the numerical IP address and
the domain name for that address. We interact with this class by using the name of an IP host,
which is more convenient and understandable than its IP address. The InetAddress class hides
the number inside. As of Java 2, version 1.4, InetAddress can handle both IPv4 and IPv6
addresses.

FACTORY METHODS:

The InetAddress class has no visible constructors. To create an InetAddress

object, we use one of the available factory methods. Factory methods are merely a convention
whereby static methods in a class return an instance of that class. This is done in lieu of
overloading a constructor with various parameter lists when having unique method names makes
the results much clearer.
 Three commonly used InetAddress factory methods are shown here.

static InetAddress getLocalHost( ) throws UnknownHostException

static InetAddress getByName(String hostName) throws UnknowsHostException

static InetAddress[ ] getAllByName(String hostName)

throws UnknownHostException

The getLocalHost( ) method simply returns the InetAddress object that represents
the local host. The getByName( ) method returns an InetAddress for a host name passed to it. If
these methods are unable to resolve the host name, they throw an UnknownHostException.

On the internet, it is common for a single name to be used to represent several machines.
In the world of web servers, this is one way to provide some degree of scaling. The
getAllByName ( ) factory method returns an array of InetAddresses that represent all of the
addresses that a particular name resolves to. It will also throw an UnknownHostException if it
can’t resolve the name to at least one address. Java 2, version 1.4 also includes the factory
method getByAddress( ), which takes an IP address and returns an InetAddress object. Either an
IPv4 or an IPv6 address can be used.

INSTANCE METHODS:

The InetAddress class also has several other methods, which can be used on the
objects returned by the methods just discussed. Here are some of the most commonly used.

Boolean equals (Object other)- Returns true if this object has the same
Internet address as other.

byte[ ] getAddress( )- Returns a byte array that represents the object’s Internet address in
network byte order.

String getHostAddress( )- Returns a string that represents the host address associated with
the InetAddress object.
 String getHostName( )- Returns a string that represents the host name associated
with the InetAddress object.

boolean isMulticastAddress( )- Returns true if this Internet address is a multicast

address. Otherwise, it returns false.

String toString( )- Returns a string that lists the host name and the IP address for
conveneince.

Internet addresses are looked up in a series of hierarchically cached servers. That means
that your local computer might know a particular name-to-IP-address mapping autocratically,
such as for itself and nearby servers. For other names, it may ask a local DNS server for IP
address information. If that server doesn’t have a particular address, it can go to a remote site and
ask for it. This can continue all the way up to the root server, called InterNIC (internic.net).

TCP/IP CLIENT SOCKETS:

TCP/IP sockets are used to implement reliable, bidirectional, persistent, point-to-point,

stream-based connections between hosts on the Internet. A socket can be used to connect Java’s
I/O system to other programs that may reside either on the local machine or on any other
machine on the Internet.

There are two kinds of TCP sockets in Java. One is for servers, and the other is for
clients. The ServerSocket class is designed to be a “listener,” which waits for clients to connect
before doing anything. The Socket class is designed to connect to server sockets and initiate
protocol exchanges.

The creation of a Socket object implicitly establishes a connection between the

client and server. There are no methods or constructors that explicitly expose the details of
establishing that connection. Here are two constructors used to create client sockets:

Socket(String hostName, int port) Creates a socket connecting the local host to
the named host and port; can throw an UnknownHostException or anIOException.

Socket(InetAddress ipAddress, int port) Creates a socket using a preexisting

InetAddress object and a port; can throw an IOException.
 A socket can be examined at any time for the address and port information
associated with it, by use of the following methods:

InetAddress getInetAddress( )- Returns the InetAddress associated with the

Socket object.

int getPort( ) Returns the remote port to which this Socket object is connected.

int getLocalPort( ) Returns the local port to which this Socket object is connected.

Once the Socket object has been created, it can also be examined to gain access
to the input and output streams associated with it. Each of these methods can throw an
IOException if the sockets have been invalidated by a loss of connection on the Net.

InputStream getInputStream( )Returns the InputStream associated with the invoking

socket.

OutputStream getOutputStream( ) Returns the OutputStream associated with the invoking

socket.

TCP/IP SERVER SOCKETS:

Java has a different socket class that must be used for creating server applications.
The ServerSocket class is used to create servers that listen for either local or remote client
programs to connect to them on published ports. ServerSockets are quite different form normal
Sockets.

When we create a ServerSocket, it will register itself with the system as having an
interest in client connections. The constructors for ServerSocket reflect the port number that we
wish to accept connection on and, optionally, how long we want the queue for said port to be.
The queue length tells the system how many client connection it can leave pending before it
should simply refuse connections. The default is 50. The constructors might throw an
IOException under adverse conditions. Here are the constructors:

ServerSocket(int port) Creates server socket on the specified port with a queue length of 50.
 Serversocket(int port, int maxQueue)-Creates a server socket on the specified port with a
maximum queue length of maxQueue.

ServerSocket(int port, int maxQueue, InetAddress localAddress)-Creates a server socket

on the specified port with a maximum queue length of maxQueue. On a multihomed host,
localAddress specifies the IP address to which this socket binds.

ServerSocket has a method called accept( ), which is a blocking call that will wait for a
client to initiate communications, and then return with a normal Socket that is then used for
communication with the client

5. SYSTEM DESIGN:

5.1. SYSTEM ACHITECTURE

5.2. DATA FLOW DIAGRAM
 5.3. UML DIAGRAMS

USECASE DIAGARAM
 Use case diagrams overview the usage requirements for a system. They are useful for
presentations to management and/or project stakeholders, but for actual development you will
find that use cases provide significantly more value because they describe "the meat" of the
actual requirements.

Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse

Node Registration

Topology Construction

User
Detecting Jamming

Jammer

Dynamic Routing

Receiver

CLASS DIAGRAM:
 Class diagrams are the mainstay of object-oriented analysis and design. class diagrams
show the classes of the system, their interrelationships (including inheritance, aggregation, and
association), and the operations and attributes of the classes. Class diagrams are used for a wide
variety of purposes, including both conceptual/domain modeling and detailed design modeling.

Server
Result Set
Request
Response

Database()
Path Generation()

Client 1 Client N
Node Name Node Name
Ip Address Ip Address
Port number Port Number

Registering Node() Registering Node()

Topology Construction() Client 2 Topology Construction()
Node Name
Ip Address
Port number

Registering Node()
Topology Construction()

SEQUENCE DIAGRAM
 Sequence diagrams model the flow of logic within your system in a visual manner,
enabling you both to document and validate your logic, and are commonly used for both analysis
and design purposes. Sequence diagrams are the most popular UML artifact for dynamic
modeling, which focuses on identifying the behavior within your system.

Sender Intermediate Jammer Receiver

Node

1: data send

2: data send through Different path

3: Sending Request

4: Sending through Alternate path

5: Data Send to Receiver

 6. MODULES

 Node Registration.
 Topology Construction.
 Jammer detection in the network.
 Dynamic Allocation of data packets.

MODULES DESCRIPTION

1. NODE REGISTRATION
Enter the node details such as the port address, ip address and name of user using
the present system. The ip address can be given in an ip 4 byte format or ip 6 byte
configuration. And the port number is the common address port for connecting to two
systems. The registered node details are stored in the database. Each nodes have distinct
port address. Each node is executed from different port number.
2. TOPOLOGY CONSTRUCTION

The node constructed can be added to form a structured topology or an

unstructured topology. The topology is constructed to transfer data through different path
of the network. Each node is connected to each other and the source and the destination is
connected with each other and the topology is constructed it may be a structured network
or may be an unstructed network.

3. JAMMER DETECTION IN THE NETWORK

The jammer in the network is identified based on the number of request and the
jammer is removed from the network. Dynamic detection of the jammer is detected
 automatically even though the jammer changes the path frequently. The jammer in the
network path may be change the location frequently. But the dynamic location in the path
is identified by the number of request.

4. DYNAMIC ALLOCATION OF DATA PACKET

The data content of the file is splitted according to the number of the available
path and then the data is transferred so that the traffic jamming is avoided and the impact
of the jamming is reduced between the source and the destination.
 7. SOFTWARE TESTING
The purpose of testing is to discover errors. Testing is the process of
trying to discover every conceivable fault or weakness in a work product. It
provides a way to check the functionality of components, sub assemblies,
assemblies and/or a finished product it is the process of exercising software
with the intent of ensuring that the Software system meets its requirements
and user expectations and does not fail in an unacceptable manner. There
are various types of test. Each test type addresses a specific testing
requirement.

MAINTENANCE

Correction

Correct defects in the software: defects relating to incorrect requirements, or incorrectly

specifications; defects from any of the construction phases - `bugs'.

Adaption
Adapt to changes in the original software and hardware platform. E.g. simpler: MS-DOS to
Windows. Complex: stand-alone to client-server.

Enhancement

Customer identifies additional requirements.

Prevention

After many sets of changes, the software `deteriorates', or otherwise becomes difficult to
maintain. See Reengineering, Legacy Systems.

Problems:
 Programmers do not like doing maintenance.
 Maintenance needs a project of its own. It is very uncommon to include maintenance
in a (development) contract.
 Cost estimation. Normal software cost estimation is difficult enough; most
estimation models do not include maintenance.
 Design deficiencies make system impossible to extend. See Object-oriented ....
 Deterioration of legacy systems.

7.1. UNIT TESTING

The first test in the development process is the unit test. The source code is normally
divided into modules, which in turn are divided into smaller units called units. These units have
specific behavior. The test done on these units of code is called unit test. Unit test depends upon
the language on which the project is developed. Unit tests ensure that each unique path of the
project performs accurately to the documented specifications and contains clearly defined inputs
and expected results.

7.2. INTEGRATION TESTING

Testing in which software components, hardware components, or both together are

combined and tested to evaluate interactions between them.
Integration testing takes as its input modules that have been checked out by unit testing, groups
them in larger aggregates, applies tests defined in an Integration test plan to those aggregates,
and delivers as its output the integrated system ready for system testing.

7.3. REGRESSION TESTING

Regression testing is the process of testing changes to computer programs to make sure
that the older programming still works with the new changes. Regression testing is a normal part
of the program development process. Test department coders develop code test scenarios and
exercises that will test new units of code after they have been written. Before a new version of a
software product is released, the old test cases are run against the new version to make sure that
all the old capabilities still work. The reason they might not work because changing or adding
new code to a program can easily introduce errors into code that is not intended to be changed. It
is a quality control measure to ensure that the newly modified code still complies with its
specified requirements and that unmodified code has not been affected by the maintenance
activity.

7.4. ACCEPTANCE TESTING

Acceptance testing is formal testing conducted to determine whether a system satisfies its
acceptance criteria and thus whether the customer should accept the system.

The main types of software testing are:

 Component.
 Interface.
 System.
 Acceptance.
 Release.
Acceptance Testing checks the system against the "Requirements". It is similar to
systems testing in that the whole system is checked but the important difference is the change in
focus:

Systems testing checks that the system that was specified has been delivered.
Acceptance Testing checks that the system delivers what was requested. The customer, and not
the developer should always do acceptance testing. The customer knows what is required from
the system to achieve value in the business and is the only person qualified to make that
judgment. The User Acceptance Test Plan will vary from system to system but, in general, the
testing should be planned in order to provide a realistic and adequate exposure of the system to
all reasonably expected events. The testing can be based upon the User Requirements
Specification to which the system should conform.

BLACK BOX TESTING – Internal system design is not considered in this type of testing. Tests
are based on requirements and functionality.

WHITE BOX TESTING – This testing is based on knowledge of the internal logic of an
application’s code. Also known as Glass box Testing. Internal software and code working should
be known for this type of testing. Tests are based on coverage of code statements, branches,
paths, conditions.

INCREMENTAL INTEGRATION TESTING – Bottom up approach for testing i.e

continuous testing of an application as new functionality is added; Application functionality and
modules should be independent enough to test separately. done by programmers or by testers.

FUNCTIONAL TESTING – This type of testing ignores the internal parts and focus on the
output is as per requirement or not. Black-box type testing geared to functional requirements of
an application.

SYSTEM TESTING – Entire system is tested as per the requirements. Black-box type testing
that is based on overall requirements specifications, covers all combined parts of a system.

END-TO-END TESTING – Similar to system testing, involves testing of a complete

application environment in a situation that mimics real-world use, such as interacting with a
database, using network communications, or interacting with other hardware, applications, or
systems if appropriate.
SANITY TESTING - Testing to determine if a new software version is performing well enough
to accept it for a major testing effort. If application is crashing for initial use then system is not
stable enough for further testing and build or application is assigned to fix.

REGRESSION TESTING – Testing the application as a whole for the modification in any
module or functionality. Difficult to cover all the system in regression testing so typically
automation tools are used for these testing types.

LOAD TESTING – Its a performance testing to check system behavior under load. Testing an
application under heavy loads, such as testing of a web site under a range of loads to determine
at what point the system’s response time degrades or fails.

STRESS TESTING – System is stressed beyond its specifications to check how and when it
fails. Performed under heavy load like putting large number beyond storage capacity, complex
database queries, continuous input to system or database load.

PERFORMANCE TESTING – Term often used interchangeably with ‘stresses and ‘load’
testing. To check whether system meets performance requirements. Used different performance
and load tools to do this.

USABILITY TESTING – User-friendliness check. Application flow is tested, Can new user
understand the application easily, Proper help documented whenever user stuck at any point.
Basically system navigation is checked in this testing.

INSTALL/UNINSTALL TESTING - Tested for full, partial, or upgrade install/uninstall

processes on different operating systems under different hardware, software environment.

RECOVERY TESTING – Testing how well a system recovers from crashes, hardware failures,
or other catastrophic problems.

SECURITY TESTING – Can system be penetrated by any hacking way. Testing how well the
system protects against unauthorized internal or external access. Checked if system, database is
safe from external attacks.
COMPATIBILITY TESTING – Testing how well software performs in a particular
hardware/software/operating system/network environment and different combination s of above.

COMPARISON TESTING – Comparison of product strengths and weaknesses with previous

versions or other similar products.

ALPHA TESTING – In house virtual user environment can be created for this type of testing.
Testing is done at the end of development. Still minor design changes may be made as a result of
such testing.

BETA TESTING – Testing typically done by end-users or others. Final testing before releasing
application for commercial purpose.

8. CONCLUSION
In this paper, we studied the problem of traffic allocation in multiple-path routing
algorithms in the presence of jammers whose effect can only be characterized
statistically. We have presented methods for each network node to probabilistically
characterize the local impact of a dynamic jamming attack and for data sources to
incorporate this information into the routing algorithm. We formulated multiple-path
traffic allocation in multisource networks as a lossy network flow optimization problem
using an objective function based on portfolio selection theory from finance. We showed
that this centralized optimization problem can be solved using a distributed algorithm
based on decomposition in network utility maximization (NUM).We presented
simulation results to illustrate the impact of jamming dynamics and mobility on network
throughput and to demonstrate the efficacy of our traffic allocation algorithm. We have
thus shown that multiple-path source routing algorithms can optimize the throughput
performance by effectively incorporating the empirical jamming impact into the
allocation of traffic to the set of paths.
REFERENCES

 D. J. Thuente and M. Acharya, “Intelligent jamming in wireless networks with

applications to 802.11 b and other networks,” in Proc.25th IEEE MILCOM, Washington,
DC, Oct. 2006, pp. 1–7.
 G. Lin and G. Noubir, “On link layer denial of service in data Wireless LANs,”Wireless
Commun. Mobile Comput., vol. 5, no. 3, pp. 273–284, May 2005.
 W. Xu, K. Ma, W. Trappe, and Y. Zhang, “Jamming sensor networks: Attack and defense
strategies,” IEEE Netw., vol. 20, no. 3, pp. 41–47, May/Jun. 2006.
 F. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: A survey,” Comput.
Netw., vol. 47, no. 4, pp. 445–487, Mar. 2005.
 D. P. Palomar and M. Chiang, “A tutorial on decomposition methods for network utility
maximization,” IEEE J. Sel. Areas Commun., vol. 24, no. 8, pp. 1439–1451, Aug. 2006.
 W. F. Sharpe, Investors and Markets: Portfolio Choices, Asset Prices, and Investment
Advice. Princeton, NJ: Princeton Univ. Press, 2007.
 E. M. Sozer, M. Stojanovic, and J. G. Proakis, “Underwater acoustic networks,” IEEE J.
Ocean. Eng., vol. 25, no. 1, pp. 72–83, Jan. 2000.
 R. Anderson, Security Engineering: A Guide to Building Dependable Distributed
Systems. New York: Wiley, 2001.
 J. Bellardo and S. Savage, “802.11 denial-of-service attacks: Real vulnerabilities and
practical solutions,” in Proc. USENIX Security Symp., Washington, DC, Aug. 2003, pp.
15–28.
 D.Wood and J. A. Stankovic, “Denial of service in sensor networks,” Computer, vol. 35,
no. 10, pp. 54–62, Oct. 2002.
 D. B. Johnson, D. A. Maltz, and J. Broch, DSR: The Dynamic Source Routing Protocol
for Multihop Wireless Ad Hoc Networks. Reading, MA: Addison-Wesley, 2001, ch. 5, pp.
139–172.
 E. M. Royer and C. E. Perkins, “Ad hoc on-demand distance vector routing,” in Proc.
2nd IEEE WMCSA, New Orleans, LA, Feb. 1999, pp. 90–100.
  R. Leung, J. Liu, E. Poon, A.-L. C. Chan, and B. Li, “MP-DSR: A QoS-aware multi-path
dynamic source routing protocol for wireless ad-hoc networks,” in Proc. 26th Ann. IEEE
LCN, Tampa, FL, Nov. 2001, pp. 132–141.
 H. Markowitz, “Portfolio selection,” J. Finance, vol. 7, no. 1, pp. 77–92, Mar. 1952.
 S. Boyd and L. Vandenberghe, Convex Optimization. Cambridge, U.K.: Cambridge Univ.
Press, 2004.
 D. P. Palomar and M. Chiang, “A tutorial on decomposition methods for network utility
maximization,” IEEE J. Sel. Areas Commun., vol. 24, no. 8, pp. 1439–1451, Aug. 2006.
 M. Evans, N. Hastings, and B. Peacock, Statistical Distributions, 3rd ed. New York:
Wiley, 2000.
 V. Paxson and M. Allman, “Computing TCP’s retransmission timer,” RFC 2988, Nov.
2000 [Online]. Available: http://www.ietf.org/rfc/ rfc2988.txt
 S. W. Roberts, “Control chart tests based on geometric moving averages,”
Technometrics, vol. 42, no. 1, pp. 97–101, Feb. 2000.

11. APPENDICES

11.1. SAMPLE CODING:

//package Login;

import java.sql.*;

import javax.swing.*;

import java.io.*;

import java.net.*;

import java.io.*;

import java.util.*;
public class Admin

JLabel l1,l2,l3,l4,l5,l6,l7;

JList li1,li2;

JList lis1,lis2;

JTextField tf1;

JButton b1,b2,b3,b4;

Container panel1;

JComboBox cb1;

String RH;

JScrollPane sb1,sb2,sb3,sb4;

DataBase_Connection DBC=new DataBase_Connection();

JFrame f=new JFrame();

Vector cli=new Vector();

Vector conn=new Vector();//package Login;

import java.awt.Dimension;

import java.awt.Point;

import java.awt.event.*;

import javax.swing.*;

import javax.swing.event.*;

import java.net.*;
import com.birosoft.liquid.LiquidLookAndFeel;

public class Registration

JLabel l1,l2,l3,l4,l5;

JTextField t1,t2,t3;

JButton b1,b2;

Container panel1;

Socket socket;

JFrame f=new JFrame();

Clientipaddress ca=new Clientipaddress();

sysname a = new sysname();

String ip= a.orgin();

String strSRep;

String PName,IPAdd,sPort,strReq,strRe,strRep;

public static ServerConnection sc =new ServerConnection();

public Registration()

initialization1();

try
 {

catch (Exception e1)

System.out.println(e1);

System.out.println("end");

public void initialization1()

l1=new JLabel("Node Registration");

l2=new JLabel("Name");

l3=new JLabel("IPAddress");

l4=new JLabel("PortNumber");

l5=new JLabel(new ImageIcon("loginimg.jpg"));

t1=new JTextField();

t2=new JTextField(ip);

t3=new JTextField();

b1=new JButton("Register");

// b2=new JButton("Complete");
 // l5.setIcon(new ImageIcon("bg.bmp"));

f=new JFrame();

panel1=(JPanel)f.getContentPane();

//panel1.setBackground(new Color(102,138,150));

t2.setEnabled(false);

f.setLayout(null);

addComponent(panel1, l5, 0,0,400,200);

/* b2.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e)

b2_actionPerformed(e);

}); */

b1.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e)

b1_actionPerformed(e);

});

f.setTitle("Node Registration");
 f.setLocation(new Point(50, 100));

f.setSize(new Dimension(400,500));

f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);

f.setVisible(true);

private void addComponent(Container container,Component c,int x,int y,int width,int

height)

c.setBounds(x,y,width,height);

container.add(c);

private void b2_actionPerformed(ActionEvent e)

System.exit(0);

private void b1_actionPerformed(ActionEvent e)

try

{
 PName=t1.getText().trim();

IPAdd=t2.getText().trim();

sPort=t3.getText().trim();

int ch;

strReq="Registration@"+PName+"@"+IPAdd+"@"+sPort;

socket=new Socket("localhost",8585);

ObjectOutputStream OutStream=new
ObjectOutputStream(socket.getOutputStream());

OutStream.writeObject(strReq);

ObjectInputStream InStream=new
ObjectInputStream(socket.getInputStream());

strSRep=(String)InStream.readObject();

String strSp[]=strSRep.split("&");

String strcValue=strSp[0];

String strRPeer=strSp[1];
 if(strcValue.equals("true"))

JOptionPane.showMessageDialog(null," Successfully
Login the Peer ","Information Message",JOptionPane.INFORMATION_MESSAGE);

f.dispose();

new TCreation(PName,IPAdd,sPort,strRPeer);

else

JOptionPane.showMessageDialog(null," Peer Details Not

in DataBase","Warning Message",JOptionPane.INFORMATION_MESSAGE);

catch(Exception ex)

ex.printStackTrace();

}
public static void main(String args[])

try{

//UIManager.setLookAndFeel("com.birosoft.liquid.LiquidLookAndFeel");

UIManager.setLookAndFeel(

//UIManager.getCrossPlatformLookAndFeelClassName());

UIManager.getSystemLookAndFeelClassName());

}catch(Exception e){

System.out.println("expc"+e.toString());

Registration reg=new Registration();

Vector cli2=new Vector();

Vector tl=new Vector();

Vector ts=new Vector();

private void b1_actionPerformed(ActionEvent e)

try

Vector trss=new Vector();

String strSp[]=RH.split("@");

DataBase_Connection DBC=new DataBase_Connection();

System.out.println(strSp[0]+""+strSp[1]+""+strSp[2]);

ts=DBC.RHs(strSp[0],strSp[1],strSp[2]);

lis2.setListData(ts);

trss=DBC.HH1();

// tl.add(strNode1+"@"+strNNode1+"@"+strNNode2);

lis1.setListData(trss);

catch (Exception ef)

11.2. SAMPLE SCREENSHOTS: