276
3, AUGUST 2002
Understanding and Implementing Computer Network
Protocols Through a Lab Project
Mohamed Watheq El-Kharashi, Student Member, IEEE, Glen Darling, Brent Marykuca, and
Gholamali C. Shoja, Senior Member, IEEE
Abstract—This paper describes a lab project in computer com-
munications and networks for senior undergraduate students in
computer science and engineering. Given detailed specifications,
students are asked to implement a data link layer (DLL) that in-
tegrates correctly with other provided layers to obtain a complete
working network stack. This lab gives the students the opportunity
to learn how to read formal specifications for a network project and
write a complete piece of source code. It provides a comprehensive
environment for students to write software for a network protocol,
test and debug it, and observe its working behavior. In this paper,
the authors present a technical description of the project and a dis-
cussion of related educational issues.
Index Terms—Computer communications and networks educa-
tion, data link layer (DLL), network architecture, network proto-
cols, open systems interconnection (OSI) reference model.
I. INTRODUCTION
C OMPUTER communications and networks is a standard
topic in undergraduate computer science and engineering
curriculum. There has been an increasing interest in the course
because of the growing popularity of the Internet and the
importance of networking in business environments. A lab
project for a computer communications and networks course
that fourth-year undergraduate computer science and engi-
neering students take at the University of Victoria, Victoria,
BC, Canada, is described in this paper [1].
In the lab, the authors adopt a three-layer network architec-
ture that consists of a physical layer, a data link layer (DLL),
and an application layer. Provided with application and phys-
ical layer software, students design and implement the logical
link control software to interface between these two layers ac-
cording to detailed specifications [1]. For simplicity, the logical
link control software is referred to as the DLL.
The project uses the Java network stack [2]–[4]. From the
Java system point of view, the whole project is an application.
However, a layer at the bottom of the project provides a simu-
lated abstraction of an Ethernet LAN, a simulated media access
control (SMAC) layer.
Manuscript received June 28, 2001; revised February 19, 2002.
M. W. El-Kharashi is with the Department of Electrical and Computer
Engineering, University of Victoria, Victoria, BC V8W 3P6, Canada (e-mail:
watheq@engr.uvic.ca).
G. Darling is with Cisco Systems, San Jose, CA 95134 USA (e-mail: gdar-
ling@cisco.com).
B. Marykuca is with Art and Logic Software Engineering and Design, Glen-
dale, CA 91203 USA (e-mail: brentm@telus.net).
G.C. Shoja is with the Department of Computer Science, University of Vic-
toria, Victoria, BC V8W 3P6, Canada (e-mail: gshoja@csc.uvic.ca).
Publisher Item Identifier S 0018-9359(02)05048-3.
0018-9359/02$17.00 © 2002 IEEE
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO.
The software implemented by students compensates for those
communication errors not handled by the SMAC (or those intro-
duced for testing purposes). That is, the SMAC can simulate un-
reliable packet transmission by the physical layer by randomly
discarding packets. It is up to the student’s DLL software to ac-
count for the possibility that some packets may be lost.
The application code (the Tester) acts as a client of the stu-
dent’s DLL and is used to test the developed code. The Tester is
also provided to the students.
The paper is organized as follows. The course background
necessary for the project is suggested in Section II. Section III
gives an overview of the project and highlights the students’
tasks. The project technical specifications that students imple-
ment are discussed in Section IV. Section V presents the envi-
ronment in which the project is developed. The variety of tools
students use to develop their projects are summarized in Sec-
tion VI. Section VII shows how the project is scheduled and
evaluated. Finally, conclusions are drawn in Section VIII.
II. COURSE BACKGROUND
The project described here aims at providing the experimental
support for the computer communications and networks course
that is taken by computer science and engineering students in
the Faculty of Engineering, University of Victoria.
The lab requires that the related network theory be covered in
the classroom lecture before the implementation of the project
is attempted. This theoretical background is expected to form
the foundation of the generic network architecture targeted by
the project and to clarify the expected operation of the relevant
protocol stack.
Topics with which the students need to be familiar before
starting the project include basics of network hardware and soft-
ware, layered architecture of different reference models, func-
tionalities of different layers and the interaction between them,
and example networks and data communication services. The
pre-project stage also emphasizes the operation of the physical
and data link layers, which fully prepares the students for the
project.
III. OVERVIEW
In the open systems interconnection (OSI) reference model,
specific network or communication services are grouped into
layers according to their functions [5]–[7]. Fig. 1 compares the
project model versus the IEEE 802.3 and OSI models [5]. In
this project, the standard seven layers of the OSI model are
compressed into just three layers. These three layers [shown in
EL-KHARASHI et al.: COMPUTER NETWORK PROTOCOLS LAB PROJECT
(a)
Fig. 1. A comparison of network hierarchies. (a) IEEE 802.3 model. (b) OSI model. (c) The project model.
Fig. 1(c)] are selected in such a way as to simplify the project
requirements and help the students focus on the project’s main
objectives. While compressing the OSI model into three layers,
some functions were grouped together, whereas others were not
used at all. This selection does not disturb the overall structure
of the model.
The first layer in the project, SMAC, is a simulated abstrac-
tion of an Ethernet LAN, i.e., the OSI media access control sub-
layer. The second layer, the DLL, is a client of the SMAC and
acts as the OSI logical link control sublayer. The combination
of these two layers is approximately equivalent to the OSI DLL.
The last layer, the Tester, acts as a client of the DLL.
From a functionality point of view, the SMAC provides to the
DLL simple packet transmission and retrieval services but does
not guarantee that packets sent will be received at the other end.
In other words, the SMAC does not imply any reliability fea-
tures other than if it gets there, it gets there uncorrupted. More-
over, the SMAC can simulate unreliable packet transmission by
the physical layer by randomly discarding packets. However, the
DLL does provide the Tester with the capability to communicate
reliably with any address. To be able to achieve that communi-
cation, the DLL must compensate for specific communication
errors not handled by the SMAC (or introduced for testing pur-
poses). Packet loss is the primary communication error in this
project. Finally, the Tester assists the lab instructors in evalu-
ating students’ code.
The full network stack was first developed by the authors
and tested for proper functionality. To achieve the lab objective
(i.e., to help the students develop an experience with a typical
DLL protocol), the students are provided with implementations
of only the SMAC and Tester layers and asked to develop the
missing DLL. Formally stated, the lab requirement is: given an
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
277
(b) (c)
implementation of the SMAC and the Tester layers as part of
the provided software distribution, the SMAC/DLL interface in
the class library notes and the Tester/DLL interface as detailed
application programming interface (API) specifications, the stu-
dents are required to implement the DLL.
IV. TECHNICAL SPECIFICATIONS
In this section, the authors provide a brief overview of the
technical specifications of the DLL project. They start with the
project core services. Then, advanced features are discussed.
Features that are optionally added from term to term are men-
tioned next. Finally, the protocol and data types are explained.
A. Core Services
The DLL only provides three communications services to its
clients, as follows:
1) Link Initialization (Init): requested by the client to open
a new connection or reinitialize an existing connection to
a remote host. Link initialization can be thought of as a
reset or synchronization phase of communication. Once
opened, a link is owned by both parties, and either of them
can then use, close, or reinitialize it.
2) Link Termination (Term): requested by the client to close
a connection which has been previously initialized.
3) Data Transmission (Data): requested by the client to send
arbitrary information over an initialized link.
The DLL allows its client to request these services and also
provides notification to the client when remote hosts make
similar requests involving the local system. The DLL provides
error recovery for lost transmissions, theoretically creating an
error-free link.
278 IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO. 3, AUGUST 2002

DLL clients gain access to these services through a Java inter-

face file that defines the API used by the DLL in communicating
with its client. The API is based roughly on the following four
kinds of service primitives defined in the OSI model and shown
in Fig. 2: requests, confirmations, indications, and responses.
Example 1: Assume that the link layer interface and class are
named DLL and LinkLayer, respectively. The LinkLayer
class implements the DLL interface. The DLL.java file will
look like:

public interface DLL {

public static final byte kInitPacket = Fig. 2. Different kinds of communication service primitives.
1;
... // other constant definitions the DLL. That is, the client gets its packets by polling the DLL
public abstract RequestReply initRe- rather than via interrupts. The response primitive is not used in
quest(InetAddress addr); this project.
... // other API method prototypes Example 3: The following Tester code shows how events are
} dispatched from the link layer:

if(theDLL.eventAvailable()) {
To gain access to DLL services, the Tester instantiates the LinkEvent e = theDLL.getEvent();
Java class representing the link layer. Requests are made by .. process the Event ...
making method invocations to DLL request routines. Each re- }
quest method returns a data structure that contains information
about the status of the request. If the request was rejected for The link layer queues and dequeues events as follows:
some reason, the returned value will contain a result code ex-
plaining the reason for the rejection. If the request was accepted, Vector eventQueue = new Vector();
then a request ID value will be assigned to it by the DLL, ...
and returned to the Tester. This ID is used by the Tester to track eventQueue.addElement(new LinkEvent(re-
each request and also to identify to which request a particular moteAddress,
confirmation packet applies. LinkEvent.kInitConfirmation,
Example 2: The following code shows an example of a link eventRequestId,LinkEvent.kNoError));
layer request routine:
Event dispatching methods could be defined in the link layer
public RequestReply termRequest(InetAd- class as follows:
dress addr) {
if (getExistingLinkNo(addr) == -1) public boolean eventAvailable() {
return (new RequestReply(Re- return !eventQueue.isEmpty();
questReply.kNonRequest, }
RequestReply.kNoSuchLink)); public LinkEvent getEvent() {
... other request validations return (LinkEvent) eventQueue.remove(0);
... queue request for later processing }
incrementRequestId();
return(new RequestReply(getNextRe-
questId())); From the other side, the DLL has access to sending and re-
} ceiving services provided by the SMAC. Sending is done via
a method invocation, whereas receiving is done by polling the
SMAC.
Communications from the DLL to its client are in the form Fig. 3 shows a diagram of the overall software architecture of
of events, which can be either solicited or unsolicited. A so- the system within which the student’s DLL will be incorporated.
licited event (or confirmation packet) is the result of making a It identifies the key methods in the API and some key compo-
DLL request. It is the way in which the client receives status nents of the class library that will be used in implementing the
information about the requests it has made. Unsolicited events DLL.
(or indication packets) are the result of remote hosts communi- The Tester is the entity that holds the system control. It peri-
cating with the DLL. In the course of the client’s processing, odically transfers control to the DLL by invoking the link layer’s
it must make occasional invocations to a DLL access routine, process() method. The specifications do not require this
which informs it of any confirmations or indications posted by method to do anything in particular. It is invoked to give some

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
EL-KHARASHI et al.: COMPUTER NETWORK PROTOCOLS LAB PROJECT
Fig. 3. Link layer system architecture.
Fig. 4. A suggestion for DLL module shell.
processing time to the DLL. Thus, the DLL implementations
use this method to send packets to remote hosts and to process
arriving ones.
In addition to the above point-to-point reliable communica-
tion services, the DLL also provides the ability to carry on sev-
eral simultaneous communications with different clients. Fig. 4
shows a DLL module shell with a possible arrangement for main
data structures. Students are allowed to change this arrangement
to provide more efficient realization, as will be discussed later
in Section VII.
B. Advanced Issues
In this subsection, the authors describe some advanced issues
that the students are exposed to during the project. Most of the
DLL communication services that are provided revolve around
reliability in packet delivery. Given SMAC services that provide
best effort communications, the DLL sends packets to confirm
delivery. It must also handle the retransmission of data that is
not confirmed.
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
279
To handle packet retransmissions, the DLL times each sent
packet. When a time-out occurs, the packet is retransmitted. A
timer module is provided to ease the development task. Students
implement a callback method to handle timer events. A timer is
set up with a countdown time and instructions as to what to do
in this callback routine. When the time elapses, this callback
routine is invoked with the information specified. This routine
can then act accordingly (perhaps retransmitting the packet if no
acknowledgment has been received).
One other advanced feature is piggybacking. For better use of
bandwidth, the project specifications require that data acknowl-
edgments be piggybacked on outgoing data packets. That is, ac-
knowledgments are not allowed to be sent separately to a remote
node unless there is not a ready-to-go data packet targeting that
node.
C. Optional Features
Aspects described so far provide a complete, nontrivial
project. In addition, the authors have a list of optional features
to select from every term to provide some challenging tasks
that differ from term to term:
1) Init Busy (IBusy) Packets: sent to indicate that the receiver
received the Init request correctly but was forced to deny
the requested service because no available communica-
tion link was available on the receiver.
2) Receiver Busy (RBusy) Packets: sent to indicate that the
receiver received the data request correctly but was forced
to discard it because of a lack of buffer space. This feature
shows how the DLL can react to machine overloads in a
consistent manner.
3) Host Going Down (HGD) Packets: sent automatically by
the DLL to all remote hosts that the DLL keeps connec-
tions with upon the client’s requests to terminate the cur-
rent application session. Since they carry low-reliability
termination packets between stations, HGD packets are
sent once, and no acknowledgment is expected in return.
4) Out of Band (OOB) Data Packets: carry high-urgency
low-reliability data between hosts. OOB packets are sent
once, and no acknowledgment is expected in return.
5) Data Segmentation and Reassembly: the size of data
communicated between the DLL and the SMAC can be
limited to a size smaller than that exchanged between
the DLL and the Tester. Therefore, sender DLLs have to
break up data into segments that are reassembled by the
receiver DLLs. This process is done transparently to the
DLL client.
D. Protocol and Packet Types
Because it is the simplest reliable protocol, the Alternating
Bit Protocol (ABP) with piggyback acknowledgment is used for
communication in this project. It uses a sequence number and
an acknowledgment number to communicate. Sequence and ac-
knowledgment numbers belong to the set and are inde-
pendent from each other.
The services described in this section are implemented with
the aid of standardized packets that are sent between machines
using the SMAC. Each packet is simply an array of bytes with
280
TABLE I
DLL PACKET FORMAT
TABLE II
SUPPORTED PACKET TYPES
the general format summarized in Table I. Each packet has a par-
ticular meaning. Core and optional services generate packets of
certain types. Some of these services require acknowledgments
to be sent that also have their own packet type. Table II summa-
rizes supported protocol packet types and their use.
V. DEVELOPMENT ENVIRONMENT
In this section, the authors describe the environment in which
the students develop their project. They start with the develop-
ment platform, then they discuss the use of Java as the project
language. Finally, they explain in detail the way a simulated
LAN is provided for the students.
A. Platform
The Computer Science Department at University of Victoria
has a stand-alone computer communications and networks lab.
This lab has its own isolated subnetwork that interfaces to the
engineering network through a gateway. Isolating the lab net-
work from the engineering network gives the students complete
freedom in developing their projects without worrying about
flooding the engineering network with excessive packets. Stu-
dents can log in to the lab gateway from home through remote
shells to run their own network stack on a number of machines
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO. 3, AUGUST 2002
to test their projects. Development is done on Pentium-based
PCs running Sun Solaris.
B. Programming Language
The language of choice for the project is Java [8]–[11]. Java
was selected for its powerful networking capabilities and ease
of use [2]–[4]. As mentioned before, the project is built on top of
the Java virtual machine network stack (i.e., the whole project is
just a network application written in Java). However, the SMAC
organization gives its clients the illusion of being at the OSI
DLL level. The SMAC is organized in a way to shield the stu-
dents from details that are not directly related to the DLL pro-
tocol.
C. Simulated LAN
The SMAC uses the multicast User Diagram Protocol (UDP)
that runs on top of Internet Protocol (IP) to simulate an Ethernet
environment. Computers linked together with an Ethernet
network have access to a common transmission media which
provides an efficient but unreliable communication services.
Adopting a multicast UDP/IP protocol simulates the shared
environment in which arbitrary packets sent by one host are
echoed to all others, thus simulating an Ethernet operation.
To enable many users’ network traffic to coexist on the net-
work without interference, a different multicast group is con-
structed for each student. Unique multicast groups could be con-
structed by using unique listening ports. At the beginning of
the project, each student selects a unique Personal Port Number
(PPN) and saves it in a file in the DLL directory to be used as
the SMAC listening port.
When the SMAC is instantiated, its constructor installs a mul-
ticast UDP port listener in a separate execution thread using
the student’s PPN. (The main program thread and this listener
thread are the only threads required in the DLL project.) For the
rest of the time that the student’s program is running, that lis-
tener thread will remain instantiated. As long as it persists, that
listener will sit in the background collecting packets as they are
received and inserting them into a receiving queue implemented
as a synchronized Java Vector object.
Communication through the SMAC is done through the fol-
lowing simple scenario that simulates a real LAN: when a local
DLL wants to deliver a packet to another remote host, it does
so by invoking the SMAC sending routine. This routine sends
the packet to the multicast group, which reflects it back to all
machines in that group. By periodical invocation of the SMAC
receiving routine, DLLs pick packets from the receiving queue.
DLLs ignore received packets that are not intended for them. It
is worth mentioning that the hop count for packets delivered to
the multicast group is set in a way to keep the packets inside the
isolated lab network.
VI. DEVELOPMENT TOOLS
A variety of tools are made available for the students to help
them while developing their projects. Five classes of tools are
discussed in this section: class libraries, the Tester shell, testing
EL-KHARASHI et al.: COMPUTER NETWORK PROTOCOLS LAB PROJECT 281

and debugging methodologies, working off-line, and the packet

Watcher.

A. Class Libraries
In addition to the standard Java classes [12], several support
classes are used to connect students’ DLL code with the applica-
tion client and the SMAC layer. The students are provided with
a class library that helps them in code development.
The DLL class library contains a Timer class to facilitate
the timely retransmission of packets that have not been appro-
priately acknowledged by the remote machine. There is also a
Packet class that serves as a receptacle for data being com-
municated with the SMAC. A Utility class containing mis-
cellaneous utility routines is also provided.

B. The Tester Shell

The Tester shell application is to be used to demonstrate
whether the student’s DLL project works.
Example 4: The Tester life cycle is an infinite loop that looks
like:

private static LinkLayer theDLL;
...
while (1) {
getInputFromUser();
processUserInput();
theDLL.process();
dispatchLinkLayerEvents();
}
The Tester also provides many features to assist in code de-
velopment, including the ability to create data, make Init, Date,
and Term requests, and view the returned reply. It also displays
the events posted by the DLL on the screen. Fig. 5 shows the
Tester help screen with a list of the commands the Tester under-
stands. Commands to the Tester are of four types (shown in the
figure in the upper four partitions): request, content, testing and
debugging, and off-line development commands. The first two
will be discussed here; the others will be discussed in the next
two subsections.
Request commands, such as initRequest(), dataRe-
quest(), and termRequest(), interface directly with the
corresponding DLL request routines. These commands can be
issued multiple times back to back to test different aspects of
the DLL protocol.
Content commands are provided by the Tester shell to allow
the students to select the content that will be sent in data requests
and to view the content received in data indications.
C. Methods for Testing and Debugging
The Tester shell provides several commands to help examine
the internal data structures during testing and to help contrive
unusual circumstances to aid in testing the limitations of a stu-
dent’s DLL.
The first of these commands is links, which interfaces with
the link layer’s status() method. This method returns the
Fig. 5. List of commands that the Tester understands.
status and history of each opened link per host. This command
allows the collection of some statistics about packet transmis-
sion and delivery.
The second command of this type is the busy command. It
turns on and off calling the link layer’s getEvent() method.
In the busy mode, the Tester shell stops calling this method,
and, therefore, incoming Data indication events will be queued.
This feature exists for the sole purpose of testing the RBusy
packet transaction specified in the protocol.
The third command in this series is the reliability com-
mand, which interfaces with the SMAC to control its sending
and receiving behavior directly. It causes the SMAC to fail in
sending and/or receiving packets with some probability. There-
fore, it simulates having network problems and allows testing
the ability of the student’s DLL to recover from lost packets.
The final command in this series helps students to debug their
DLL. When the debug command is issued, the Tester shell
will simply call the link layer’s debug() method. Within that
method, students may display the contents of important internal
state variables.
D. Working Off-line
There are three commands that have been provided to assist
students who work at home or elsewhere without networking
facilities. The enter command allows a user to construct a
packet (destination address, header, and data length, if any) at
the keyboard and have the SMAC simulate its receipt from a re-
mote host. Two of these commands allow creating files full of
packet contents that can be read by the SMAC in order to sim-
ulate content being received by the local host over the network.
The file command causes a packet vector file to be read into
an internal buffer. The packet command can then be used to
release packets that are stored in that buffer.

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
282 IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO. 3, AUGUST 2002

E. The Packet Watcher

During project testing, it is useful to monitor packet traffic
going back and forth between hosts under test. When students
issue a command to one Tester instance that should send a packet
to another Tester instance and return an acknowledgment and
something goes wrong, there are many possibilities to track
down. Packet monitoring can save students considerable debug-
ging time because they can watch the network to see whether the
first packet was sent and had the correct structure or whether a
reply packet was sent and had the correct structure.
The packet Watcher allows monitoring of all packet traffic
in the network that uses a certain PPN. The Watcher program
is also capable of parsing DLL packets to detect some typical
packet configuration errors.
Watcher has three different (and mutually exclusive) packet
monitoring modes: 1) a physical mode primarily intended for
instructors’ use in debugging the SMAC layer, though students
may use it to view the packets as they are sent by the SMAC
(with embedded address information and any other fields the
SMAC may add to DLL packets before sending them); 2) a ver-
bose mode–the mode most used—in which all of the packet con-
tents are parsed and displayed in an easy-to-read manner; 3) a
brief mode that allows viewing DLL packets one packet per line,
useful while watching a long series of transactions, such as when
working on piggybacking or RBusy transactions. Fig. 6 shows
a sample output from the packet Watcher.

VII. SCHEDULE AND EVALUATION
In this section, the authors show how the project is divided
into milestones and how these milestones are scheduled over the
project period. Table III gives the schedule and grade division
for the project. The project spans a period of half of a term (6
weeks). Related work is divided into two tutorials, two work
sessions, a quiz, and two project demonstrations.
Fig. 6. Sample output from the packet Watcher. hostB initializes a link to
hostA, which acknowledges this request. Packets corresponding to these two
actions are shown in the verbose mode. Five simultaneous data requests are then
made between the two hosts to test piggybacking. This action is shown in the
brief mode. Refer to Table I for expansion of abbreviations. The data contents
of each Data packet are sequential numbers from 0 to 4.
TABLE III
TERM SCHEDULE WITH CORRESPONDING CREDITS

A. Tutorials and Work Sessions

Students are given two comprehensive in-lab tutorials. Com-
plementing the online documentation, these tutorials are de-
signed to provide insights about the project specifications. Dis-
cussion is divided among design concepts and implementation
approaches. The first tutorial starts by introducing the project
and the programming environment. The authors then explain the
used DLL protocol and the DLL interface with the other two
layers. By the end of this tutorial, students should have a clear
picture about the overall DLL organization and how different
aspects could be put together to produce a working project.
During the second tutorial, advanced topics are discussed. In examples are also discussed to trigger deep thinking by students
this tutorial, a working version of the project is presented to the (Example 5).
students to give them a feeling about how the project should Example 5: Consider this case: Host A sends (DATA,0,1)
work. At the same time, development tools are discussed and to host B. B replies with (RBUSY,0,0)to A then sends it
demonstrated. Both tutorials aim at clarifying the project re- (DATA,0,1). Write out the remaining packet exchanges.
quirements and give the students a structured task list. Tutorials are done in a discussion format with input from
During tutorials, examples are provided to clarify different students. Different design options are highlighted with pros
concepts. Trace examples are excellent teaching aids. Exam- and cons for each. For example, other alternatives to the shell
ples can be shown in the form of vertical time-line diagrams module in Fig. 4 are investigated to justify using multiple
(Fig. 7) or in a form of tables showing requested services, ex- request queues. Another example deals with timers. Tutorial
changed packets, and resultant events (Table IV). Challenging explanations justify the need for timers and help the students

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
EL-KHARASHI et al.: COMPUTER NETWORK PROTOCOLS LAB PROJECT
Fig. 7. Example traces exchanged between two hosts A and B. A link is first
initialized between them, a set of Data packets are then sent back and forth, and
finally, the link is terminated. Examples show piggybacking and error recovery
in the case of losing a Data packet or its acknowledgment. Packets are denoted
by the tuple (Type, SeqNo, AckNo). The other fields in the packet are omitted
here since they do not affect the operation of the protocol. Traces are shown
graphically. Table IV shows the same information as table entries.
select an appropriate number of timers to incorporate in the
system and determine the suitable time instance to create, start,
and stop them.
When the students start developing the project on their
own, they are given the chance to ask questions through two
work sessions. During these work sessions, questions and
developing problems are brought to the lab. The instructors
then work closely with each individual trying to solve his or
her problem, e.g., by discussing adopted design concepts or by
code inspection.
B. Quiz and Demonstrations
To ensure students understand the DLL requirements, they
are given a brief in-lab DLL quiz early in the term. The quiz
is designed as a set of multiple-choice questions that is marked
in the lab. Example 6 shows a typical quiz question. Time is
devoted for discussing quiz questions.
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
283
TABLE IV
TABULARIZATION OF THE EXAMPLE TRACES SHOWN IN FIG. 7
Example 6: Receiving a packet may generate 0, 1, or 2 local
events. When an Init packet is received, it normally generates 1
local event (Init indication). Which situation generates no local
events while connected?
1) Receipt of a duplicate Data packet.
2) Receipt of a Term packet.
3) Receipt of a duplicate Init packet.
4) No answer is correct.
Students’ code evaluation is divided into two demonstrations:
beta and final. During the beta stage, DLLs are only required
to initialize and terminate links with different scenarios. This
milestone helps the instructors detect students who are having
trouble getting started. No data requests are tested during this
demonstration. Furthermore, perfect network conditions are as-
sumed. That is, reliability features are not tested. During the
final demonstration, students are required to present a com-
plete implementation of the posted DLL specifications. To pre-
pare for both demonstrations, students are given a complete task
checklist.
Demonstration requirements are transformed into a set of
tasks, each worth one point. These tasks are organized in
the form of a marking sheet and used to check the students’
implementation. These marking sheets are made available
at the beginning of the project for the students to use as a
guideline. A script is used to mark each task. If a student’s code
demonstrates the correct and expected behavior, the student
gets the mark for the question. Example 7 shows a sample task
included in the final marking sheet and its testing script.
Example 7: Test for receiving out-of-sequence data. Corre-
sponding script is as follows.
• Initialize a link between the two hosts A and B.
• Set receiving reliability on A to 0.
284
• Send a Data packet from A to B.
• Observe transmission of the Data packet and its DAck.
• Observe retransmission of the Data packet (since A will
not receive its acknowledgment, it will retransmit it).
• For B, this packet is out of sequence. B should acknowl-
edge then discard it. That is, no indication should be re-
posted on B.
In addition to technically marking student projects, code style
is also checked for such characteristics as modularity and clarity.
VIII. CONCLUSION
In this paper, the authors have presented a lab project that
teaches computer science and engineering students how to
design, implement, and test a simple single-bit DLL protocol.
This DLL project provides an excellent venue for the students
studying computer communications and networks to exper-
iment with implementation of network protocols. It offers
them a guided opportunity to comprehend detailed network
specifications and design a communication layer that adheres
to the desired characteristics. Furthermore, the lab familiarizes
the students with protocol testing and debugging, using an
advanced set of methodologies and tools.
The well-structured lab environment and support infrastruc-
ture present an outstanding platform for the students to use to
experiment, maximizing the benefits from the project. Java is
chosen as the project language for its suitability for network pro-
gramming. This selection helps students focus on major project
objectives and masks the time-consuming, low-level implemen-
tation details. The discussion in this paper is illustrated with
some Java code fragments. Also presented are the evaluation
methods used to make the students follow a consistent schedule
that results in a high project completion rate.
Finally, the reader is invited to browse through the project
website [1]. The online documentation includes the detailed
project specifications, full class library notes, and user manual
for the relevant tools.
REFERENCES
[1] UVic, Computer Science 450. (2002, Jan./Feb. 15) Data Link
Layer (DLL) project documentation in University of Victoria,
Computer Science 450 Lab Web Page. [Online]. Available:
http://www.csc.uvic.ca/~csc450/Lab/.
[2] M. Hughes, M. Shoffner, and D. Hamner, Java Network Programming,
2nd ed. Greenwich, CT: Manning, 1999.
[3] E. R. Harold, Java Network Programming, 2nd ed. Sebastopol, CA:
O’Reilly & Associates, 2000.
[4] D. E. Comer, Computer Networks and Internets With Internet Applica-
tions, 3rd ed. Englewood Cliffs, NJ: Prentice-Hall, 2001.
[5] A. S. Tanenbaum, Computer Networks, 3rd ed. Englewood Cliffs, NJ:
Prentice-Hall, 1996.
[6] A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental
Concepts and Key Architecture. New York, NY: McGraw-Hill, 2000.
[7] W. Stallings, Data and Computer Communications, 6th
ed. Englewood Cliffs, NJ: Prentice-Hall, 2000.
[8] M. Campione, K. Walrath, and A. Huml, The Java Tutorial: A Short
Course on the Basics, 3rd ed. Reading, MA: Addison-Wesley, 2001.
[9] K. Arnold, J. Gosling, and D. Holmes, The Java Programming Lan-
guage, 3rd ed, ser. The Java Series. Reading, MA: Addison-Wesley,
2000.
[10] J. Bishop, Java Gently: Programming Principles Explained, 3rd
ed. Reading, MA: Addison-Wesley, 2002.
Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO. 3, AUGUST 2002
[11] J. Lewis and W. Loftus, Java Software Solutions: Foundations of Pro-
gram Design, 2nd ed. Reading, MA: Addison-Wesley, 2000.
[12] Java Software. (2002, Jan.) Java 2 SDK Documentation (Ver-
sion 1.4.0) in Java 2 Platform Web Page. [Online]. Available:
http://java.sun.com/j2se/1.4/docs/.
Mohamed Watheq El-Kharashi (S’97) received
the B.Sc. and M.Sc. degrees in computer engineering
from Ain Shams University, Cairo, Egypt, in 1992
and 1996, respectively. He is currently working
towards the Ph.D. degree in computer engineering
with the Department of Electrical and Computer
Engineering, University of Victoria, Victoria, BC,
Canada, and is working on hardware support for
Java.
He currently teaches courses in computer
architecture, embedded systems, and computer
networks at the University of Victoria. His research interests include advanced
microprocessor design, simulation, performance evaluation, and testability;
Java performance improvement; and computer architecture and computer
networks education.
Mr. El-Kharashi is a Student Member of the Association of Computing
Machinery (ACM), the ACM Special Interest Group on Computer Architecture
(SIGARCH), and the ACM Special Interest Group on Microarchitecture
(SIGMICRO).
Glen Darling received the B.Sc. and M.Sc. degrees
in computer science from the University of Victoria,
Victoria, BC, Canada, in 1984 and 1995, respectively.
For more than ten years, he taught computer
science at the University of Victoria, Victoria, BC,
Canada, while also managing the Computer Science
Department lab facilities and writing software to
support the labs. In addition, for the last five of
those years, he was also the Software Architect for
a small computer-based training company providing
customized educational software, mostly for large telecommunication and
networking firms. Since 2000, he has been working for Cisco Systems, Inc.,
San Jose, CA, as a Tech Lead for a team of 18 engineers providing development
tools for a larger group of engineers working on Cisco’s next generation of
routers.
Brent Marykuca received the B.Sc. degree in com-
puter science from the University of Victoria, Vic-
toria, BC, Canada, in 1993.
Currently, he is employed as a software engineer
for Art & Logic Software Engineering & Design,
Glendale, CA, where he works on developing
application and driver software for desktop and
embedded computing systems.
Gholamali C. Shoja (M’82–SM’90) received the
B.S.E.E. degree from Kansas State University,
Manhattan, KS, in 1961, the M.S.E.E. degree from
Northwestern University, Evanston, IL, in 1964,
and the Ph.D. degree in computer science from
University of Sussex, Brighton, Sussex, U.K., in
1981.
He is currently an Associate Professor of Com-
puter Science at the University of Victoria, Victoria,
BC, Canada. He is also a Research Scientist with
the New Media Innovation Center (NewMIC) in
Vancouver, BC. His area of research includes computer networks, distributed
computing, and multimedia systems.