Computer Network Protocol Lab

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 communications 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 integrates 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 discussion of related educational issues. Index Terms—Computer communications and networks education, data link layer (DLL), network architecture, network protocols, 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 engineering 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 architecture that consists of a physical layer, a data link layer (DLL), and an application layer. Provided with application and physical layer software, students design and implement the logical link control software to interface between these two layers according 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 simulated 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: [email protected]). G. Darling is with Cisco Systems, San Jose, CA 95134 USA (e-mail: [email protected]). B. Marykuca is with Art and Logic Software Engineering and Design, Glendale, CA 91203 USA (e-mail: [email protected]). G.C. Shoja is with the Department of Computer Science, University of Victoria, Victoria, BC V8W 3P6, Canada (e-mail: [email protected]). Publisher Item Identifier S 0018-9359(02)05048-3.

The software implemented by students compensates for those communication errors not handled by the SMAC (or those introduced for testing purposes). That is, the SMAC can simulate unreliable packet transmission by the physical layer by randomly discarding packets. It is up to the student’s DLL software to account for the possibility that some packets may be lost. The application code (the Tester) acts as a client of the student’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 implement are discussed in Section IV. Section V presents the environment in which the project is developed. The variety of tools students use to develop their projects are summarized in Section 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 software, layered architecture of different reference models, functionalities 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

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

(a)

(b)

277

(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 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 abstraction of an Ethernet LAN, i.e., the OSI media access control sublayer. 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 features other than if it gets there, it gets there uncorrupted. Moreover, 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 communication, the DLL must compensate for specific communication errors not handled by the SMAC (or introduced for testing purposes). Packet loss is the primary communication error in this project. Finally, the Tester assists the lab instructors in evaluating 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

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 students 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 mentioned 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.

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 interface 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 = 1; ... // other constant definitions public abstract RequestReply initRequest(InetAddress addr); ... // other API method prototypes }

To gain access to DLL services, the Tester instantiates the Java class representing the link layer. Requests are made by making method invocations to DLL request routines. Each request method returns a data structure that contains information about the status of the request. If the request was rejected for some reason, the returned value will contain a result code explaining the reason for the rejection. If the request was accepted, 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 each request and also to identify to which request a particular confirmation packet applies. Example 2: The following code shows an example of a link layer request routine: public RequestReply termRequest(InetAddress addr) { if (getExistingLinkNo(addr) == -1) return (new RequestReply(RequestReply.kNonRequest, RequestReply.kNoSuchLink)); ... other request validations ... queue request for later processing incrementRequestId(); return(new RequestReply(getNextRequestId())); }

Communications from the DLL to its client are in the form of events, which can be either solicited or unsolicited. A solicited event (or confirmation packet) is the result of making a DLL request. It is the way in which the client receives status information about the requests it has made. Unsolicited events (or indication packets) are the result of remote hosts communicating with the DLL. In the course of the client’s processing, it must make occasional invocations to a DLL access routine, which informs it of any confirmations or indications posted by

Fig. 2.

Different kinds of communication service primitives.

the DLL. That is, the client gets its packets by polling the DLL rather than via interrupts. The response primitive is not used in this project. Example 3: The following Tester code shows how events are dispatched from the link layer: if(theDLL.eventAvailable()) { LinkEvent e = theDLL.getEvent(); .. process the Event ... } The link layer queues and dequeues events as follows: Vector eventQueue = new Vector(); ... eventQueue.addElement(new LinkEvent(remoteAddress, LinkEvent.kInitConfirmation, eventRequestId,LinkEvent.kNoError)); Event dispatching methods could be defined in the link layer class as follows: public boolean eventAvailable() { return !eventQueue.isEmpty(); } public LinkEvent getEvent() { return (LinkEvent) eventQueue.remove(0); }

From the other side, the DLL has access to sending and receiving services provided by the SMAC. Sending is done via a method invocation, whereas receiving is done by polling the SMAC. Fig. 3 shows a diagram of the overall software architecture of the system within which the student’s DLL will be incorporated. It identifies the key methods in the API and some key components of the class library that will be used in implementing the DLL. The Tester is the entity that holds the system control. It periodically transfers control to the DLL by invoking the link layer’s process() method. The specifications do not require this 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 acknowledgments be piggybacked on outgoing data packets. That is, acknowledgments 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

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 communication services, the DLL also provides the ability to carry on several 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.

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 communication 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 connections with upon the client’s requests to terminate the current 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 acand are indeknowledgment numbers belong to the set 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

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 DLL PACKET FORMAT

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 students from details that are not directly related to the DLL protocol. C. Simulated LAN

TABLE II SUPPORTED PACKET TYPES

the general format summarized in Table I. Each packet has a particular 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 summarizes 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 development 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 network from the engineering network gives the students complete freedom in developing their projects without worrying about flooding the engineering network with excessive packets. Students can log in to the lab gateway from home through remote shells to run their own network stack on a number of machines

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 network without interference, a different multicast group is constructed for each student. Unique multicast groups could be constructed 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 multicast 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 listener 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 following 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

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 application 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 appropriately acknowledged by the remote machine. There is also a Packet class that serves as a receptacle for data being communicated with the SMAC. A Utility class containing miscellaneous 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 development, 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 understands. 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(), dataRequest(), 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 student’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 transmission 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 command, 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. Therefore, 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 remote host. Two of these commands allow creating files full of packet contents that can be read by the SMAC in order to simulate 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 debugging 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 verbose mode–the mode most used—in which all of the packet contents 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. Complementing the online documentation, these tutorials are designed to provide insights about the project specifications. Discussion 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 this tutorial, a working version of the project is presented to the students to give them a feeling about how the project should work. At the same time, development tools are discussed and demonstrated. Both tutorials aim at clarifying the project requirements and give the students a structured task list. During tutorials, examples are provided to clarify different concepts. Trace examples are excellent teaching aids. Examples can be shown in the form of vertical time-line diagrams (Fig. 7) or in a form of tables showing requested services, exchanged packets, and resultant events (Table IV). Challenging

examples are also discussed to trigger deep thinking by students (Example 5). Example 5: Consider this case: Host A sends (DATA,0,1) to host B. B replies with (RBUSY,0,0)to A then sends it (DATA,0,1). Write out the remaining packet exchanges. Tutorials are done in a discussion format with input from students. Different design options are highlighted with pros and cons for each. For example, other alternatives to the shell module in Fig. 4 are investigated to justify using multiple request queues. Another example deals with timers. Tutorial 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) 2) 3) 4) 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.

Receipt of a duplicate Data packet. Receipt of a Term packet. Receipt of a duplicate Init packet. 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 assumed. That is, reliability features are not tested. During the final demonstration, students are required to present a complete implementation of the posted DLL specifications. To prepare 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. Corresponding script is as follows. • Initialize a link between the two hosts A and B. • 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. • 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 acknowledge then discard it. That is, no indication should be reposted 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 experiment 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 infrastructure 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 programming. This selection helps students focus on major project objectives and masks the time-consuming, low-level implementation 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 Applications, 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 Language, 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.

[11] J. Lewis and W. Loftus, Java Software Solutions: Foundations of Program Design, 2nd ed. Reading, MA: Addison-Wesley, 2000. [12] Java Software. (2002, Jan.) Java 2 SDK Documentation (Version 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 computer science from the University of Victoria, Victoria, 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 Computer 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.

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