Post on 31-Dec-2015
description
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 of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
• 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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
6. SYSTEM DESIGN SPECIFICATIONS
6.1 Flow Chart
Fig. 9: Flowchart for whole application
27
START
ENCAPSULATION
PROTOCOLS
DECAPSULATION
STOP
Simulation of Network Protocols
6.2 Sequence Diagram
Fig. 10: Sequence diagram for ideal case
28
Simulation of Network Protocols
6.2.1 For Go Back N
Fig. 11: Sequence diagram for lost frame and time out in Go-Back-N
29
Simulation of Network Protocols
Fig. 12: Sequence diagram for lost acknowledgement in Go-Back-N
30
Simulation of Network Protocols
6.2.2 For Selective Repeat
Fig. 13: Sequence diagram for lost frame in Selective Repeat
31
Simulation of Network Protocols
Fig. 14: Sequence diagram for lost acknowledgement in Selective Repeat
32
Simulation of Network Protocols
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
Simulation of Network Protocols
Fig. 17: Collaboration diagram for lost acknowledgement in Go-Back-N
34
Simulation of Network Protocols
6.3.2 For Selective Repeat
Fig. 18: Collaboration diagram for lost acknowledgement in Selective Repeat
Fig. 19: Collaboration diagram for lost frame in Selective Repeat
35
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
• 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
Simulation of Network Protocols
• 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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
Fig. 21: Test case 1 frame sent by sender
Fig. 22: Test case 1 frame received by reciever
51
Simulation of Network Protocols
Fig. 23: Test case 2 acknowledgement sent
Fig. 24: Test case 2 acknowledgement received
52
Simulation of Network Protocols
Fig. 25: Test case 3 resend frame after time out
Fig. 26: Test case 3 acknowledgement for resent frames
53
Simulation of Network Protocols
Fig. 27: Test case 3 acknowledgement received
Fig. 28: Test case 4 packet killed
54
Simulation of Network Protocols
Fig. 29: Test case 4 acknowledgement for received frames
Fig. 30: Test case 4 killed packet resend after time out
55
Simulation of Network Protocols
Fig. 31: Test case 4 acknowledgement received
10.5.2 For Selective Repeat
Fig. 32: Test case 1 frame sent by sender
56
Simulation of Network Protocols
Fig. 33: Test case 1 frame received by reciever
Fig. 34: Test case 2 acknowledgement sent
57
Simulation of Network Protocols
Fig. 35: Test case 2 acknowledgement received
Fig. 36: Test case 3 resend frame after time out
58
Simulation of Network Protocols
Fig. 37: Test case 3 acknowledgement for resent frames
Fig. 38: Test case 3 acknowledgement received
59
Simulation of Network Protocols
Fig. 39: Test case 4 packet killed
Fig. 40: Test case 4 acknowledgement for received frames and frame buffered out of order
60
Simulation of Network Protocols
Fig. 41: Test case 4 killed packet resend after time out
Fig. 42: Test case 4 acknowledgement received
61
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Simulation of Network Protocols
Fig. 47 : Sending frame
Acknowledgement recieved
Fig. 48 : Receiving acknowledgement
Packet kill
75
Simulation of Network Protocols
Fig. 49 : kill packet
Fig. 50 : Acknowledgement of left frames being sent
When time out occurs
76
Simulation of Network Protocols
Fig. 51 : when time out occur
After clicking on selective repeat, this window will appear
Fig. 52 : Selective Repeat interface
frame sent
77
Simulation of Network Protocols
Fig. 53 : Sending frame
Acknowledgement recieved
Fig. 54 : Receiving acknowledgement
78
Simulation of Network Protocols
Packet kill
Fig. 55 : kill packet
Acknowledgement killed
Fig. 56 : Acknowledgement of left frames being sent and frame is buffered out of order
79
Simulation of Network Protocols
When time out occurs
Fig. 57 : when time out occur
When Decapsulation is clicked ,window will appear illustrating Decapsulation
Fig. 58 : Depicts decapsulation
80
Simulation of Network Protocols
WEB INTEGRATED VERSION
Fig. 59: Application interface
After clicking on encapsulation, this window will appear illustrating encapsulation
Fig. 60: Depicts encapsulation
81
Simulation of Network Protocols
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
Simulation of Network Protocols
Interface for Selective Repeat
Fig. 63: Selective Repeat interface
And if one clicks on decapsulation , this window will appear
Fig. 64: Depicts decapsulation
83
Simulation of Network Protocols
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
Simulation of Network Protocols
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
Fig 37 Test case 3 The receiver sends corresponding acknowledgement(green) for the
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
Fig 40 Test case 4 The receiver sends corresponding acknowledgement(green) for the
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
Simulation of Network Protocols
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
Simulation of Network Protocols
Project Guide’s Remark
87