Network Border Patrol

Network Border Patrol - 1-

Network Border Patrol

Dept. of CSE KVSRIT


ABSTRACT

Network Border Patrol

The Internet’s excellent scalability and robustness result in part from the end-to-end nature of

Internet congestion control. End-to-end congestion control algorithms alone, however, are

unable to prevent the congestion collapse and unfairness created by applications that are

unresponsive to network congestion. To address these maladies, we propose and investigate a

novel congestion-avoidance mechanism called network border patrol (NBP). NBP entails the

exchange of feedback between routers at the borders of a network in order to detect and

restrict unresponsive traffic flows before they enter the network, thereby preventing

congestion within the network. Moreover, NBP is complemented with the proposed enhanced

core-stateless fair queuing (ECSFQ) mechanism, which provides fair bandwidth allocations to

competing flows.

Both NBP and ECSFQ are compliant with the Internet philosophy of

pushing complexity toward the edges of the network whenever possible. Simulation results

show that NBP effectively eliminates congestion collapse and that, when combined with

ECSFQ, approximately max-min fair bandwidth allocations can be achieved for competing

flows. ECSFQ is a mechanism where feedback control and rate control algorithm are

achieved.

Dept. of CSE KVSRIT


Dept. of CSE KVSRIT


Project Synopsis

Dept. of CSE KVSRIT


EXISTING SYSTEM

The present system has the TCP congestion control, which is implemented primarily

through algorithms operating at end systems. Unfortunately, TCP congestion control

also illustrates some of the shortcomings the end-to-end argument. As a result of its

strict adherence to end-to-end congestion control, the current Internet suffers from

main maladies.

DISADVANTAGES:

Congestion are unavoidable as network traffic increases

Packet loss may occur due to collapse

Packets may come in various speed it may lead to collision problem

Security is less

Flexibility and Scalability are limited

PROPOSED SYSTEM:

In the proposed system novel congestion-avoidance mechanism called network border

patrol (NBP) . NBP entails the exchange of feedback between routers at the borders of a

network in order to detect and restrict unresponsive traffic flows before they enter the

network, thereby preventing congestion within the network.

ADVANTAGES:

Network Border Patrol has been placed to control the speed of the packets.

Congestion is avoided as the speed decreases.

Packet loss is totally controlled

Security is high

Flexibility and Scalability are more.

Dept. of CSE KVSRIT


System Analysis

Dept. of CSE KVSRIT


MODULES:

REGISTRATION MODULE

CLIENT MODULE

SERVER MODULE

FEEDBACK MODULE

RATE CONTROL MODULE

REGISTRATION MODULE :

Every user must register with the server. Users are certified by the server to enter into

the network to prevent the unauthorized users access the server. Client and Server have an

authentication entry and also it is to differentiate between them.Sometimes by mistake, the

user inputs are wrong means, the server generates the warning to every mismatch inputs. The

server is matching the user name and password based on the database. If it is matched, then

the user get the connection otherwise the server quit the unauthorized person

CLIENT MODULE:

In this Module, first the user gives the user name and password for security.

Then, the user gives request for retrieving the file and gets the file from the server.

Suppose, the server communicates with another user also, the server acts as a supervisor

Dept. of CSE KVSRIT


between those users. Those users share the file with respect to the server. Every user

accessing the server with use of port and also identifies these port with its number. Clients

are the users, requests some files or data’s from the server. If it is available then the

request is converted into the response and the server responds or else it displays “File Not

Found”.

SERVER:

In this module, the server is the administrator of all the processes. The server

only checks the user is authorized or not. In this Group Communication System process is

functioning with help of cryptographic procedure. Based on the user defined query, the server

searches the corresponding file in the database and sends that file to the particular user. The

server has the user requirement file in its folder as well as it contains username, password,

status and sender IP address in its database. The server response to the request is sent to the

client .The packets which are sent by the server may vary from different speeds. If the speeds

vary congestion or collision or packet loss may occur.

FEEDBACK MODULE:

An algorithm has been followed to avoid the congestion or collision while

transfer of packets which varies in different speeds.A Feedback algorithm is followed to

check the various speeds of the packets and finds which packet speed has to be reduced.

Normally packets are traversed in various speeds. Because of traveling with various speeds

there is a chance of congestion or packet loss occurrence. The above problem plays a main

and important part in the current network topology. To overcome this we are following a

patrol type method to control the speed of the packet to certain level. To attain this we have to

find the speed, an algorithm has been followed i.e.; the feedback control algorithm in NBP

determines the speed flow of the packets.

Dept. of CSE KVSRIT


RATE CONTROL MODULE:

Network Border Patrol comes into existence in this module where after finding the

feedback, a rate has been reduced by the patrol near the entry point of the network router.

Which a packet the speed has to reduce has been insisting by the feedback algorithm,

accordingly the rate has been reduced and controlled by following the rate control

algorithm.To overcome the congestion problem we are following a patrol type method to

control the speed of the packet to certain level. After finding the feed back & if it is found to

be fast the rate of the packet are controlled or reduced to certain limit. The packets are

patrolled in such a manner congestions are reduced .i.e.; The NBP rate-control algorithm

regulates the rate at which each flow is allowed to enter the network.

SOFTWARE REQUIREMENTS:-

Java1.3 or More

Swings

Windows 98 or more

HARDWARE REQUIREMENTS

Processor : Intel P-III based system

Processor Speed : 250 MHz to 833MHz

RAM : 64MB to 256MB

Hard Disk : 2GB to 30GB

Dept. of CSE KVSRIT


Proposed System

Description

Dept. of CSE KVSRIT


Network Border Patrol is a network layer congestion avoidance protocol that is aligned with

the “core-stateless” approach. The core-stateless approach, which has recently received a

great deal of research attention, allows routers on the borders (or edges) of a network to

perform flow classification and maintain per-flow state but does not allow routers at the core

of the network to do so. Below Figures illustrates this architecture. As in other work on core

stateless approaches, we draw a further distinction between two types of edge routers.

Depending on which flow it is operating on, an edge router may be viewed as an ingress or an

egress router. An edge router operating on a flow passing into a network is called an ingress

router, whereas an edge router operating on flow passing out of a network is called an egress

router. Note that a flow may pass through more than one egress (or ingress) router if the end-

to-end path crosses multiple networks.

Fig 1

NBP prevents congestion collapse through a combination of per-flow rate monitoring at

egress routers and per-flow rate control at ingress routers. Rate monitoring allows an

egress router to determine how rapidly each flow’s packets are leaving the network,

whereas rate control allows an ingress router to police the rate at which each flow’s

packets enter the network. Linking these two functions together are the feedback packets

exchanged between ingress and egress routers; ingress routers send egress routers forward

feedback packets to inform them about the flows that are being rate controlled, and egress

routers send ingress routers backward feedback packets to inform them about the rates at

which each flow’s packets are leaving the network. By matching the ingress rate and

Dept. of CSE KVSRIT


egress rate of each flow, NBP prevents congestion collapse within the network1. This

section describes three important aspects of the NBP mechanism:

modified edge routers, which must be present in the network,

the feedback control algorithm, which determine show and when information is

exchanged between edge routers, and

the rate control algorithm, which uses the information carried in feedback packets to

regulate flow transmission rates and thereby prevent congestion collapse in the network.

Dept. of CSE KVSRIT


The Feedback Control Algorithm

The feedback control algorithm in NBP determines how and when feedback packets are

exchanged between edge routers. Feedback packets take the form of ICMP packets and

are necessary in NBP for three reasons. First, forward feedback packets allow egress

routers to discover which ingress routers are acting as sources for each of the flows they

are monitoring. Second, backward feedback packets allow egress routers to communicate

per-flow bit rates to ingress routers. Third, forward and backward feedback packets allow

ingress routers to detect incipient network congestion by monitoring edge-to-edge round

trip times.

The contents of feedback packets are shown in Figure 5. Contained within the forward

feedback packet generated at an ingress router are a time stamp and a list of flow

specifications for flows originating at the ingress router. The time stamp field is used to

calculate the round trip time between two edge routers, and the list of flow specifications

indicates to an egress router the identities of active flows originating at the ingress router.

A flow specification is a value uniquely identifying a flow, assigned by the ingress router

Dept. of CSE KVSRIT


flow classifier. An ingress router adds a flow to its list of active flows whenever a packet

from a new flow arrives; it removes a flow when the flow becomes inactive. In the event

that the network’s maximum transmission unit size is not sufficient to hold an entire list of

flow specifications, multiple forward feedback packets are used. When an egress router

receives a forward feedback packet, it immediately generates a backward feedback packet

and returns it to the ingress router. Contained within the backward feedback packet are the

forward feedback packet’s original time stamp, a hop count, and a list of observed bit

rates, called egress rates, collected by the egress router for each flow listed in the forward

feedback packet. The hop count, which is used by the ingress router’s rate control

algorithm, indicates how many routers are in the path between the ingress and the egress

router. The egress router determines the hop count by examining the time to live (TTL)

field of arriving forward feedback packets. When the backward feedback packet arrives at

the ingress router, its contents are passed to the ingress router’s rate controller, which uses

them to adjust the parameters of each flow’s traffic shaper.

In order to determine how often to generate forward feedback packets

an ingress router keeps a byte transmission counter for each flow it monitors. Whenever a

flow’s byte transmission counter exceeds a threshold, denoted NBP’s transmission

counter threshold (Tx), the ingress router generates and transmits a forward feedback

packet to the flow’s egress router, and resets the the byte transmission counters of all

flows included in the feedback packet. Using a byte ransmission counter for each flow

ensures that forward feedback packets are generated more frequently when flows transmit

at higher rates, thereby allowing ingress routers to respond more quickly to impending

congestion collapse. To maintain a frequent flow of feedback between edge routers even

when data transmission rates are low, ingress routers also generate forward feedback

packets whenever a time-out interval, denoted _f , is exceeded. A rough estimate of the

amount of overhead that NBP feedback packets create is provided in the Appendix of this

paper.

Dept. of CSE KVSRIT


The Rate Control Algorithm:

The NBP rate control algorithm regulates the rate at which each flow is allowed to enter

the network. Its primary goal is to converge on a set of per-flow transmission rates

(hereinafter called ingress rates) that prevents congestion collapse due to undelivered

packets. It also attempts to lead the network to a state of maximum link utilization and low

router buffer occupancies, and it does this in a manner that is similar to TCP.

In the NBP rate control algorithm, shown in Figure 6, a flow may be in one of two phases,

slow start or congestion avoidance, similar to the phases of TCP congestion control. The

desirable stability characteristics of slow start and congestion control algorithms have

been proven in TCP congestion control, and NBP expects to benefit from their

on arrival of Backward Feedback packet p from egress router e

currentRTT = currentTime - p.timestamp;

if (currentRTT < e.baseRTT)

e.baseRTT = currentRTT;

deltaRTT = currentRTT - e.baseRTT;

RTTsElapsed = (currentTime - e.lastFeedbackTime) / currentRTT;

e.lastFeedbackTime = currentTime;

for each flow f listed in p

rateQuantum = min (MSS / currentRTT, f.egressRate / QF);

if (f.phase == SLOW_START)

if (deltaRTT ´ f.ingressRate < MSS ´ e.hopcount)

f.ingressRate = f.ingressRate ´ 2 ^ RTTsElapsed;

else

f.phase = CONGESTION_AVOIDANCE;

if (f.phase == CONGESTION_AVOIDANCE)

if (deltaRTT ´ f.ingressRate < MSS ´ e.hopcount)

f.ingressRate = f.ingressRate + rateQuantum * RTTsElapsed;

else

Dept. of CSE KVSRIT


f.ingressRate = f.egressRate - rateQuantum;

Figure 6: Pseudocode for ingress router rate control algorithm

well-known stability features. In NBP, new flows entering the network start with the slow

start phase and proceed to the congestion avoidance phase only after the flow has

experienced incipient congestion.

The rate control algorithm is invoked whenever a backward feedback packet arrives at an

ingress router. Recall that backward feedback packets contain a timestamp and a list of

flows arriving at the egress router from the ingress router as well as the monitored egress

rates for each flow. Upon the arrival of a backward feedback packet, the algorithm

calculates the current round trip time (currentRTT in Figure 6) between the edge routers

and updates the base round

trip time (e.baseRTT), if necessary. The base round trip time (e.baseRTT) reflects the best

observed round trip time between the two edge routers. The algorithm then calculates

deltaRTT, which is the difference between the current round trip time (currentRTT) and

the base round trip time (e.baseRTT). A deltaRTT value greater than zero indicates that

packets are requiring a longer time to traverse the network than they once did, and this can

only be due to the

buffering of packets within the network.

NBP’s rate control algorithm decides that a flow is experiencing incipient congestion

whenever it estimates that the network has buffered the equivalent of more than one of the

flow’s packets at each router hop. To do this, the algorithm first computes the product of

the flow’s ingress rate (f.ingressRate) and deltaRTT (i.e., f.ingressRate _ deltaRTT). This

value provides an estimate of the amount of the flow’s data that is buffered somewhere in

the network. If this amount (i.e., f.ingressRate _ deltaRTT) is greater than the number of

router hops between the ingress and the egress routers (e.hopcount) multiplied by the size

of the largest possible packet (MSS) (i.e., MSS _ e.hopcount), then the flow is considered

to be experiencing incipient congestion. The rationale for determining incipient

congestion in this manner is to maintain both high link utilization and low queueing delay.

Ensuring there is always at least one packet buffered for transmission on a network link is

Dept. of CSE KVSRIT


the simplest way to achieve full utilization of the link, and deciding that congestion exists

when more than one packet is buffered at the link keeps queueing delays low.

Therefore, NBP’s rate control algorithm allows the “equivalent” of

e.hopCount packets to be buffered in flow f’s path before it reacts to congestion by

monitoring deltaRTT 2. A similar approach is used in the DECbit congestion avoidance

mechanism. Furthermore, the approach used by NBP’s rate control algorithm to detect

congestion, by estimating whether the network has buffered the equivalent of more than

one of the flow’s packets at each router hop, has the advantage of , when congestion

occurs, flows with higher ingress rates detect congestion first. This is because the

condition f.ingressRate _ deltaRTT ¡ MSS _ e.hopcount fails first for flows f with a large

ingress rate, detecting that the path is congested due to ingress flow f.

When the rate control algorithm determines that a

flow is not experiencing congestion, it increases the flow’s ingress rate. If the flow is in

the slow start phase, its ingress rate is doubled for each round trip time that has elapsed

since the last backward feedback packet arrived (f.ingress _2RTTsElapsed). The estimated

number of round trip times since the last feedback packet arrived is denoted as

RTTsElapsed. Doubling the ingress rate during slow start allows a new flow to rapidly

capture available bandwidth when the network is underutilized. If, on the other hand, the

flow is in the congestion avoidance phase, then its ingress rate is conservatively

incremented by one rateQuantum value for each round trip that has elapsed since the last

backward feedback packet arrived (f.ingressRate + rateQuantum_ RTTsElapsed). This is

done to avoid the creation of congestion. The rate quantum is computed as the maximum

segment size divided by the current round trip time between the edge routers. This results

in rate growth behavior that is similar to TCP in its congestion avoidance phase.

Furthermore, the rate quantum is not allowed to exceed the flow’s current egress rate

divided by a constant quantumfactor (QF). This guarantees that rate increments are not

excessively large when the round trip time is small 3.

Dept. of CSE KVSRIT


When the rate control algorithm determines that a flow is

experiencing incipient congestion, it reduces the flow’s ingress rate. If a flow is in the

slow start phase, it enters the congestion avoidance phase. If a flow is already in the

congestion avoidance phase, its ingress rate is reduced to the flow’s egress rate

decremented by a constant value. In other words, an observation of incipient congestion

forces the ingress router to send the flow’s packets into the network at a rate slightly lower

than the rate at which they are leaving the network. NBP’s rate control algorithm is

designed to have minimum impact on TCP flows. The rate at which NBP regulates each

flow (f.ingressRate) is primarily a function of the round trip time between the flow’s

ingress and egress routers (currentRTT). In NBP, the initial ingress rate for a new flow is

set to be MSS/e.baseRTT, following TCP’s initial rate of one segment per round trip time.

NBP’s currentRTT is always smaller than TCP’s end-to-end round trip time (as the

distance between ingress and egress routers, i.e., the currentRTT in NBP, is shorter than

end to end distance, i.e., TCP’s RTT). As a result, f.ingressRate is normally larger than

TCP’s transmission rate when the network is not congested, since TCP transmission

window increases at a rate slower than NBP’s f.ingressRate increases. Therefore, NBP

normally does not regulate TCP flows. However, when congestion occurs, NBP reacts

first by reducing f.ingressRate and, therefore, reducing the rate at which TCP packets are

allowed to enter the network. TCP eventually detects the congestion (either by loosing

packets or due to longer round trip times) and then promptly reduces its transmission rate.

From this time point on, f.ingressRate becomes greater than TCP’s transmission rate, and

therefore, NBP’s congestion control do not regulate TCP sources until congestion happens

again.

Dept. of CSE KVSRIT


System Design

Dept. of CSE KVSRIT


Data Flow

Diagram’s

Dept. of CSE KVSRIT


AUTHENTICATION MODULE

Dept. of CSE KVSRIT

START

IS VALID?

ENTER USERNAME &

PWD

REGISTER WITH THE SERVER


CLIENT

Dept. of CSE KVSRIT

CLIENT

REGISTERS WITH THE SERVER

REQUEST FOR FILE TO THE SERVER


SERVER

Dept. of CSE KVSRIT

SERVER

CHECK FOR THE FILE AND IF IT IS AVAILABLE

RESPONDS TO THE CLIENT

PACKET HAS BEEN SENT TO THE APPROPRIATE CLIENT


FEEDBACK

Dept. of CSE KVSRIT

SERVER

ACTIVATES THE NBP AT THE ROUTER

PACKET SPEED HAS BEEN MONITORED


RATECONTROL MODULE

Dept. of CSE KVSRIT

SERVER

BASED ON THE PREDEFINED VALUE FOR

THE SPEED OF THE PACKETS

PACKET SPEED HAS BEEN CONTROLLED


Dept. of CSE KVSRIT

START

ENTER USERNAME &

PWD

IS VALID?

CLIENT REQUEST FOR FILE

PACKETS ARE SENT FROM SERVER

CHECK IF PACKET SPEED

IS HIGH?

NBP IS ACTIVATED AND THE SPEED IS REDUCED TO AVOID CONGESTION

PACKETS SENT SUCCESSFULLY TO THE CLIENT

STOP

NO

NO

YES

YES


UML Diagram’s

Dept. of CSE KVSRIT


Sequence Diagram

Dept. of CSE KVSRIT

source Ingress Router Egress Destination

Data packets

Data packets

Forward feedback

Backward feedback

Data packets

Forward feedback

Data packets

Backward feedback


Software Overview

Dept. of CSE KVSRIT


FEATURES OF THE LANGUAGE USED

Front-end tool: JAVA 1.3

About Java

Initially the language was called as “oak” but it was renamed as “Java” in 1995. The

primary motivation of this language was the need for a platform-independent (i.e.,

architecture neutral) language that could be used to create software to be embedded in various

consumer electronic devices.

Java is a programmer’s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment,

Java gives the programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

Applications and Applets

An application is a program that runs on our Computer under the operating system

of that computer. It is more or less like one creating using C or C++. Java’s ability to

create Applets makes it important. An Applet is an application designed, to be transmitted

over the Internet and executed by a Java –compatible web browser. An applet is actually

a tiny Java program, dynamically downloaded across the network, just like an image. But

the difference is, it is an intelligent program, not just a media file. It can react to the user

input and dynamically change.

FEATURES OF JAVA

Security

Every time you that you download a “normal” program, you are risking a viral

infection. Prior to Java, most users did not download executable programs frequently, and

those who did scanned them for viruses prior to execution. Most users still worried about the

possibility of infecting their systems with a virus. In addition, another type of malicious

Dept. of CSE KVSRIT


program exists that must be guarded against. This type of program can gather private

information, such as credit card numbers, bank account balances, and passwords. Java

answers both of these concerns by providing a “firewall” between a networked application

and your computer. When you use a Java-compatible Web browser, you can safely download

Java applets without fear of virus infection or malicious intent.

Portability

For programs to be dynamically downloaded to all the various types of platforms

connected to the Internet, some means of generating portable executable code is needed .As

you will see, the same mechanism that helps ensure security also helps create portability.

Indeed, Java’s solution to these two problems is both elegant and efficient.

The Byte code

The key that allows the Java to solve the security and portability problem is that the

output of Java compiler is Byte code. Byte code is a highly optimized set of instructions

designed to execute by the Java run-time system, which is called the Java Virtual Machine

(JVM). That is, in its standard form, the JVM is an interpreter for byte code.

Translating a Java program into byte code helps makes it much easier to run a program

in a wide variety of environments. The reason is, Once the run-time package exists for a given

system, any Java program can run on it.

Although Java was designed for interpretation, there is technically nothing about Java

that prevents on-the-fly compilation of byte code into native code. Sun has just completed its

Just In Time (JIT) compiler for byte code. When the JIT compiler is a part of JVM, it

compiles byte code into executable code in real time, on a piece-by-piece, demand basis. It is

not possible to compile an entire Java program into executable code all at once, because Java

performs various run-time checks that can be done only at run time. The JIT compiles code,

as it is needed, during execution.

Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine is an

important element of the Java technology. The virtual machine can be embedded within a web

browser or an operating system. Once a piece of Java code is loaded onto a machine, it is

Dept. of CSE KVSRIT


verified. As part of the loading process, a class loader is invoked and does byte code

verification makes sure that the code that’s has been generated by the compiler will not

corrupt the machine that it’s loaded on. Byte code verification takes place at the end of the

Compilation process to make sure that is all accurate and correct. So byte code verification is

integral to the compiling and executing of Java code.

.Java .Class

The above picture shows the development process a typical Java programming uses to

produce byte codes and executes them. The first box indicates that the Java source code is

located in a. Java file that is processed with a Java compiler called JAVA. The Java compiler

produces a file called a. class file, which contains the byte code. The class file is then loaded

across the network or loaded locally on your machine into the execution environment is the

Java virtual machine, which interprets and executes the byte code.

Java Architecture

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java Virtual

Machine, which is then interpreted on each platform by the run-time environment. Java is a

dynamic system, able to load code when needed from a machine in the same room or across

the planet.

Compilation of Code

When you compile the code, the Java compiler creates machine code (called byte

code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to

execute the byte code. The JVM is created for overcoming the issue of portability. The code is

written and compiled for one machine and interpreted on all machines. This machine is called

Java Virtual Machine.

Dept. of CSE KVSRIT

Java Source

Java Byte Code

Java Virtual Machine

Javac


Compiling and interpreting Java Source Code

During run-time the Java interpreter tricks the byte code file into thinking that it is running on

a Java Virtual Machine. In reality this could be a Intel Pentium Windows 95 or SunSARC

station running Solaris or Apple Macintosh running system and all could receive code from

any computer through Internet and run the Applets.

SIMPLE

Java was designed to be easy for the Professional programmer to learn and to use

effectively. If you are an experienced C++ programmer, learning Java will be even easier.

Because Java inherits the C/C++ syntax and many of the object oriented features of C++.

Most of the confusing concepts from C++ are either left out of Java or implemented in a

cleaner, more approachable manner. In Java there are a small number of clearly defined ways

to accomplish a given task.

Dept. of CSE KVSRIT

Source Code………..………..

………..

…………

PC Compiler

MacintoshCompiler

SPARCCompiler

Java

Byte code

(Platform

Independent)

JavaInterpreter(PC)

JavaInterpreter(Macintosh

)

Java Interpreter (Sparc)


Object-Oriented

Java was not designed to be source-code compatible with any other language. This

allowed the Java team the freedom to design with a blank slate. One outcome of this was a

clean usable, pragmatic approach to objects. The object model in Java is simple and easy to

extend, while simple types, such as integers, are kept as high-performance non-objects.

Robust

The multi-platform environment of the Web places extraordinary demands on a

program, because the program must execute reliably in a variety of systems. The ability to

create robust programs was given a high priority in the design of Java. Java is strictly typed

language; it checks your code at compile time and run time. Java virtually eliminates the

problems of memory management and de-allocation, which is completely automatic. In a

well-written Java program, all run time errors can –and should –be managed by your program.

SWING

Swing is a set of classes that provides more powerful and flexible components than

are possible with the AWT. In addition to that the familiar components such as buttons,

check box and labels swings supplies several exciting additions including tabbed panes,

scroll panes, trees and tables. Even familiar components such as buttons have more

capabilities in swing.

For example a button may have both an image and text string associated with it. Also

the image can be changed as the state of button changes. Unlike AWT components swing

components are not implemented by platform specific code instead they are return entirely in

JAVA and, therefore , are platform- independent. The term lightweight is used to describe

such elements. The number of classes and interfaces in the swing packages is substantial.

The swing component classes are

Dept. of CSE KVSRIT


SWING COMPONENT CLASSES

Class Description

Abstract Button Abstract super class for Swing

Buttons

Button Group Encapsulates a mutually exclusive

Set of Buttons

Image Icon Encapsulates an Icon

Japplet The swing version of Applet

Jbutton The Swing Push Button class

JcheckBox The swing CheckBox class

JcomboBox Encapsulates a combobox

JLabel The swing version of a Label

JradioButton The swing version of a RadioButton

Dept. of CSE KVSRIT


Networking Classes in the JDK

Through the classes in java.net, Java programs can use TCP or UDP to communicate over

the Internet. The URL, URL Connection, Socket, and Server Socket classes all use TCP to

communicate over the network. The Datagram Packet, Datagram Socket, and Multicast

Socket classes are for use with UDP.

What Is a URL?

If you've been surfing the Web, you have undoubtedly heard the term URL and have used

URLs to access HTML pages from the Web.

It's often easiest, although not entirely accurate, to think of a URL as the name of a file on the

World Wide Web because most URLs refer to a file on some machine on the network.

However, remember that URLs also can point to other resources on the network, such as

database queries and command output.

Definition: URL is an acronym for Uniform Resource Locator and is a reference (an address)

to a resource on the Internet.

The following is an example of a URL which addresses the Java Web site hosted by Sun

Microsystems:

As in the previous diagram, a URL has two main components:

Protocol identifier

Resource name

Note that the protocol identifier and the resource name are separated by a colon and two

forward slashes. The protocol identifier indicates the name of the protocol to be used to fetch

the resource. The example uses the Hypertext Transfer Protocol (HTTP), which is typically

used to serve up hypertext documents. HTTP is just one of many different protocols used to

Dept. of CSE KVSRIT


access different types of resources on the net. Other protocols include File Transfer Protocol

(FTP), Gopher, File, and News.

The resource name is the complete address to the resource. The format of the resource name

depends entirely on the protocol used, but for many protocols, including HTTP, the resource

name contains one or more of the components listed in the following table:

Host Name The name of the machine on which the resource lives.

Filename The pathname to the file on the machine.

Port Number The port number to which to connect (typically optional).

Reference A reference to a named anchor within a resource that usually

identifies a specific location within a file (typically optional).

For many protocols, the host name and the filename are required, while the port number and

reference are optional. For example, the resource name for an HTTP URL must specify a

server on the network (Host Name) and the path to the document on that machine (Filename);

it also can specify a port number and a reference. In the URL for the Java Web site

java.sun.com is the host name and the trailing slash is shorthand for the file named

/index.html.

Sequence of socket calls for connection-oriented protocol:

System Calls

Socket - create a descriptor for use in network communication. On success, socket

system call returns a small integer value similar to a file descriptor Name.

Bind - Bind a local IP address and protocol port to a socket

When a socket is created it does not have nay notion of endpoint address. An

application calls bind to specify the local; endpoint address in a socket. For TCP/IP protocols,

the endpoint address uses the socket address in structure. Servers use bind to specify the well-

known port at which they will await connections.

Connect - connect to remote client

After creating a socket, a client calls connect to establish an actual connection to a

remote server. An argument to connect allows the client to specify the remote endpoint, which

Dept. of CSE KVSRIT


include the remote machines IP address and protocols port number. Once a connection has

been made, a client can transfer data across it.

Accept () - accept the next incoming connection

Accept creates a new socket for each new connection request and returns the

descriptor of the new socket to its caller. The server uses the new socket only for the new

connections it uses the original socket to accept additional connection requests once it has

accepted connection, the server can transfer data on the new socket.

Return Value:

This system-call returns up to three values

An integer return code that is either an error indication or a new socket description

The address of the client process

The size of this address

Listen - place the socket in passive mode and set the number of incoming TCP

connections the system will en-queue. Backlog - specifies how many connections requests can

be queued by the system while it wants for the server to execute the accept system call it us

usually executed after both the socket and bind system calls, and immediately before the

accept system call.

send, send to, receive and receive from system calls

These system calls are similar to the standard read and write system calls, but

additional arguments are requested.

close - terminate communication and de-allocate a descriptor. The normal UNIX close system

call is also used to close a socket.

Back-end tool: MS-ACCESS

It minimizes data contention and guarantees data concurrency.

Access maintains the preceding features with a high degree of overall system

performance.

Database users do not suffer from slow processing performance.

Access also offers the heterogeneous option that allows users to access data on

some non oracle database transparently.

Dept. of CSE KVSRIT


While most software development, web page design, etc. nowadays is done using

graphical user interfaces, experienced Unix/Linux people appreciate the simplicity and

efficiency of the powerful text-based tools available on those platforms. If you are familiar for

example with one of the powerful text editors, such as Emacs or VI, it is very easy to work

remotely (over the Internet or intranet) on other computers using Telnet or SSH connections

Dept. of CSE KVSRIT


Testing & Debugging Strategies

Dept. of CSE KVSRIT


Overview

Software testing identifies errors at an early stage and hence prevents a breakdown at a

later stage, where it might be costlier. It is not unusual for a software development

organization to expend 40% of the total project effort on testing. In the extreme, the testing of

mission-critical software (e.g., flight control, nuclear reactor monitoring) can cost three to five

times as much as all other software engineering activities combined.

A planned testing identifies the difference between the expected results and the actual results.

Since the main objective of software testing is to find errors, the person who does it must

work to prove that the software fails. A successful testing is one that uncovers, as many as yet

undiscovered errors, which helps to make the software more rugged and reliable. However it

should be clear, that testing cannot show the absence of defects, it can only highlight that the

defects are present in software.

Levels of Testing

Testing is applied at different levels in the software development life-cycle, but the

testing done is different in nature and has different objectives at each level. The focus of all

testing is to find errors, but different type of errors are looked for at each level.

The levels of testing in a development project could be:

Unit Testing : To test individual software items

Integration Testing : To test the interfaces between the software items

System Testing : To validate the entire product

Acceptance Testing : To test the product for acceptance

Further levels of testing than stated above could include

Alpha Testing : Testing by users at the developers site or on a test environment

Beta Testing : Testing by a large number of users at the user site

Field Testing : To test the system on the target environment

All levels of testing should be planned in advance and conducted systematically. The

activities that are to be carried out include:

Test planning

Test case preparation

Test execution

Dept. of CSE KVSRIT


Unit testing (White Box Testing)

At the lowest level, the function of the basic unit of software is tested in isolation. This is

where the most detailed investigation of the internal workings of individual units are carried

out. Unit testing is often performed by the programmer who wrote the code.

The purpose of unit testing is to find errors in the individual units, which could be data or

logic related errors. The test can be derived from the program specification or design

document. Units which cannot be tested in isolation may require the creation of small test

programs known as test harness.

Activities to be followed for Unit Testing

Ensure that all paths are traversed and branching takes properly.

Ensure that instructions related to a testcase are executed properly.

Verify operation at normal value range.

Verify operation outside range values.

Verify program execution at boundary conditions.

Check the calls to all programs.

Ensure all data structures are handled properly.

Check file handling.

Ensure that all loops are terminated normally.

Identify and remove abnormal termination of all loops.

Ensure all errors are trapped.

Check the values returned from called programs ( stubs may be used if called

program is not yet ready)

Integration testing (Interfaces Testing)

When two or more tested units are combined the tests should look for errors in two ways;

in the interfaces between the units and in the functions which can be performed by the

integrated unit which could not be assessed during unit testing.

The tests are derived from the design document.

System testing (Functionality Testing)

After integration testing is completed the entire system is tested as whole. System testing

looks for errors in the end-to-end functionality of the system and also for errors in non-

Dept. of CSE KVSRIT


functional quality attributes such as performance, reliability, volume, usability,

maintainability security etc. System testing can be carried out by independent personnel.

The tests are derived from the Functional Specification

Regression testing

Regression testing is a testing process that is applied after the programs are modified.

Regression testing is a major component in maintenance and conversion projects.

Modifying a program involves creating new logic to correct an error or implement a

change, and incorporating that logic into an existing program. The new logic may involve

minor modification such as adding, deleting or rewriting a few lines of code or may involve

major modifications such as adding, deleting or replacing one or more modules or sub-

systems. Regression testing aims to check the correctness of the new logic, to ensure the

continuous working of the unmodified portions of a program and to validate that the whole

functions correctly.

Acceptance testing (Black Box Testing)

After system testing or regression testing is completed, the system is handed over to the

customer or user, and acceptance testing marks the transition from ownership by the

developers to the ownership by the users. The acceptance test is different in nature in three

ways:

It is the responsibility of the accepting organization rather than the developing

organization

The purpose of acceptance testing is to give confidence that the system is

working rather than trying to find errors. The acceptance testing is a

demonstration rather than a test.

Acceptance testing also includes testing of the user organization working

practices, to ensure the computer system will fit the operational procedures.

The acceptance test gives a confidence to the users that the system is ready for

operational use.

General tips

For every testing activity planning should be done. Test plan should be prepared,

reviewed and approved before testing commences. Test plan should be documented and

testing should be done as per the approved plan.

Dept. of CSE KVSRIT


Test cases should be prepared, reviewed and approved prior to testing and must be as per

the test plan. A good test should have a reasonable probability of catching an error. It should

not be redundant and should make the program failure obvious without being too simple or

too complex.

Tests must be documented for their description, expected results and actual results. If a

bug is discovered, its nature, severity and fix done should also be documented

Testing never ends, it just gets transferred from the developer to the customer. Every time the

customer uses the program a test gets conducted. The testing process during development

should therefore terminate when the number of errors found in the unit time reduces to a very

low extent.

For system or regression testing it is preferable to install the system afresh.For multi-

user systems aspects such as security measures, integrity and recovery measures

mustbethoroughly tested.Test Plan should indicate the test coverage ( statement, path, branch

and usage profile)

Dept. of CSE KVSRIT


Output Screens

Dept. of CSE KVSRIT


Dept. of CSE KVSRIT


Conclusion&

Recommendations

Dept. of CSE KVSRIT


Conclusion and Recommendations:

In our project, we have presented a novel congestion-avoidance mechanism for the Internet

called NBP and an ECSFQ mechanism. Unlike existing Internet congestion control

approaches, which rely solely on end-to-end control, NBP is able to prevent congestion

collapse from undelivered packets. ECSFQ complements NBP by providing fair bandwidth

allocations in a core-stateless fashion. NBP ensures at the border of the network that each

flow’s packets do not enter the network faster than they are able to leave it, while ECSFQ

ensures, at the core of the network that flows transmitting at a rate lower than their fair share

experience no congestion.

Dept. of CSE KVSRIT


Dept. of CSE KVSRIT


Bibliography

Dept. of CSE KVSRIT


BIBLIOGRAPHY

S No. TITLE AUTHOR PUBLICATION EDITION

1. THE COMPLETE PATRICK NAUGHTON TATA McGraw 1994

REFERENCE JAVA2 HERBERT SCHILDT HILL

2. JAVA JAWORSICK TECH.MEDIA 1998 CERTIFICATION

Publication

3. COMPLETE JAVA 2 ROBERT HELLERS DPB 1998

ERNEST PUBLICATIONS

4. CRYPTOGRAPHY JOHN E. HERSHEY TATA Mc Graw 2004

DEMYSTIFIED HILL

5. MASTERING JAVA RICH HELTON WILEY 2002

SECURITY JOHENNIE HELTON Dreamtech

6. JAVA NETWORK OREILLY 2004

PROGRAMMING PUBLICATIONS

7. SOFTWARE ROGER PRESSMAN TATA Mc Graw 2004

ENGINEERING HILL

Dept. of CSE KVSRIT


Dept. of CSE KVSRIT

Network Border Patrol

Documents

Transcript of Network Border Patrol