File of SIMULATION OF NETWORK PROTOCOLS

Simulation of Network Protocols

1. INTRODUCTION

The project entitled “Simulation of Network Protocols” is to create a simple but

effective Graphical User Interface (GUI) for simulating Network Protocols i.e. GO-

BACK-N and SELECTIVE REPEAT. This simulation provides a graphical display of

how packets are transmitted from the sender to receiver, and the concept of these

protocols is described fully using visual effects. This project is very useful for giving a

look and feel to students learning these concepts, instead of reading and imagining about

them they can see how all this actually work.

Basically, Simulation is the imitation of the operation of a real-world process or system

over time. The act of simulating something first requires that a model be developed; this

model represents the key characteristics or behaviors of the selected physical or abstract

system or process. The model represents the system itself, whereas the simulation

represents the operation of the system over time.

1.1 WHAT IS SIMULATION?

1.1.1 Definition

Simulation is the imitation of the operation of a real-world process or system over

time. The act of simulating something first requires that a model be developed; this

model represents the key characteristics or behaviors of the selected physical or abstract

system or process. The model represents the system itself, whereas the simulation

represents the operation of the system over time.

1


Simulation is a powerful and important tool because it provides a way in which

alternative designs, plans and/or policies can be evaluated without having to experiment

on a real system, which may be prohibitively costly, time-consuming, or simply

impractical to do. That is, it allows you to ask "What if?" questions about a system

without having to experiment on the actual system itself.

1.1.2 Types of Simulation

Three types of simulations are there: live, virtual and constructive. A simulation also

may be a combination of two or more styles. Within these styles, simulations can be

science-based (where, for example, interactions of things are observed or measured), or

involve interactions with humans.

1. Live simulations:

Typically involve humans and/or equipment and activity in a setting where they would

operate for real. Think war games with soldiers out in the field or manning command

posts. Time is continuous, as in the real world. Another example of live simulation is

testing a car battery using an electrical tester.

2. Virtual simulations:

Typically involve humans and/or equipment in a computer-controlled setting. Time is in

discrete steps, allowing users to concentrate on the important stuff, so to speak. A flight

simulator falls into this category.

3. Constructive simulations:

2


Typically do not involve humans or equipment as participants. Rather than by time, they

are driven more by the proper sequencing of events. The anticipated path of a hurricane

might be "constructed" through application of temperatures, pressures, wind currents etc.

1.2 ENCAPSULATION AND LAYERED COMMUNICATION

As data is passed from the user application down the virtual layers of the OSI model,

each layer adds a header (and sometimes a trailer) containing protocol information

specific to that layer. These headers are called Protocol Data Units (PDUs), and the

process of adding these headers is called encapsulation. Note that in the TCP/IP protocol

suite only the lower layers perform encapsulation, generally.For example, a Transport

layer protocol such as TCP will add a header containing flow control, port numbers, and

sequencing. The Network layer header contains logical addressing information, and the

Data-link header contains physical addressing and other hardware specific information.

The PDU of each layer is identified with a different term:

Layer PDU Name

Application -

Transport Segments

Network Packets

Data-Link Frames

Physical Bits

Table 1: Depicts the PDU names at different layers.

Each layer communicates with the corresponding layer on the receiving device. For

example, on the sending device, source and destination hardware addressing is placed in

3


a Data-link header. On the receiving device, that Data-link header is processed and

stripped away (decapsulated) before being sent up to the Network and other upper

layers.Network devices are commonly identified by the OSI layer they operate at; or,

more specifically, what header or PDU the device processes.

For example, switches are generally identified as Layer-2 devices, as switches process

information stored in the Data-Link header of a frame, such as Ethernet MAC addresses.

Similarly, routers are identified as Layer- 3 devices, as routers process logical

addressing information in the Network header of a packet, such as IP addresses.

1.2.1 Encapsulation illustration

The following illustrates how basic encapsulation occurs with the OSI stack, which

typically performs encapsulation only at the lower layers:

Fig. 1: Encapsulation occurs at different layers .

4


During encapsulation on the sending host:

• Data from the user application is handed off to the Transport layer.

• The Transport layer adds a header containing protocol-specific information, and then

hands the segment to the Network layer.

• The Network layer adds a header containing source and destination logical addressing,

and then hands the packet to the Data-Link layer.

• The Data-Link layer adds a header containing source and destination physical

addressing and other hardware-specific information.

• The Data-Link frame is then handed off to the Physical layer to be transmitted on the

network medium as bits.

During decapsulation on the receiving host, the reverse occurs:

• The frame is received from the physical medium.

• The Data-Link layer processes its header, strips it off, and then hands it off to the

Network layer.

• The Network layer processes its header, strips it off, and then hands it off to the

Transport layer.

• The Transport layer processes its header, strips it off, and then hands the data to the

user application.

5


2. SYSTEM OVERVIEW

This product is to actually visualize how the network protocols actually work with the

help of a simple GUI .Instead of reading from books about them and understanding

partially. You can use this product. This product is easy to use. This product has

importance in the field of learning, education and etc which help people to have a better

understanding about concepts and make learning about networking interesting.

2.1 Product Perspective:

The product has been developed to provide better understanding to people having

interest in networking. Basically, to study the concepts of GO BACK N and

SELECTIVE REPEAT protocols . To provide the user with an easy to handle graphical

interface for visualizing and understanding the working of mentioned protocols. By

using java concept like applet, awt etc.

2.2 Product Function:

By using java concepts like applet , swing etc, this product will simulate how

encapsulation , decapsulation is done in TCP (Transmission Control Protocol) and how

packets are transmitted . This helps people to have a better understanding about

concepts and make learning about networking interesting.

6


3. SYSTEM ANALYSIS

3.1 Scope:

This application can be used by various educational organisations for interesting learning

and better understanding.

3.2 Need for the proposed product

The Simulation of Network Protocols is an easy to maintain, ready to run, scalable, cost

saving application for educational organisation where better understanding is required.

Features and Benefits:

Low Cost of Maintenance

Basic Computer Knowledge Required

Configurable and Extensible Application UI design

Open source libraries and tools used to reduce cost.

The proposed system can be used even by the naive users and it does not require any

educational level, experience, and technical expertise in computer field but it will be of

good use if the user has the good knowledge of how to operate a computer and access

the internet.

7


4. SYSTEM REQUIREMENTS SPECIFICATIONS

System requirements are expressed in a software requirement document. The Software

requirement specification (SRS) is the official statement of what is required of the

system developers. This requirement document includes the requirements definition and

the requirement specification. The software requirement document is not a design

document. It should set out what the system should do without specifying how it should

be done. The requirement set out in this document is complete and consistent.

The software specification document satisfies the following:-

• It specifies the external system behaviours.

• It specifies constraints on the implementation.

• It is easy to change.

• It serves as learning tool for students .

4.1 Modules and module description:

The modules used in this software are as follows:

4.1.1 Encapsulation

In this module, we graphically visualise what actually encapsulation is .When data

moves from upper layer to lower level of TCP/IP protocol stack (outgoing transmission)

each layer includes a bundle of relevant information called a header along with the

actual data. The data package containing the header and the data from the upper layer

then becomes the data that is repackaged at the next lower level with lower layer's

8


header. Header is the supplemental data placed at the beginning of a block of data when

it is transmitted. This supplemental data is used at the receiving side to extract the data

from the encapsulated data packet. This packing of data at each layer is known as data

encapsulation.

Fig. 2: Encapsulation of data at various layers of the TCP/IP model.

4.1.2 Protocols

Go-Back-N

In a Go-Back-N (GBN) protocol, the sender is allowed to transmit multiple packets

(when available) without waiting for an acknowledgement, but is constrained to have no

more than some maximum allowable number, N, of unacknowledged packets in the

pipeline.

9


Sequence Numbers: Frames from the sender are numbered sequentially.

Sender Sliding Window: At the sender site, to hold the outstanding frames until they

are acknowledged, we use the concept of window. We image that all frames are stored in

a buffer. The outstanding frames are enclosed in a window. The frames to the left of the

window are those that have already been acknowledged; those to the right of the window

cannot be sent until the window slides over them. The size of the window in this

protocol is fixed. The window slides to include unsent frames when the correct

acknowledgments are received.

Receiver Sliding Window: The size of the window at the receiver site in this protocol is

always 1. The receiver is always looking for a specific frame to arrive in a specific order.

Any frame arriving out of order is discarded and needs to be resent.

Figure 1 shows the operation of the GBN protocol for the case of a window size of four

packets. Because of this window size limitation, the sender sends packets 0 through 3

but then must wait for one or more of these packets to be acknowledges before

proceeding. As each successive ACK (for example, ACK0 and ACK1) is received, the

window slides forward and the sender can transmit one new packet (pkt4 and pkt5,

respectively). On the receiver site, packet 2 is lost and thus packets 3, 4 and 5 are found

to be out of order and discarded.

10


Fig. 3: Go-Back-N in operation

Go-Back-N protocol includes the use of sequence numbers, cumulative

acknowledgements, checksums and a timeout/retransmit operation.

11


4.1.2.2 Selective Repeat

Go-Back-N ARQ simplifies the process at the receiver site. The receiver keeps track of

only one variable, and there is no need to buffer out-of-order frames; they are simply

discarded. However, this protocol is very inefficient for a noisy link. In a noisy link a

frame has a higher probability of damage, which means the resending of multiple

frames. This resending uses up the bandwidth and slows down the transmission. For

noisy links, there is another protocol that does not resend N frames when just one frame

is damaged; only the damaged frame is resent. This protocol is called Selective Repeat.

Sender and Receiver Windows: In Go-Back-N, the receiver is looking for one

specific sequence number; in Selective Repeat, the receiver is looking for a range of

sequence numbers. Selective Repeat also defines a negative acknowledgement (NAK)

that reports the sequence number of a damaged frame before the timer expires.

12


Fig. 4: Selective Repeat in operation

Advantage over Go-Back-N:

Go-Back-N ARQ is a specific instance of the automatic repeat request (ARQ)

protocol, in which the sending process continues to send a number of frames

specified by a window size even without receiving an acknowledgement (ACK)

packet from the receiver. It is a special case of the general sliding window protocol

with the transmit window size of N and receive window size of 1.

Selective Repeat ARQ / Selective Reject ARQ is a specific instance of the Automatic

Repeat-Request (ARQ) protocol used for communications. It may be used as a

13


protocol for the delivery and acknowledgement of message units, or it may be used

as a protocol for the delivery of subdivided message sub-units.

Comparison of Go-Back-N and Selective Repeat

Go-Back-N

Retransmission begins with the last unacknowledged frame even if subsequent

frames have arrived correctly. Duplicate frames are discarded.

Go-back-n : Receiver must get Frames in correct order.

Selective Repeat

Only the unacknowledged frame is retransmitted.

It may be (slightly) more efficient than Go-back-n ARQ, but also much more

complicated.

Selective repeat ARQ : correctly-received out-of-order Frames are stored at

Receiver until they can be re-assembled into correct order

4.1.3 Decapsulation

The reverse process of encapsulation (or decapsulation) occurs when data is received on

the destination computer. As the data moves up from the lower layer to the upper layer

of TCP/IP protocol stack (incoming transmission), each layer unpacks the corresponding

header and uses the information contained in the header to deliver the packet to the exact

network application waiting for the data.

14


Fig. 5: Depicts decapsulation at various layers of the TCP/IP model.

4.2 Functional Requirements

The product must provide following functionalities:

Graphically show encapsulation and decapsulation .

Visualize the data sending in both protocols.

Visualize all cases in both protocols.

4.3 Performance Requirements

A web browser to integrate applets with it.

Server should be available 24x7.

15


4.4 Non-Functional Requirements

Following Non-functional requirements will be there in the insurance of internet:

• 24x7 availability.

• Better component design to get better performance .

• Flexible service based architecture will be highly desirable for future extension.

Non-functional requirements define system properties and constraints. It arises through

user needs, because of budget constraints or organizational policies, or due to the

external factors.

Various other Non-functional requirements are:

• Reliability

• Maintainability

• Portability

• Extensibility

• Reusability

• Application Affinity/Compatibility

• Resource Utilization

4.5 External Interface Requirements

4.5.1 User Interface

16


User of the system will be provided with the GUI. In order to learn one should have a

little idea about networking and both protocols. The GUI will get reset after clicking on

the reset button.

4.5.2 Hardware Interface

The project does not deal with any specific requirement about the h/w interfaces. It

mainly deals with providing an interface to user for providing inputs and displays the

output in an animated form.The hardware requirements are basic fundamentals which

are required to run a program. Minimum hardware requirements for the product are :

Processor : Intel P4 or above.

RAM : 256 MB or above.

Hard Disk : 4 GB or above.

4.5.3 Software Interface

Minimum Software requirement to make product work are as follows:

• Operating System - Windows XP

• Java Development Kit

• IDE- Eclipse/ NetBeans

• Web Browser – IE / Google Chrome / Mozilla Firefox

4.6 General Constraints, Assumptions, Dependencies, Guidelines

4.6.1 General Constraints

17


• The interface will be in English only.

• The system is working for a single server.

• There is maintainability or backup so that availability is there.

• The system is a single user system.

4.6.2 Assumptions and Dependencies

Assumptions:

• User must be trained for basic computer functionalities.

• User must have the basic knowledge of English

• The system must be able to respond within reasonable time.

Front-end (User Interaction):

• The application will require a computer with a compatible web browser and a

communication channel.

18


5. TECHNOLOGY DESCRIPTION

5.1 Java

Java is an object-oriented multi-threaded programming language developed by Sun

Microsystems in 1991. It is designed to be small, simple and portable across different

platforms as well as operating systems. The language derives much of its syntax from C

and C++ but has a simpler object model and fewer low-level facilities.

The original and reference implementation Java compilers, virtual machines, and class

libraries were developed by Sun from 1995. As of May 2007, in compliance with the

specifications of the Java Community Process, Sun made available most of their Java

technologies as free software under the GNU General Public License. Others have also

developed alternative implementations of these Sun technologies, such as the GNU

Compiler for Java and GNU class path.

The popularity of Java is due to its unique technology that is designed on the basis of

three key elements. They are usage of applets, powerful programming language

constructs and a rich set of significant object classes.

When a program is compiled, it is translated into machine code or processor instructions

that are specific to the processor. In the Java development environment there are two

parts: a Java compiler and a Java interpreter. The compiler generates byte code (a set of

instructions that resemble machine code but are not specific to any processor) instead of

machine code and the interpreter executes the Java program.

19


Java is also unusual in that each Java program is both compiled and interpreted. With a

compiler, you translate a Java program into an intermediate language called Java byte

codes--the platform-independent codes interpreted by the Java interpreter. With an

interpreter, each Java byte code instruction is parsed and run on the computer.

Compilation happens just once; interpretation occurs each time the program is executed.

This figure illustrates how this works.

Fig. 6: Program Execution

We can think of Java byte codes as the machine code instructions for the Java Virtual

Machine (Java VM). Every Java interpreter, whether it's a Java development tool or a

Web browser that can run Java applets, is an implementation of the Java VM. The Java

VM can also be implemented in hardware.

Java byte codes help make "write once, run anywhere" possible. You can compile your

Java program into byte codes on any platform that has a Java compiler. The byte codes

can then be run on any implementation of the Java VM. For example, the same Java

program can run on Windows NT, Solaris, and Macintosh.

20


Fig. 7: Platform Independent

A platform is the hardware or software environment in which a program runs. The Java

platform differs from most other platforms in that it's a software-only platform that runs

on top of other, hardware-based platforms. Most other platforms are described as a

combination of hardware and operating system.

The Java platform has two components:

The Java Virtual Machine (Java VM)

The Java Application Programming Interface (Java API)

We've already been introduced to the Java VM. It's the base for the Java platform and is

ported onto various hardware-based platforms.

The Java API is a large collection of ready-made software components that provide

many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is

grouped into libraries (packages) of related components.

21


Java Buzzwords

No discussion of the genesis of Java is complete without a look at the Java

buzzwords.Although the fundamental forces that necessitated the invention of Java are

portability and security, other factors also played an important role in molding the final

form of the language. The key considerations were summed up by the Java team in the

following list of buzzwords:

Simple

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

effectively. If you already understand the basic concepts of object-oriented

programming, learning Java will be even easier. Java inherits the C/C++ syntax and

many of the object-oriented features of C++, most programmers have little trouble

learning Java. Also, some of the more confusing concepts from C++ are either left out of

Java or implemented in a cleaner, more approachable manner.

Security

As you are likely aware, every time that you download a “normal” program, you are at

risk of virus. Prior to Java, most users did not download executable programs frequently,

and those who did scan them for viruses prior to execution.

Even so, most users still worried about the possibility of infecting their systems with a

virus. In addition to viruses, another type of malicious 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, by searching the contents of your

22


computer’s local file system. 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 viral

infection or malicious intent.

Java achieves this protection by confining a Java program to the Java execution

environment and not allowing it access to other parts of the computer.

Portability

As discussed earlier, many types of computers and operating systems are in use

throughout the world—and many are connected to the Internet.

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

Object-Oriented

Although influenced by its predecessors, 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.

Borrowing liberally from many seminal object-software environments of the last few

decades, Java manages to strike a balance between the purists’s “everything is an object”

paradigm and the pragmatist’s “stay out of my way” model.

23


Robust

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

program, because the program must execute reliably in a variety of systems. Thus, the

ability to create robust programs was given a high priority in the design of Java.

To gain reliability, Java restricts you in a few key areas, to force you to find your

mistakes early in program development. At the same time, Java frees you from having to

worry about many of the most common causes of programming errors.

Because Java is a strictly typed language, it checks your code at compile time. However,

it also checks your code at run time. In fact, many hard-to-track-down bugs that often

turn up in hard-to-reproduce run-time situations are simply impossible to create in Java.

Knowing that what you have written will behave in a predictable way under diverse

conditions is a key feature of Java.

To better understand how Java is robust, consider two of the main reasons for program

failure: memory management mistakes and mishandled exceptional conditions (that is,

run-time errors).

Memory management can be a difficult, tedious task in traditional programming

environments. For example, in C/C++, the programmer must manually allocate and free

all dynamic memory. This sometimes leads to problems, because programmers will

either forget to free memory that has been previously allocated or, worse, try to free

some memory that another part of their code is still using. Java virtually eliminates these

problems by managing memory allocation and DE allocation for you.

24


Multithreaded

Java was designed to meet the real-world requirement of creating interactive, networked

programs. To accomplish this, Java supports multithreaded programming, which allows

you to write programs that do many things simultaneously.

The Java run-time system comes with an elegant yet sophisticated solution for

multiprocessing synchronization that enables you to construct smoothly running

interactive systems.Java’s easy-to-use approach to multithreading allows you to think

about the specific behavior of your program, not the multitasking subsystem.

Architecture-Neutral

A central issue for the Java designers was that of code longevity and portability. One of

the main problems facing programmers is that no guarantee exists that if you write a

program today, it will run tomorrow—even on the same machine.

Operating system upgrades, processor upgrades, and changes in core system resources

can all combine to make a program malfunction. The Java designers made several hard

decisions in the Java language and the Java Virtual Machine in an attempt to alter this

situation.

Their goal was “write once; run anywhere, anytime, forever.” To a great extent, this goal

was accomplished. You can compile your Java program into byte codes on any platform

that has a Java compiler. The byte codes can then be run on any implementation of the

Java VM. For example, the same Java program can run on Windows NT, Solaris, and

Macintosh.

25


Fig. 8: Program Execution on Different Platforms

Interpreted and High Performance

As described earlier, Java enables the creation of cross-platform programs by compiling

into an intermediate representation called Java byte code. This code can be interpreted

on any system that provides a Java Virtual Machine. Most previous attempts at cross

platform solutions have done so at the expense of performance. Other interpreted

systems, such as BASIC, Tcl, and PERL, suffer from almost insurmountable

performance deficits. Java, however, was designed to perform well on very low-power

CPUs.

As explained earlier, while it is true that Java was engineered for interpretation, the Java

byte code was carefully designed so that it would be easy to translate directly into native

machine code for very high performance by using a just-in-time compiler. Java run-time

systems that provide this feature lose none of the benefits of the platform-independent

code.

26


6. SYSTEM DESIGN SPECIFICATIONS

6.1 Flow Chart

Fig. 9: Flowchart for whole application

27

START

ENCAPSULATION

PROTOCOLS

DECAPSULATION

STOP


6.2 Sequence Diagram

Fig. 10: Sequence diagram for ideal case

28


6.2.1 For Go Back N

Fig. 11: Sequence diagram for lost frame and time out in Go-Back-N

29


Fig. 12: Sequence diagram for lost acknowledgement in Go-Back-N

30


6.2.2 For Selective Repeat

Fig. 13: Sequence diagram for lost frame in Selective Repeat

31


Fig. 14: Sequence diagram for lost acknowledgement in Selective Repeat

32


6.3 Collaboration Diagram

Fig. 15: Collaboration diagram for ideal case

6.3.1 For Go Back N

Fig. 16: Collaboration diagram for lost frame and time out in Go-Back-N

33


Fig. 17: Collaboration diagram for lost acknowledgement in Go-Back-N

34



Fig. 18: Collaboration diagram for lost acknowledgement in Selective Repeat

Fig. 19: Collaboration diagram for lost frame in Selective Repeat

35


7. PROJECT FEASIBILITY STUDY

It can be defined as an investigation into a project or proposed plan in order to determine

whether and how the proposed project can successfully and profitably. It is performed in

order to measure whether the project is feasible. Developer of the proposed system

carefully conducted feasibility by keeping in mind with considerations of two important

factors time and resource. Developer of the proposed system has to go through several

stages for the successful accomplishment of the project and here feasibility study

becomes important, in order to make sure that the software is built according to its

specification. Conducting feasibility study is considered as a good business practice.

There are different types of feasibility study but the developer divided the feasibility

study in four major types. They are as follows:-

1. Technical Feasibility

2. Schedule Feasibility

3. Operational Feasibility

4. Economic Feasibility

Developer of the proposed system carefully carried out research and study on all these

types in order to determine whether it is feasible to carry out the development of the

proposed system.

36


7.1 Technical Feasibility

Developer of the proposed system carried out technical feasibility in order to determine

the requirements of technologies for the current system. It is very much essential and

necessary for the developer to determine that the current technological resources are

sufficient to develop the proposed system or there is need to upgrade the technological

resource. There is a need carefully conduct this study because it is considered as one of

the most important study in all aspects. Developer needs to answer few things in order to

conduct technical feasibility study. These are:-

1. Is proposed technology or solution practical?

2. What kind of technology will developer need?

3. Is the required technology available “in house”?

After answering all of the above questions developer conducted and concluded

feasibility study. To Develop “LAN RADIO” developer carefully examined the

technical resource available and concluded that it is possible to get started with

developing the proposed system.

7.2 Schedule Feasibility

This feasibility is related is used to determine the time factor related to current system. It

is very much necessary for the developer to define deadlines for the project. Only

defining is not important but also there is a need to accomplish the work on due time.

There is a need to build a System/ Solution in time which is useful. Also there is need to

37


answer few questions during and after the development in order to acquire accuracy and

usefulness.

1. What are the consequences of delay?

2. Any Constraints on schedule?

3. Can these constraints be met?

As developer knows the fact that most of the project fails due to delay in project

deadline. Answering above mentioned questions will help the developer to eradicate

problems in schedule feasibility. Developer has maintained a Gantt chart for defining

task with deadline dates. This will help developer to evaluate project development

process.

7.3 Operational Feasibility

Developer of the proposed system carried out operational feasibility study to make sure

that if the proposed system is developed, will it be used. It is very much necessary to

conduct because there is a need to determine that the proposed system which is going to

be developed can satisfy and meet user requirements and expectations. It is very much

necessary to analyze user requirement and to what level the proposed will meet the

expectations. Developer will perform a competitive analysis of the available systems in

the market. This will help in getting a closer view to the features of similar systems

available in market and to focus on features which are going to be supplied with the

proposed system. After conducting competitive and comparative analysis developer

concluded that it is feasible to build the proposed system. Several testing will be

performed for ensuring quality of the proposed system.

38


7.4 Economic Feasibility

It is the most important feasibility study used to evaluate the effectiveness of the

candidate system i.e. proposed system. The effectiveness should be in term of Cost

effectiveness and Benefits (Tangible/ Intangible). It is very important to determine

tangible and intangible benefits associated with the proposed system, since the degree of

success of proposed system depends a lot upon this factor. Identifying benefits

associated with the proposed system has a greater impact on the development and

usefulness of the desired output. So, developer identified tangible and intangible benefits

of the proposed system which will be discussed in next chapter.

39


8. LITERATURE REVIEW

A literature review is an objective, through summary and critical analysis of the relevant

available research and non-research literature on the topic being studied (Hart, 1998). It

is the summary of resources but it has an organized manner and combines summary and

synthesis Its goal is to bring the reader up-to –date with current literature on a topic and

form the basis for another goal, such as justification for future research in the area. It

gives a new birth to the old material and help to be converted into a new material or

combine with old material to form new material.

It is important and necessary to do a literature review because if we have limited time to

conduct research, literature reviews can give us an overview or act as a stepping stone.

Research has been always playing a vital role in the development and success of all

projects. During this conscientious period of study of Word Online the main source of

references includes journals, web sites, newsgroup and guideline from the supervisor.

In order to design or develop any system developer needs to consult spectrum of

magazine or journals or whitepapers or newsgroup or websites so as to meet end user

requirement and move on to detailed research phase. This process of getting technology

and meeting end user requirement is called as literature review.

40


9. METHODOLOGY USED

9.1 Selection of Methodology

Software engineering is the practice of using selected process techniques to improve the

quality of a software development effort. This is based on the assumption, subject to

endless debate and supported by patient experience, that a methodical approach to

software development results in fewer defects and, therefore, ultimately provides shorter

delivery times and better value. The documented collection of policies, processes and

procedures used by a development team or organization to practice software engineering

is called its software development methodology (SDM).

The “Online College Portal” is the system which is going to be developed as a web

application. The requirements of the system are the combination of some existing

systems. So the requirements of the system are well defined and are fixed. The user’s

requirements will not be changing at any time. The problem domain that is the software

distribution is a quite familiar domain for any developer or anyone concern with the IT.

9.2 Software Development Methodology

After making lot of research in this area, I would probably use spiral model. The spiral

model by Barry Boehm and presented by him at the Spiral Development Workshop,

February 2000.Spiral development is a family of software development processes

characterized by repeatedly iterating a set of elemental development processes and

managing risk so it is actively being reduced.

41


Fig. 20: Spiral Model

The spiral development model is a risk-driven process model generator. It is used to

guide multi-stakeholder concurrent engineering of software-intensive systems. It has two

main distinguishing features. One is a cyclic approach for incrementally growing a

system's degree of definition and implementation while decreasing its degree of risk. The

other is a set of anchor point milestones for ensuring stakeholder commitment to feasible

and mutually satisfactory system solutions.

42


The major features of the spiral model have been identified as:

1. Cyclic concurrent engineering.

2. Risk driven.

3. Determination of process and product.

4. Growing a system via risk-driven experimentation and elaboration.

9.3 Why using this methodology?

As the proposed system is a research based one, so the suitable methodology for this

proposed system is spiral method. There are often occasions where the requirements are

not well formed or understood by the users, where it is difficult to specify the

requirements. So in such situation this it is necessary that developer knows what actually

the customer wants and try to fulfill the requirements of the customer. By using this

methodology mistakes in the requirements can be corrected and user gets feedback. It

allows customer and developer to determine and to react to risks at each evolutionary

level. It is a lifecycle where the design, develop, test phases are repeated several times

before the end product is complete. It uses prototyping as a risk reduction mechanism.

The spiral model demands a direct consideration of technical risks at all stages of the

project, and should reduce risk before become problematic. It has the advance approach

on setting project objectives, project risk management and project planning into the

overall development cycle.

The Spiral model of software development has been followed for the development of

this system. The reasons for choosing spiral model are:

43


• The size of the system is considerable and it would have been difficult to identify

complete set of requirements at the beginning of the project.

• It would be possible to swiftly identify and accommodate new requirements,

specifications, risks and real world problems if spiral model is used.

• The use of spiral model would lead to avoidance of the identified risks.

• It would enable incorporating software quality objectives into product development as

all the objectives and constraints would be identified for each spiral.

• The use of spiral model would lead to greater and optimum user involvement in the

development of the project as it enabled to use the prototyping approach at any stage in

the evolution of the product.

• Since the software evolved as the process progressed, it would be possible to

understand and react to risks at each evolutionary level.

• It provides the potential for rapid development of incremental versions of the software

• Using the spiral model, software is developed in a series of incremental releases

• There are often occasions where the requirements are not well formed or understood by

the users, where it is difficult to specify the requirements. So in such situation it is

necessary that developer knows what actually the customer wants and try to fulfill the

requirements of the customer

• By using this methodology mistakes in the requirements can be corrected and user get

feedback

44


• It allows customer and developer to determine and to react to risks at each evolutionary

level

• It uses prototyping as a risk reduction Mechanism

• The spiral model demands a direct consideration of technical risks at all stages of the

project, and should reduce risk before become problematic.

• It has the advance approach on setting project objectives, project risk management and

project planning into the overall development cycle.

9.4 Project Stages

This will have five stages and these are: -

1. Research and Planning

2. Analysis.

3. Design.

4. Development.

5. Implementation.

6. Support

9.5 Research and Planning

During this phase the research of the whole project have to be done which will include

different technology, language, platform, requirement etc. which is required during the

development of the process. And in the planning phase developer have to plan by which

45


the developer have to go through the different method to accomplish that project in the

given time period.

9.6 Analysis

In this phase the problem by the existing system will be identified and information will

be gathered from books and internet resources for developing the proposed system. In

this phase the prototype of the system will be developed.

9.7 Design

In this phase the interface screen design, use case, class and sequence diagram will be

done. In other words system designing part of the system will be done during this phase.

9.8 Development

In this phase the coding will be done. It will be divided into different parts like firstly the

coding of one module will be done and then it is tested and then moves to another

module. Each module will be tested and then proceed to the next module. Spiral

methodology will be followed during the design and development phase. Each module

of the system will be tested after designing and development. If it needs any changes

then the developer change it according to the user’s requirement. After testing and doing

changes then proceed to the next module till the end of the product.

9.9 Implementation

In this phase the systems get tested and identify the necessary changes to be made.

46


I will configure the hardware required running both database and developed tool. After

wards database and software installation will be carrying out for the final presentation

and finally report.

9.10 Support

This phase is basically used after the implementation of the project providing the back

support to the user. Which being basically used to give the maintenance and training to

the user and help them time to time regarding software error.

47


10. TESTING

It should be clear in mind that the philosophy behind testing is to find errors. Test cases

are devised with this purpose in mind. A test case is a set of data that the system will

process as normal input. However, the data are created with the express intent of

determining whether the system will process them correctly. For example, test cases for

inventory handling should include situations in which the quantifies to be withdrawn

from inventory exceed, equal and are less than the actual quantities on hand. Each test

case is designed with the intent of finding errors in the way the system will process it.

There are two general strategies for testing software: Code testing and Specification

testing. In code testing, the analyst develops that cases to execute every instructions and

path in a program. Under specification testing, the analyst examines the program

specifications and then writes test data to determine how the program operates under

specific conditions. Regardless of which strategy the analyst follows, there are preferred

practices to ensure that the testing is useful. The levels of tests and types of test data,

combined with testing libraries, are important aspects of the actual test process.

10.1 Levels of Testing

Systems are not designed as entire systems nor are they tested as single systems. The

analyst must perform both unit and system testing.

10.2 Unit Testing

In unit testing the analyst tests the programs making up a system. For this reason, unit

testing is sometimes called program testing. Unit testing gives stress on the modules

independently of one another, to find errors. This helps the tester in detecting errors in

48


coding and logic that are contained within that module alone. The errors resulting from

the interaction between modules are initially avoided. For example, a hotel information

system consists of modules to handle reservations; guest checking and checkout;

restaurant, room service and miscellaneous charges; convention activities; and accounts

receivable billing. For each, it provides the ability to enter, modify or retrieve data and

respond to different types of inquiries or print reports. The test cases needed for unit

testing should exercise each condition and option.

Unit testing can be performed from the bottom up, starting with smallest and lowest-

level modules and proceeding one at a time. For each module in bottom-up testing a

short program is used to execute the module and provides the needed data, so that the

module is asked to perform the way it will when embedded within the larger system.

10.3 System Testing

The important and essential part of the system development phase, after designing and

developing the software is system testing. We cannot say that every program or system

design is perfect and because of lack of communication between the user and the

designer, some error is there in the software development. The number and nature of

errors in a newly designed system depend on some usual factors like communication

between the user and the designer; the programmer's ability to generate a code that

reflects exactly the systems specifications and the time frame for the design.

Project testing is an important phase without which the system can’t be released to the

end users. It is aimed at ensuring that all the processes are according to the specification

49


accurately. Here entire ‘system’ has been tested against requirements of project and it is

checked whether all requirements of project have been satisfied or not.

10.4 Integration Testing

After the unit testing we have to perform integration testing. The goal here is to see if

modules can be integrated properly or not. This testing activity can be considered as

testing the design and hence the emphasis on testing module interactions. It also helps to

uncover a set of errors associated with interfacing. Here the input to these modules will

be the unit tested modules. Integration testing is classifies in two types…

1. Top-Down Integration Testing.

2. Bottom-Up Integration Testing.

In Top-Down Integration Testing modules are integrated by moving downward through

the control hierarchy, beginning with the main control module.

In Bottom-Up Integration Testing each sub module is tested separately and then the full

system is tested. Integration testing in this project: In this project integrating all the

modules forms the main system. Means I used Bottom-Up Integration Testing for this

project. When integrating all the modules I have checked whether the integration effects

working of any of the services by giving different combinations of inputs with which the

two services run perfectly before Integration.

10.5 Test Cases

10.5.1 For Go Back N

50


Fig. 21: Test case 1 frame sent by sender

Fig. 22: Test case 1 frame received by reciever

51


Fig. 23: Test case 2 acknowledgement sent

Fig. 24: Test case 2 acknowledgement received

52


Fig. 25: Test case 3 resend frame after time out

Fig. 26: Test case 3 acknowledgement for resent frames

53



Fig. 28: Test case 4 packet killed

54


Fig. 29: Test case 4 acknowledgement for received frames

Fig. 30: Test case 4 killed packet resend after time out

55




Fig. 32: Test case 1 frame sent by sender

56


Fig. 33: Test case 1 frame received by reciever

Fig. 34: Test case 2 acknowledgement sent

57



Fig. 36: Test case 3 resend frame after time out

58


Fig. 37: Test case 3 acknowledgement for resent frames


59


Fig. 39: Test case 4 packet killed

Fig. 40: Test case 4 acknowledgement for received frames and frame buffered out of order

60


Fig. 41: Test case 4 killed packet resend after time out


61


11. Maintenance

Once the software is delivered and developed, it enters the maintenance phase. After

implementation systems need maintenance. Beyond monkey testing during Software

development some errors may not appear. During its usage by the end-user with actual

data certain errors may disclose. Therefore some residual errors or bugs remain in the

system that must be removed as they are discovered. Many of these surfaces only after

the system have been in operation sometimes for a long time. These errors once

discovered need to be removed on an urgent basis for the smooth running of the system,

leading to the software getting changed. Though Maintenance is not a part of software

development, it is an extremely important activity in the life of a software product.

Maintenance involves understanding the existing software (code and related documents),

understanding the effects of change, making the changes-to both the code and

documents-testing the new parts and retesting the old part.

For successful and smooth running of the system, maintenance is the prominent part of

the project. Any error, which hinders the functioning of any part of the project, may lead

to bad impression of the developer. There are majorly two types of errors: Compilation

error and Runtime errors. Compilation errors are errors during coding and are to be take

care by the developer during development process.

Runtime errors are those which occur during running of the program. Whenever there is

an occurrence of error an ‘Error Window’ opens in the middle of the screen displaying

the type of error, Error Number and the Nearest Possible reason as to why the error has

occurred. With the occurrence of this Error Window the operator (End-user) should note

62


the type of error, the error number and the description of the error and should

immediately report to the concerned Developer or Administrator.

Now comes the role of the Maintenance Personals. After knowing the entire details from

the end-user like where or at which screen does this error occurred or what type of data

was fed by the user or the point of malfunctioning. Considering this error as the main

reason for the malfunctioning the programmer now re-examines all the possible factors,

which act behind the particular screen where error has occurred. After debugging the

required error the programmer itself tests the same screen or process with dummy data.

Only after getting completely satisfied with problem rectification the programmer

compiles and runs the program.

63


12. CONCLUSION AND FUTURE EXTENSION

Conclusion

• The system has been developed for the given condition and is found working

effectively. The developed system is flexible and changes can be made easily

whenever required. Using the facilities and functionalities of java, the software

has been developed in a neat and simple manner, thereby reducing the operator’s

work.

• The speed and accuracy are maintained in proper way. The user-friendly nature

of this software developed in java is very easy to work with both the higher

management as well as other users with little knowledge of computer. The results

obtained were fully satisfactory from the user point of view.

• The system is run with an insight into the necessary modifications that may be

required in the future. Hence the system can be maintained successfully.

Future Extension

• It is possible to use it as study material for institutions ,colleges and etc.

• It is possible to implement the project for different scenarios.

• It is possible to use it as a foundation for research work

64


Advantages

• It is very interactive & easy to use.

• It is adaptable.

• Low running cost and can be applied on various fields like research work, as

study material etc.

65


13. REFERENCES

Books:

KUROSE.ROSS “Computer Networking: A Top-Down Approach”, Dorling

Kindersley , Third Edition

Behrouz A. Forouzan “Data Communications and Networking”, MCGRAW-HILL

Higher Education, Fifth Edition

Herbert Schildt “Java: The Complete Reference” ,Tata Mc Graw –Hill ,Fifth

Edition

Web Resources:

[1] http://en.wikipedia.org/wiki

[2] http://www.ist.ucf.edu/background.htm

[3] http://www.goldsim.com/Web/Introduction/Simulation/

[4] http://stackoverflow.com/

66

http://stackoverflow.com/

http://www.goldsim.com/Web/Introduction/Simulation/

http://www.ist.ucf.edu/background.htm

http://en.wikipedia.org/wiki


APPENDIX- A

REQURIEMENTS ANALYSIS

The requirement phase basically consists of three activities:

Requirement Analysis

Requirement Specification

Requirement Validation

Requirement Analysis:

Requirement Analysis is a software engineering task that bridges the gap between

system level software allocation and software design. It provides the system engineer to

specify software function and performance, indicate software’s interface with the other

system elements and establish constraints that software must meet.

The basic aim of this stage is to obtain a clear picture of the needs and requirements of

the end-user and also the organization. Analysis involves interaction between the clients

and the analysis. Usually analysts research a problem by asking questions and reading

existing documents. The analysts have to uncover the real needs of the user even if they

don’t know them clearly. During analysis it is essential that a complete and consistent set

of specifications emerge for the system. Here it is essential to resolve the contradictions

that could emerge from information got from various parties. This is essential to ensure

that the final specifications are consistent.

It may be divided into 5 areas of effort.

67


Problem recognition

Evaluation and synthesis

Modeling

Specification

Review

Each Requirement analysis method has a unique point of view. However all analysis

methods are related by a set of operational principles.They are

The information domain of the problem must be represented and

understood.

The functions that the software is to perform must be defined.

The behavior of the software as a consequence of external events must be

defined.

The models that depict information, function and behavior must be

partitioned in a hierarchical or layered fashion.

The analysis process must move from essential information to

Implementation detail

Requirement Analysis in this Project

The main aim in this stage is to assess what kind of a system would be suitable for a

problem and how to build it. The requirements of this system can be defined by going

through the existing system and its problems. They discussing (speak) about the new

system to be built and their expectations from it. The steps involved would be

Problem Recognition:

68


The main problem is here while taking the appointments for the Doctors. If we want to

verify the old data or historical data it is very difficult to findout. Maintain the data

related to all departments is very difficult.

Evaluation and Synthesis:

In the proposed system this application saves the lot of time, and it is time saving

process when we use this application. Using this application we can easy to manage

daily treatments and easy to maintain the historical data. No specific training is required

for the employees to use this application. They can easily use the tool that decreases

manual hours spending for normal things and hence increases the performance.

Requirement Specification

Principles:

Software Requirements Specification plays an important role in creating quality software

solutions. Specification is basically a representation process. Requirements are

represented in a manner that ultimately leads to successful software implementation.

Requirements may be specified in a variety of ways. However there are some guidelines

worth following: -

Representation format and content should be relevant to the problem

Information contained within the specification should be nested

Diagrams and other notational forms should be restricted in number and

consistent in use.

Representations should be revisable.

69


Software Requirements Specifications:

The software requirements specification is produced at the culmination of the analysis

task. The function and performance allocated to the software as a part of system

engineering are refined by establishing a complete information description, a detailed

functional and behavioral description, and indication of performance requirements and

design constraints, appropriate validation criteria and other data pertinent to

requirements.

APPENDIX- B

70


UML DIAGRAMS

UML is a notation that resulted from the unification of Object Modeling Technique and

Object Oriented Software Technology .UML has been designed for broad range of

application. Hence, it provides constructs for a broad range of systems and activities.

An Overview of UML in five notations

1. Use Case diagram

Use cases are used during requirements elicitation and analysis To represent the

functionality of the system.Use cases focus on the behaviour of the system from the

external point of view.The actor are Outside the boundary of the system,whereas the use

cases are inside the boundary of the system.

2. Class diagram

Class diagrams to describe the structure of the system. Classes Are abstraction that

specify the common structure and behaviour of a set Class diagrams describe the

system in terms of objects, classes, attributes, operations and their associations.

3. Sequence diagram

Sequence diagrams are used to formalize the behaviour of the system and to visualize

the communication among objects. They are useful for identifying additional objects that

participate in the use cases. A Sequence diagram represents the interaction that take

place among these objects.

4. State chart diagram

State chart diagrams describe the behaviour of an individual object as a number of states

and transitions between these states. A state represents a particular set of values for an

71


object. The sequence diagram focuses on the messages exchanged between objects, the

state chart diagrams focuses on the transition between states.

5. Activity diagram

An activity diagram describes a system in terms of activities. Activities are states that

represents the execution of a set of operations. Activity diagrams are similar to flowchart

diagram and data flow.

APPENDIX – C

72


SCREENSHOTS

DESKTOP APPLICATION INTERFACE

Fig. 43 : Application interface

After clicking on encapsulation this appears

Fig. 44 : Depicts encapsulation

Click on protocol, from this window, select the required protocol

73


Fig. 45 : For selecting the protocol

After clicking on Go Back N protocol, this window will appear

Fig. 46 : Go Back N interface

frame sent

74


Fig. 47 : Sending frame

Acknowledgement recieved

Fig. 48 : Receiving acknowledgement

Packet kill

75


Fig. 49 : kill packet

Fig. 50 : Acknowledgement of left frames being sent

When time out occurs

76


Fig. 51 : when time out occur

After clicking on selective repeat, this window will appear

Fig. 52 : Selective Repeat interface

frame sent

77


Fig. 53 : Sending frame

Acknowledgement recieved

Fig. 54 : Receiving acknowledgement

78


Packet kill

Fig. 55 : kill packet

Acknowledgement killed

Fig. 56 : Acknowledgement of left frames being sent and frame is buffered out of order

79


When time out occurs

Fig. 57 : when time out occur

When Decapsulation is clicked ,window will appear illustrating Decapsulation

Fig. 58 : Depicts decapsulation

80


WEB INTEGRATED VERSION

Fig. 59: Application interface

After clicking on encapsulation, this window will appear illustrating encapsulation

Fig. 60: Depicts encapsulation

81


After clicking on protocol this will appear ,select the required protocol

Fig. 61: For selecting the protocol

Interface for GBN

Fig. 62 : Go Back N interface

82


Interface for Selective Repeat

Fig. 63: Selective Repeat interface

And if one clicks on decapsulation , this window will appear

Fig. 64: Depicts decapsulation

83


APPENDIX- D

DESCRIPTION OF TEST CASES

GO BACK N PROTOCOL

Figure no. Test case Test case description Page no.

Fig 21 Test case 1 Sender sends the first frame(yellow) by pressing send new button

51

Fig 22 Test case 1 The frame sent by the sender(yellow) is received(blue) by the receiver

51

Fig 23 Test case 2 The receiver sends corresponding acknowledgement(green) for the frame

received

52

Fig 24 Test case 2 The acknowledgement sent by receiver is received by sender (pink)

52

Fig 25 Test case 3 Frame 0 and 1(yellow) are resent after a time-out of 25 sec

53

Fig 26 Test case 3 The receiver sends corresponding acknowledgement(green) for the frames 0

and 1 resent

53

Fig 27 Test case 4 The acknowledgement sent by receiver for frames 0 and 1 is received by sender (pink)

54

Fig 28 Test case 4 The frames 0,1,2,3,4 (yellow) are sent ,out of which frames 2 and 3 are killed

54

Fig 29 Test case 4 The receiver sends corresponding acknowledgement(green) for the frames 0,1

and 4

55

Fig 30 Test case 4 After a time out of 25 sec the killed Frames i.e. 2, 3 and 4 (out of order) are sent again

55

Fig 31 Test case 4 The sender receives the acknowledgement of frames 2,3 and 4(pink)

56

Table 2: Test cases for Go back N protocol

84


SELECTIVE REPEAT PROTOCOL

Figure no. Test case Test case description Page no.

Fig 32 Test case 1 Sender sends the first frame(yellow) by pressing send new button

56

Fig 33 Test case 1 The frame sent by the sender(yellow) is received(blue) by the receiver

57

Fig 34 Test case 2 The receiver sends corresponding acknowledgement(green) for the

frame received

57

Fig 35 Test case 2 The acknowledgement sent by receiver is received by sender (pink)

58

Fig 36 Test case 3 Frame 0 and 1(yellow) are resent after a time-out of 25 sec since frame

0 was killed

58


frames 0 and 1 resent

59

Fig 38 Test case 3 The acknowledgement sent by receiver for frames 0 and 1 is

received by sender (pink)

59

Fig 39 Test case 4 The frames 0,1,2,3,4 (yellow) are sent ,out of which frames 2 and 3 are

killed

60


frames 0,1 and 4

60

Fig 41 Test case 4 After a time out of 25 sec the killed Frames i.e. 2, 3 and 4 (out of order)

are sent again

61

Fig 42 Test case 4 The sender receives the acknowledgement of frames 2,3 and

4(pink)

61

Table 3: Test cases description for Selective Repeat Protocol

85


1. Is the report properly hard bound? Yes/No

2. Is the Cover page(on hard bound cover) in proper format? Yes/No

3. Is the Title Page (Inner Cover Page) in proper format? Yes/No

4. (a) Is the Certificate from the Supervisor in proper format?

(b) Has it been signed by the Supervisor?

Yes/No

Yes/No

5. (a) Is the Acknowledgement from the Student in proper format?

(b) Has it been signed by the Student?

Yes/No

6. Does the Table of Contents include page numbers?

(i) Are the Pages numbered properly?

(ii) Are the Figures numbered properly?

(iii) Are the Tables numbered properly?

(iv) Are the Captions for the Figures and Tables proper?

(v) Are the Appendices numbered properly?

Yes/No

Yes/No

Yes/No

Yes/No

Yes/No

Yes/No

7. Is the conclusion of the Report based on discussion of the work? Yes/No

8. Are References or Bibliography given in the Report?

Have the References been cited inside the text of the Report?

Is the citation of References in proper format?

Yes/No

Yes/No

Yes/No

9. A Compact Disk (CD) containing the softcopy of that Final Report (preferably in PDF format) and a Final Project Presentation in MS power point only (made to the Supervisor/Examiner has been placed in a protective jacket securely fastened to the inner back cover of the Final Report). Write the name and Roll No on the CD.

Yes/No

86


Project Guide’s Remark

87

File of SIMULATION OF NETWORK PROTOCOLS

Documents

Transcript of File of SIMULATION OF NETWORK PROTOCOLS