You are on page 1of 9

276 IEEE TRANSACTIONS ON EDUCATION, VOL. 45, NO.

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- The software implemented by students compensates for those
munications and networks for senior undergraduate students in communication errors not handled by the SMAC (or those intro-
computer science and engineering. Given detailed specifications, duced for testing purposes). That is, the SMAC can simulate un-
students are asked to implement a data link layer (DLL) that in-
tegrates correctly with other provided layers to obtain a complete reliable packet transmission by the physical layer by randomly
working network stack. This lab gives the students the opportunity discarding packets. It is up to the student’s DLL software to ac-
to learn how to read formal specifications for a network project and count for the possibility that some packets may be lost.
write a complete piece of source code. It provides a comprehensive The application code (the Tester) acts as a client of the stu-
environment for students to write software for a network protocol, dent’s DLL and is used to test the developed code. The Tester is
test and debug it, and observe its working behavior. In this paper,
the authors present a technical description of the project and a dis- also provided to the students.
cussion of related educational issues. The paper is organized as follows. The course background
necessary for the project is suggested in Section II. Section III
Index Terms—Computer communications and networks educa-
tion, data link layer (DLL), network architecture, network proto- gives an overview of the project and highlights the students’
cols, open systems interconnection (OSI) reference model. 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
I. INTRODUCTION students use to develop their projects are summarized in Sec-
tion VI. Section VII shows how the project is scheduled and
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
evaluated. Finally, conclusions are drawn in Section VIII.

because of the growing popularity of the Internet and the II. COURSE BACKGROUND
importance of networking in business environments. A lab The project described here aims at providing the experimental
project for a computer communications and networks course support for the computer communications and networks course
that fourth-year undergraduate computer science and engi- that is taken by computer science and engineering students in
neering students take at the University of Victoria, Victoria, the Faculty of Engineering, University of Victoria.
BC, Canada, is described in this paper [1]. The lab requires that the related network theory be covered in
In the lab, the authors adopt a three-layer network architec- the classroom lecture before the implementation of the project
ture that consists of a physical layer, a data link layer (DLL), is attempted. This theoretical background is expected to form
and an application layer. Provided with application and phys- the foundation of the generic network architecture targeted by
ical layer software, students design and implement the logical the project and to clarify the expected operation of the relevant
link control software to interface between these two layers ac- protocol stack.
cording to detailed specifications [1]. For simplicity, the logical Topics with which the students need to be familiar before
link control software is referred to as the DLL. starting the project include basics of network hardware and soft-
The project uses the Java network stack [2]–[4]. From the ware, layered architecture of different reference models, func-
Java system point of view, the whole project is an application. tionalities of different layers and the interaction between them,
However, a layer at the bottom of the project provides a simu- and example networks and data communication services. The
lated abstraction of an Ethernet LAN, a simulated media access pre-project stage also emphasizes the operation of the physical
control (SMAC) layer. and data link layers, which fully prepares the students for the
project.
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:
III. OVERVIEW
watheq@engr.uvic.ca). In the open systems interconnection (OSI) reference model,
G. Darling is with Cisco Systems, San Jose, CA 95134 USA (e-mail: gdar-
ling@cisco.com). specific network or communication services are grouped into
B. Marykuca is with Art and Logic Software Engineering and Design, Glen- layers according to their functions [5]–[7]. Fig. 1 compares the
dale, CA 91203 USA (e-mail: brentm@telus.net). project model versus the IEEE 802.3 and OSI models [5]. In
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). this project, the standard seven layers of the OSI model are
Publisher Item Identifier S 0018-9359(02)05048-3. compressed into just three layers. These three layers [shown in
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.
EL-KHARASHI et al.: COMPUTER NETWORK PROTOCOLS LAB PROJECT 277

(a) (b) (c)


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 implementation of the SMAC and the Tester layers as part of
requirements and help the students focus on the project’s main the provided software distribution, the SMAC/DLL interface in
objectives. While compressing the OSI model into three layers, the class library notes and the Tester/DLL interface as detailed
some functions were grouped together, whereas others were not application programming interface (API) specifications, the stu-
used at all. This selection does not disturb the overall structure dents are required to implement the DLL.
of the model.
The first layer in the project, SMAC, is a simulated abstrac- IV. TECHNICAL SPECIFICATIONS
tion of an Ethernet LAN, i.e., the OSI media access control sub-
In this section, the authors provide a brief overview of the
layer. The second layer, the DLL, is a client of the SMAC and
technical specifications of the DLL project. They start with the
acts as the OSI logical link control sublayer. The combination
project core services. Then, advanced features are discussed.
of these two layers is approximately equivalent to the OSI DLL.
Features that are optionally added from term to term are men-
The last layer, the Tester, acts as a client of the DLL.
tioned next. Finally, the protocol and data types are explained.
From a functionality point of view, the SMAC provides to the
DLL simple packet transmission and retrieval services but does
A. Core Services
not guarantee that packets sent will be received at the other end.
In other words, the SMAC does not imply any reliability fea- The DLL only provides three communications services to its
tures other than if it gets there, it gets there uncorrupted. More- clients, as follows:
over, the SMAC can simulate unreliable packet transmission by 1) Link Initialization (Init): requested by the client to open
the physical layer by randomly discarding packets. However, the a new connection or reinitialize an existing connection to
DLL does provide the Tester with the capability to communicate a remote host. Link initialization can be thought of as a
reliably with any address. To be able to achieve that communi- reset or synchronization phase of communication. Once
cation, the DLL must compensate for specific communication opened, a link is owned by both parties, and either of them
errors not handled by the SMAC (or introduced for testing pur- can then use, close, or reinitialize it.
poses). Packet loss is the primary communication error in this 2) Link Termination (Term): requested by the client to close
project. Finally, the Tester assists the lab instructors in evalu- a connection which has been previously initialized.
ating students’ code. 3) Data Transmission (Data): requested by the client to send
The full network stack was first developed by the authors arbitrary information over an initialized link.
and tested for proper functionality. To achieve the lab objective The DLL allows its client to request these services and also
(i.e., to help the students develop an experience with a typical provides notification to the client when remote hosts make
DLL protocol), the students are provided with implementations similar requests involving the local system. The DLL provides
of only the SMAC and Tester layers and asked to develop the error recovery for lost transmissions, theoretically creating an
missing DLL. Formally stated, the lab requirement is: given an error-free link.

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.
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 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:
Fig. 3. Link layer system architecture. 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.
Fig. 4. A suggestion for DLL module shell.
4) Out of Band (OOB) Data Packets: carry high-urgency
low-reliability data between hosts. OOB packets are sent
processing time to the DLL. Thus, the DLL implementations once, and no acknowledgment is expected in return.
use this method to send packets to remote hosts and to process 5) Data Segmentation and Reassembly: the size of data
arriving ones. communicated between the DLL and the SMAC can be
In addition to the above point-to-point reliable communica- limited to a size smaller than that exchanged between
tion services, the DLL also provides the ability to carry on sev- the DLL and the Tester. Therefore, sender DLLs have to
eral simultaneous communications with different clients. Fig. 4 break up data into segments that are reassembled by the
shows a DLL module shell with a possible arrangement for main receiver DLLs. This process is done transparently to the
data structures. Students are allowed to change this arrangement DLL client.
to provide more efficient realization, as will be discussed later
in Section VII. D. Protocol and Packet Types
Because it is the simplest reliable protocol, the Alternating
B. Advanced Issues Bit Protocol (ABP) with piggyback acknowledgment is used for
In this subsection, the authors describe some advanced issues communication in this project. It uses a sequence number and
that the students are exposed to during the project. Most of the an acknowledgment number to communicate. Sequence and ac-
DLL communication services that are provided revolve around knowledgment numbers belong to the set and are inde-
reliability in packet delivery. Given SMAC services that provide pendent from each other.
best effort communications, the DLL sends packets to confirm The services described in this section are implemented with
delivery. It must also handle the retransmission of data that is the aid of standardized packets that are sent between machines
not confirmed. using the SMAC. Each packet is simply an array of bytes with

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

TABLE I to test their projects. Development is done on Pentium-based


DLL PACKET FORMAT 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
TABLE II The SMAC uses the multicast User Diagram Protocol (UDP)
SUPPORTED PACKET TYPES
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 general format summarized in Table I. Each packet has a par- the student’s PPN. (The main program thread and this listener
ticular meaning. Core and optional services generate packets of thread are the only threads required in the DLL project.) For the
certain types. Some of these services require acknowledgments rest of the time that the student’s program is running, that lis-
to be sent that also have their own packet type. Table II summa- tener thread will remain instantiated. As long as it persists, that
rizes supported protocol packet types and their use. 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.
V. DEVELOPMENT ENVIRONMENT
Communication through the SMAC is done through the fol-
In this section, the authors describe the environment in which lowing simple scenario that simulates a real LAN: when a local
the students develop their project. They start with the develop- DLL wants to deliver a packet to another remote host, it does
ment platform, then they discuss the use of Java as the project so by invoking the SMAC sending routine. This routine sends
language. Finally, they explain in detail the way a simulated the packet to the multicast group, which reflects it back to all
LAN is provided for the students. machines in that group. By periodical invocation of the SMAC
receiving routine, DLLs pick packets from the receiving queue.
A. Platform DLLs ignore received packets that are not intended for them. It
is worth mentioning that the hop count for packets delivered to
The Computer Science Department at University of Victoria the multicast group is set in a way to keep the packets inside the
has a stand-alone computer communications and networks lab. isolated lab network.
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 VI. DEVELOPMENT TOOLS
freedom in developing their projects without worrying about
flooding the engineering network with excessive packets. Stu- A variety of tools are made available for the students to help
dents can log in to the lab gateway from home through remote them while developing their projects. Five classes of tools are
shells to run their own network stack on a number of machines discussed in this section: class libraries, the Tester shell, testing

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 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; Fig. 5. List of commands that the Tester understands.
...
while (1) { status and history of each opened link per host. This command
getInputFromUser(); allows the collection of some statistics about packet transmis-
processUserInput(); sion and delivery.
theDLL.process();
The second command of this type is the busy command. It
dispatchLinkLayerEvents();
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
The Tester also provides many features to assist in code de- packet transaction specified in the protocol.
velopment, including the ability to create data, make Init, Date, The third command in this series is the reliability com-
and Term requests, and view the returned reply. It also displays mand, which interfaces with the SMAC to control its sending
the events posted by the DLL on the screen. Fig. 5 shows the and receiving behavior directly. It causes the SMAC to fail in
Tester help screen with a list of the commands the Tester under- sending and/or receiving packets with some probability. There-
stands. Commands to the Tester are of four types (shown in the fore, it simulates having network problems and allows testing
figure in the upper four partitions): request, content, testing and the ability of the student’s DLL to recover from lost packets.
debugging, and off-line development commands. The first two The final command in this series helps students to debug their
will be discussed here; the others will be discussed in the next DLL. When the debug command is issued, the Tester shell
two subsections. will simply call the link layer’s debug() method. Within that
Request commands, such as initRequest(), dataRe- method, students may display the contents of important internal
quest(), and termRequest(), interface directly with the state variables.
corresponding DLL request routines. These commands can be
issued multiple times back to back to test different aspects of
the DLL protocol. D. Working Off-line
Content commands are provided by the Tester shell to allow There are three commands that have been provided to assist
the students to select the content that will be sent in data requests students who work at home or elsewhere without networking
and to view the content received in data indications. facilities. The enter command allows a user to construct a
packet (destination address, header, and data length, if any) at
C. Methods for Testing and Debugging the keyboard and have the SMAC simulate its receipt from a re-
The Tester shell provides several commands to help examine mote host. Two of these commands allow creating files full of
the internal data structures during testing and to help contrive packet contents that can be read by the SMAC in order to sim-
unusual circumstances to aid in testing the limitations of a stu- ulate content being received by the local host over the network.
dent’s DLL. The file command causes a packet vector file to be read into
The first of these commands is links, which interfaces with an internal buffer. The packet command can then be used to
the link layer’s status() method. This method returns the 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 Fig. 6. Sample output from the packet Watcher. hostB initializes a link to
hostA, which acknowledges this request. Packets corresponding to these two
In this section, the authors show how the project is divided actions are shown in the verbose mode. Five simultaneous data requests are then
into milestones and how these milestones are scheduled over the made between the two hosts to test piggybacking. This action is shown in the
project period. Table III gives the schedule and grade division brief mode. Refer to Table I for expansion of abbreviations. The data contents
of each Data packet are sequential numbers from 0 to 4.
for the project. The project spans a period of half of a term (6
weeks). Related work is divided into two tutorials, two work TABLE III
sessions, a quiz, and two project demonstrations. 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 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.

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 Students’ code evaluation is divided into two demonstrations:
finally, the link is terminated. Examples show piggybacking and error recovery beta and final. During the beta stage, DLLs are only required
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 to initialize and terminate links with different scenarios. This
here since they do not affect the operation of the protocol. Traces are shown milestone helps the instructors detect students who are having
graphically. Table IV shows the same information as table entries. trouble getting started. No data requests are tested during this
demonstration. Furthermore, perfect network conditions are as-
select an appropriate number of timers to incorporate in the sumed. That is, reliability features are not tested. During the
system and determine the suitable time instance to create, start, final demonstration, students are required to present a com-
and stop them. plete implementation of the posted DLL specifications. To pre-
When the students start developing the project on their pare for both demonstrations, students are given a complete task
own, they are given the chance to ask questions through two checklist.
work sessions. During these work sessions, questions and Demonstration requirements are transformed into a set of
developing problems are brought to the lab. The instructors tasks, each worth one point. These tasks are organized in
then work closely with each individual trying to solve his or the form of a marking sheet and used to check the students’
her problem, e.g., by discussing adopted design concepts or by implementation. These marking sheets are made available
code inspection. 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
B. Quiz and Demonstrations gets the mark for the question. Example 7 shows a sample task
included in the final marking sheet and its testing script.
To ensure students understand the DLL requirements, they
Example 7: Test for receiving out-of-sequence data. Corre-
are given a brief in-lab DLL quiz early in the term. The quiz
sponding script is as follows.
is designed as a set of multiple-choice questions that is marked
in the lab. Example 6 shows a typical quiz question. Time is • Initialize a link between the two hosts A and B.
devoted for discussing quiz questions. • Set receiving reliability on A to 0.

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

• Send a Data packet from A to B. [11] J. Lewis and W. Loftus, Java Software Solutions: Foundations of Pro-
• Observe transmission of the Data packet and its DAck. gram Design, 2nd ed. Reading, MA: Addison-Wesley, 2000.
[12] Java Software. (2002, Jan.) Java 2 SDK Documentation (Ver-
• Observe retransmission of the Data packet (since A will sion 1.4.0) in Java 2 Platform Web Page. [Online]. Available:
not receive its acknowledgment, it will retransmit it). http://java.sun.com/j2se/1.4/docs/.
• 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. Mohamed Watheq El-Kharashi (S’97) received
the B.Sc. and M.Sc. degrees in computer engineering
In addition to technically marking student projects, code style from Ain Shams University, Cairo, Egypt, in 1992
and 1996, respectively. He is currently working
is also checked for such characteristics as modularity and clarity. towards the Ph.D. degree in computer engineering
with the Department of Electrical and Computer
Engineering, University of Victoria, Victoria, BC,
VIII. CONCLUSION Canada, and is working on hardware support for
Java.
In this paper, the authors have presented a lab project that He currently teaches courses in computer
teaches computer science and engineering students how to architecture, embedded systems, and computer
design, implement, and test a simple single-bit DLL protocol. networks at the University of Victoria. His research interests include advanced
microprocessor design, simulation, performance evaluation, and testability;
This DLL project provides an excellent venue for the students Java performance improvement; and computer architecture and computer
studying computer communications and networks to exper- networks education.
iment with implementation of network protocols. It offers Mr. El-Kharashi is a Student Member of the Association of Computing
Machinery (ACM), the ACM Special Interest Group on Computer Architecture
them a guided opportunity to comprehend detailed network (SIGARCH), and the ACM Special Interest Group on Microarchitecture
specifications and design a communication layer that adheres (SIGMICRO).
to the desired characteristics. Furthermore, the lab familiarizes
the students with protocol testing and debugging, using an
advanced set of methodologies and tools.
Glen Darling received the B.Sc. and M.Sc. degrees
The well-structured lab environment and support infrastruc- in computer science from the University of Victoria,
ture present an outstanding platform for the students to use to Victoria, BC, Canada, in 1984 and 1995, respectively.
experiment, maximizing the benefits from the project. Java is For more than ten years, he taught computer
science at the University of Victoria, Victoria, BC,
chosen as the project language for its suitability for network pro- Canada, while also managing the Computer Science
gramming. This selection helps students focus on major project Department lab facilities and writing software to
objectives and masks the time-consuming, low-level implemen- support the labs. In addition, for the last five of
those years, he was also the Software Architect for
tation details. The discussion in this paper is illustrated with a small computer-based training company providing
some Java code fragments. Also presented are the evaluation customized educational software, mostly for large telecommunication and
methods used to make the students follow a consistent schedule 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
that results in a high project completion rate. tools for a larger group of engineers working on Cisco’s next generation of
Finally, the reader is invited to browse through the project routers.
website [1]. The online documentation includes the detailed
project specifications, full class library notes, and user manual
for the relevant tools. Brent Marykuca received the B.Sc. degree in com-
puter science from the University of Victoria, Vic-
REFERENCES toria, BC, Canada, in 1993.
Currently, he is employed as a software engineer
[1] UVic, Computer Science 450. (2002, Jan./Feb. 15) Data Link for Art & Logic Software Engineering & Design,
Layer (DLL) project documentation in University of Victoria, Glendale, CA, where he works on developing
Computer Science 450 Lab Web Page. [Online]. Available: application and driver software for desktop and
http://www.csc.uvic.ca/~csc450/Lab/. embedded computing systems.
[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: Gholamali C. Shoja (M’82–SM’90) received the
Prentice-Hall, 1996. B.S.E.E. degree from Kansas State University,
[6] A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental Manhattan, KS, in 1961, the M.S.E.E. degree from
Concepts and Key Architecture. New York, NY: McGraw-Hill, 2000. Northwestern University, Evanston, IL, in 1964,
[7] W. Stallings, Data and Computer Communications, 6th and the Ph.D. degree in computer science from
ed. Englewood Cliffs, NJ: Prentice-Hall, 2000. University of Sussex, Brighton, Sussex, U.K., in
[8] M. Campione, K. Walrath, and A. Huml, The Java Tutorial: A Short 1981.
Course on the Basics, 3rd ed. Reading, MA: Addison-Wesley, 2001. He is currently an Associate Professor of Com-
[9] K. Arnold, J. Gosling, and D. Holmes, The Java Programming Lan- puter Science at the University of Victoria, Victoria,
guage, 3rd ed, ser. The Java Series. Reading, MA: Addison-Wesley, BC, Canada. He is also a Research Scientist with
2000. the New Media Innovation Center (NewMIC) in
[10] J. Bishop, Java Gently: Programming Principles Explained, 3rd Vancouver, BC. His area of research includes computer networks, distributed
ed. Reading, MA: Addison-Wesley, 2002. computing, and multimedia systems.

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 12:01 from IEEE Xplore. Restrictions apply.