Design of a Laboratory for an Undergraduate Distributed Systems Course
Cristina L. Abad
Facultad de Ing. en Electricidad y Computacion
Escuela Superior Politecnica del Litoral
Campus Gustavo Galindo
Km 30.5 va Perimetral
Apartado 09-01-5863. Guayaquil-Ecuador
Email: cabad@fiec.espol.edu.ec
Abstract
The instructional laboratory is an important complement
to the engineering undergraduate curriculum. In particular,
Distributed Systems courses can benefit much from using
a laboratory to provide a balanced theory+practice class.
This paper presents the design of an objective-based, in-
expensive, instructional laboratory to be used in an under-
graduate Distributed Systems course.
Keywords: distributed systems course, laboratory, lab.
1. Introduction
In our current networked world, Distributed Systems
(DS) courses are an important part of the curricula in un-
dergraduate Computer Science education [22]. Distributed
Systems courses usually teach concepts related to Dis-
tributed Systems Theory, Parallel Processing, Grid Com-
puting, Distributed Computing, Security, Peer-to-Peer and
Overlay Networks, Middleware, Web services, among oth-
ers. All of these topics may be hard to grasp for students
if the course is only lecture-based. For this reason, many
Professors rely heavily on student projects to help them de-
liver the concepts. Unfortunately, this may not be the best
approach for undergraduate students (see Section 2).
Complementing lectures with laboratory classes may be
a better way to teach Distributed Systems to undergradu-
ates, but for this to be possible, appropriate infrastructure
needs to be available to Professors and students.
The engineering education literature has highlighted
the importance of the laboratory in undergraduate educa-
tion [11, 12], but very little has been published about lab-
Submitted to the 2007 International Conference on Frontiers in Ed-
ucation: Computer Science and Computer Engineering (FECS 2007). If
accepted, the paper will be presented by Carmen Vaca.
Carmen K. Vaca
Facultad de Ing. en Electricidad y Computacion
Escuela Superior Politecnica del Litoral
Campus Gustavo Galindo
Km 30.5 va Perimetral
Apartado 09-01-5863. Guayaquil-Ecuador
Email: cvaca@fiec.espol.edu.ec
oratory instruction and design (in recent years, less than
10% of the articles published in the Journal of Engineer-
ing Education used laboratory as a keyword [32]). Even
less has been published in the area of Distributed Systems
laboratories: Searching through the 2000-2007 archives of
the IEEE Transactions in Education, ACM Journal of Com-
puter Sciences in Colleges, the Journal of Engineering Ed-
ucation of the American Society for Engineering Educa-
tion, Proceedings of the ACM SIGCSE Technical Sympo-
sium on Computer Science Education and Elseviers Jour-
nal of Engineering Education, we found just a few papers
that describe laboratory environments for DS and related
courses [1, 2, 10, 19, 27, 28, 34]. Similar results are ob-
tained if we search for papers describing laboratory assign-
ments for Distributed Systems and related areas.
This paper presents the design of a laboratory to be used
in an undergraduate Distributed Systems course. Section 2
discusses why an specialized laboratory can improve how
a Distributed Systems course is taught. Sections 3 and 4
describe the design and implementation of the lab, respec-
tively. Finally, in Section 5 we conclude.
2. Motivation
Distributed Systems courses, currently very common
in the undergraduate Computer Science curricula, usually
teach concepts related to Distributed Systems Theory [9,
19], Parallel Computing [2, 16, 17, 21], Grid Comput-
ing [16, 21, 27, 31], Distributed Computing [17, 19, 31], Se-
curity [19, 21, 34], Peer-to-Peer and Overlay Networks [19],
Middleware [5], Web services [16], among others. All of
these topics may be hard to grasp for students if the course
is only lecture-based. For this reason, many Professors rely
heavily on student projects to better deliver the concepts.
Unfortunately, this may not be the best approach for under-
graduate students.
 Distributed Systems Course
Suggestion to Improve
Other
More classroom activities
0% 10% 20%
Figure 1. Suggestions provided by 60 students who took our Distributed Systems course (Fall 2005).
After an analysis of using the lecture+project approach
to teach an undergraduate Distributed Systems course, from
2004 to 2006, we noticed that it may not be the best ap-
proach due to several reasons:
Many students rush through the machine problems
(MPs) and project and get the job done, but fail to grasp
the important concepts that these exercises aim to de-
liver.
Students tend to get lost in the details (e.g., solving
problems that arise during the MPs and project) with-
out stopping to get the big picture.
Students tend to run the distributed processes in one
computer only, and they do not benefit from the ex-
citement of seeing their system run distributely in a
network. The main reasons for this are that many stu-
dents do not have a computer network set up at home
and that our Department Computer Labslike those in
many institutions, grant access to only one computer
at a time.
When tryingand failingto solve the problems that
arise during MPs, some students lose confidence in
their abilities and sometimes lose interest in the class.
In team-based projects, it is common for a subset of the
team members to do all the work. The students that
have little or no participation in the development of
the project do not benefit from the experiences learned
while working on it. This behavior has also been ob-
served previously in other Universities [19].
Even if plagiarism is severely penalized, some students
take this path, hoping that to get away with it [7, 19].
Laboratory classes
30% 40% 50% 60% 70% 80%
Percentage of Students
The use of laboratory courses in the Engineering un-
dergraduate curriculum has been suggested as a way to
relate theory and practice and help students learn the
things that practicing engineers are assumed to already
know [12]. Specifically, in the Computer Science area,
courses like Distributed Systems can benefit greatly from
having laboratory-based classes to complement the lectures.
In our institution, 60% of the students who took a lecture-
based Distributed Systems class during Fall 2005, when
asked what could be done to improve the class, answered
that they would like to have at least one hour a week of
laboratory classes (see Fig. 1). It should be noted that the
question (What would you suggest to improve the course?
Answer can be related to content, methodology, etc.) was
completely open. The students were not given a list of pos-
sible answers, as we thought this would bias their responses
towards what we thought could be improved.
We started incorporating a few laboratory classes in our
DS course since Spring 2006, but the results were only par-
tially successful, due to the lack of an appropriate labora-
tory environment. Thus, the need for a specialized Dis-
tributed Systems Laboratory was evident. As mentioned
earlier, the design of similar laboratories has not been prop-
erly documented. Most previous work describes labora-
tories specialized for some DS area, like grid comput-
ing [2, 10, 27, 28, 34]. Kerer et al. [19] describe the de-
sign and implementation of a Distributed Systems Labora-
tory for 600 students, but their design is specifically tailored
for the ShareMe class assignment used by the authors in
their DS course.
We thus faced the problem of designing a Distributed
Systems laboratory that could be used a generalized DS
course. As has been noted in previous research [12], un-
dergraduate engineering laboratories and the consequent
2
 Percentage of courses with laboratory classes
45%

40%

35%

30%

25%

20%

15%

10%

5%

0%
1 2 3 4 5 6 7 8

Semester

Figure 2. Courses with laboratory classes at ESPOL (ECE Department) with respect to the semester
students are suggested to register for the course.

laboratory-based classes should be designed with clear ob-
jectives in mind. The following section describes the guide-
lines we followed when designing the laboratory.
3. Design of the Lab
As noted by Feisel and Rosa [12], there are three types
of Engineering labs: development, research and educational
(instructional). Our lab fits in the research and instructional
types, since our main goals were both to (1) provide support
to the teaching of DS-related coursework through enabling
hands-on experience and problem-based learning [20], as
well as to (2) provide support to undergraduate research in
Distributed Systems and Applied Internet Technologies. In
this paper, we concentrate on the first objective (instruc-
tional lab).
Before designing the lab, we identified the following ob-
jectives, adapted from the roles described by Ernst [11], to
the case of a Laboratory for an undergraduate Distributed
Systems course: First, the student should learn how to be
an experimenter in distributed systems and related areas.
Second, the laboratory should be a place for the student
to learn new and developing distributed systems issues and
concepts. Third, classes taught using the laboratory should
help the student to gain insight and understanding of dis-
tributed systems in the real world.
We also aimed to fulfill the objectives described by Kerer
et al. [19] for a Distributed Systems laboratory: provide
an attractive environment in which students learn about
network programming and apply some fundamental con-
cepts of distributed systems and [deepen] the theoreti-
distributed systems, unicast versus multicast, connection-
oriented versus connectionless communication, concur-
rency, name services, distributed objects, remote method in-
vocation, and network security) and applying them in prac-
tice.
Additionally, we took into consideration the fundamen-
tal objectives of engineering instructional laboratories de-
scribed in [12], and identified the hardware and software
requirements for the lab so that they would enable the
achievement of these thirteen objectives as follows 1 . Note
that in Sections 3.1 through 3.13, the text in italics is the
generalized description of that particular objective, as writ-
ten by Feisel and Rosa in [12].
3.1. Objective 1: Instrumentation
Apply appropriate sensors, instrumentation, and/or soft-
ware tools to make measurements of physical quantities.
The lab has software tools installed that allow students to
gather various performance data so that they can analyze
the performance of the distributed systems they run. Per-
forming this type of analysis is not a trivial task [8] and
requires knowledge of different tools and understanding of
where the problem may be (server, network, services, end-
user or content [8]). Installed on the lab machines are sev-
eral tools that can be used to make measurements and an-
alyze the performance of distributed systems, in the areas
listed before. These tools include: Big Brother [4], NetLog-
ger [15], Argus [3], Ethereal [24], TCPDUMP [29], several
of the CAIDA tools [6], among others. Students are also
1 Each of the objectives start with By completing the laboratories in

cal concepts taught in the lecture (e.g., various models of the engineering undergraduate curriculum, you will be able to.

3
allowed to obtain performance statistics from the Ethernet
switch used in the lab.
3.2. Objective 2: Models
Identify the strengths and limitations of theoretical mod-
els as predictors of real-world behaviors. This may include
evaluating whether a theory adequately describes a physi-
cal event and establishing or validating a relationship be-
tween measured data and underlying physical principles.
Several simulation utilities are available so that students
can perform simulations of their systems and obtain per-
formance results. These results can be compared with real
data obtained from the tools listed in Section 3.1. Utili-
ties installed to help support this objective include OPNET
Modeler, ns-2 [23], p2psim [25], NeuroGrid [18], planet-
sim [13], PeerSim [26] and GPS (General Peer-to-Peer Sim-
ulator) [35].
3.3. Objective 3: Experiment
Devise an experimental approach, specify appropriate
equipment and procedures, implement these procedures,
and interpret the resulting data to characterize an engineer-
ing material, component, or system.
We have designed a Web site for the lab, in which we will
publish several tutorial-based learning objects [33] that stu-
dents can perform on the lab. All the required software to
experiment with these learning objects, as well as to work
in the class MPs and project is installed in the lab. Exam-
ples of software installed include various operating systems
(Windows Vista, GNU/Linux, FreeBSD), server software
(Apache, Geronimo, DNS, SSH, MySQL, PostgresSQL,
etc.), and various development tools, APIs, frameworks,
cluster tools, among others.
3.4. Objective 4: Data Analysis
Demonstrate the ability to collect, analyze, and interpret
data, and to form and support conclusions. Make order
of magnitude judgments and use measurement unit systems
and conversions.
Some of the learning objects to be published in the lab Web
site will ask students to use the performance tools installed
in the lab to gather and analyze data.
3.5. Objective 5: Design
Design, build, or assemble a part, product, or system, in-
cluding using specific methodologies, equipment, or mate-
rials; meeting client requirements; developing system spec-
ifications from requirements; and testing and debugging a
4
prototype, system, or process using appropriate tools to sat-
isfy requirements.
Systems design and development tools like Eclipse, Visual
Studio .NET, NetBeans, and Microsoft Visio, are installed
in the lab.
3.6. Objective 6: Learn from Failure
Identify unsuccessful outcomes due to faulty equipment,
parts, code, construction, process, or design, and then re-
engineer effective solutions.
If needed, students may be granted administration privi-
leges on some of the machines (e.g., to open/block ports
on firewall, configure services, install software, etc.). For
this reason, configuration problems may arise, which could
require partial or complete re-installation of the computer
software. The lab policy manual, published in the Web site
and a mandatory read for every student taking the course,
indicates the procedure to be taken by a student that mis-
configures a computer so that the machine can be returned
to its functional state. A detailed manual is provided to such
student, indicating the steps required to re-install and/or re-
configure the computer. This manual is kept up-to-date by
the labs student assistant.
3.7. Objective 7: Creativity
Demonstrate appropriate levels of independent thought,
creativity, and capability in real-world problem solving.
The system administration privileges granted (if needed) to
students working on the final class project allows them to
use all of the available resources in the design and imple-
mentation of the project. Additionally, the machines in the
lab have hardware features that students may not have avail-
able in their home personal computers, and which they can
explore in their projects (e.g., two Gigabit Ethernet cards,
two state-of-the-art graphical cards, Intel Core 2 Duo pro-
cessor, Trusted Platform Module (TPM) microcontroller,
Integrated Intel Matrix Storage Technology (RAID), among
others).
3.8. Objective 8: Psychomotor
Demonstrate competence in selection, modification, and
operation of appropriate engineering tools and resources.
We believe the Psychomotor objective is not applicable to
the particular lab described in this paper.
3.9. Objective 9: Safety
Identify health, safety, and environmental issues related
to technological processes and activities, and deal with
them responsibly.
 Internet
IDS VLAN
University Campus Network
Lab VLAN
Figure 3. Network diagram of the Distributed Systems laboratory.
The lab policy manual indicates the appropriate use of the
computing resources of the lab so that they are handled
properly to avoid damage.
3.10. Objective 10: Communication
Communicate effectively about laboratory work with a
specific audience, both orally and in writing, at levels rang-
ing from executive summaries to comprehensive technical
reports.
The lab Web site links to a TWiki [30] in which students
are required to publish their reports and other information
related to the class. Additionally, we are working on form-
ing a Student Interest Group with students that will special-
ize in topics related to Distributed Systems and will orga-
nize workshops so that other students can learn from their
experiences. The aim of this group is to get involved stu-
dents interested in learning more about the area, increase
their knowledge, enhance their communication and leader-
ship skills, as well as to generate some income to help fi-
nance the group activities.
3.11. Objective 11: Teamwork
Work effectively in teams, including structure individual
and joint accountability; assign roles, responsibilities, and
tasks; monitor progress; meet deadlines; and integrate in-
dividual contributions into a final deliverable.
The physical layout of the lab is designed to promote and
enhance teamwork. This includes enough room for a couple
of students to work in one or two machines at a time, several
available whiteboards, etc. With respect to software, in ad-
dition to our file server, the lab has a Concurrent Versioning
System (CVS) [14] available to students working on their
class projects.
5
IDS File Server
Web Server
Application Server
Database Server
Servers VLAN
3.12. Objective 12: Ethics in the Labora-
tory
Behave with highest ethical standards, including report-
ing information objectively and interacting with integrity.
Our lab manual describes the appropriate conduct the users
of the lab must follow. It also describes penalties to be ap-
plied in case of a violation of the conduct code.
3.13. Objective 13: Sensory Awareness
Use the human senses to gather information and to make
sound engineering judgments in formulating conclusions
about real-world problems.
Although this is not a part of the lab, the DS class includes
several case studies and a class project, through which stu-
dents can enhance their engineering skills.
3.14. Other
Figure 3 shows the logical network design of the lab. It
should be noted that the lab (hardware, software, network)
has been designed so that it is inexpensive to implement.
Most of the software is free, and in the few cases of com-
mercial software, we are using educational licenses granted
to most Higher Education institutions.
4. Implementation of the Lab
Currently we have implemented a completely functional
prototype of the lab. We are working on obtaining funding
to implement the complete lab. A pilot program with a few
selected students has already shown the benefits from using
the lab. Students are enthusiastic about it, and in the mean-
time, a full class can access it remotely from any of our De-
partment labs. Additionally, small groups of students can
be granted physical access to work on their class projects.
5. Conclusion
The instructional laboratory is an important complement
to the engineering undergraduate curriculum. In particular,
Distributed Systems courses can benefit much from using
a laboratory to provide a balanced theory+practice class.
This paper presented an objective-based design of a lab-
oratory to be used in an undergraduate Distributed Sys-
tems course. The laboratory was designed so that it can be
used to enhance the student learning experience by enabling
instructor-lead laboratory classes.
Acknowledgment
The authors would like to thank the VLIR-ESPOL Program,
which provided the grant that financed the lab, the ECE De-
partment at ESPOL, which provided the physical infrastruc-
ture for the lab, and our Student Assistant, Andre Ortega,
who worked hard to make the lab possible.
References
[1] J. Adams and D. Laverell. Configuring a multi-course lab for
system-level projects. In Proceedings of the 36th ACM Tech-
nical Symposium on Computer Science Education (SIGCSE
2005), 2005.
[2] J. Adams, C. Nevison, and N. Schaller. Parallel comput-
ing to start the millennium. In Proceedings of the 31st
ACM Technical Symposium on Computer Science Education
(SIGCSE 2000), 2000.
[3] Argus, the network audit record generation and utiliza-
tion system, 2006. <http://www.qosient.com/
argus/>, last accessed March 2007.
[4] Big brother, 2006. <http://www.bb4.com>, last ac-
cessed March 2007.
[5] J. Brownsmith. Teaching and learning middleware: A
new course. Journal of Computing Sciences in Colleges,
22(3):251256, Jan. 2007.
[6] CAIDA, the cooperative association for Internet data analy-
sis, 2006. <http://www.caida.org/tools/>, last
accessed March 2007.
[7] B. Cheanga, A. Kurniaa, A. Limb, and W.-C. Oonc. On
automated grading of programming assignments in an aca-
demic institution. Computers & Education, 41:121131,
2003.
[8] B. Chen. Infrastructure for distributed system performance
tools, Aug. 2000. Presented at The University of Washing-
ton/Microsoft Research Summer Institute on Accelerating
the Pace of Software Tools Research: Sharing Infrastructure,
slides available at <http://research.microsoft.
6
com/si/presentations.asp>, last accessed March
2007.
[9] J. Cunha and J. Lourenco. An integrated course on paral-
lel and distributed processing. In Proceedings of the 29th
SIGCSE technical symposium on Computer science educa-
tion (SIGCSE 1998), 1998.
[10] W. Du, Z. Teng, and R. Wang. SEED: A suite of instruc-
tional laboratories for computer security education. In Pro-
ceedings of the 38th ACM Technical Symposium on Com-
puter Science Education (SIGCSE 2007), Mar. 2007.
[11] E. Ernst. A new role for the undergraduate engineering lab-
oratory. IEEE Transactions on Education, E-26(2):4951,
May 1983.
[12] L. Feisel and A. Rosa. The role of the laboratory in un-
dergraduate engineering education. Journal of Engineering
Education, 24(1):121130, Jan. 2005.
[13] P. Garca, C. Pairot, R. Mondejar, J. Pujol, H. Tejedor, and
R. Rallo. PlanetSim: A new overlay network simulation
framework. Lecture Notes in Computer Science (LNCS),
3437:123137, May 2005.
[14] D. Grune. Concurrent Versions System CVS, 2004.
<http://www.cs.vu.nl/dick/CVS.html>, last
accessed March 2007.
[15] D. Gunter, B. Tierney, B. Crowley, M. Holding, and J. Lee.
NetLogger: A toolkit for distributed system performance
analysis. In Proceedings of the IEEE Mascots 2000 Con-
ference (MASCOTS 2000), Aug. 2000.
[16] M. Holliday, B. Wilkinson, J. House, S. Daoud, and
C. Ferner. A geographically-distributed, assignment-
structured undergraduate grid computing course. In Pro-
ceedings of the 36th ACM Technical Symposium on Com-
puter Science Education (SIGCSE 2005), 2005.
[17] L. Ivanov. A modern course on parallel and distributed
processing. Journal of Computing Sciences in Colleges,
21(6):2938, 2006.
[18] S. Joseph. NeuroGrid: Semantically routing queries in peer-
to-peer networks. In Proceedings of the International Work-
shop on Peer-to-Peer Computing, May 2002.
[19] C. Kerer, G. Reif, T. Gschwind, E. Kirda, R. Kur-
manowytsch, and M. Paralic. ShareMe: Running a dis-
tributed systems lab for 600 students with three faculty
members. IEEE Transactions on Education, 48(3):430437,
Aug. 2005.
[20] N. Linge and D. Parsons. Problem-based learning as an ef-
fective tool for teaching computer network design. IEEE
Transactions on Education, 49(1):510, Feb. 2006.
[21] J. Mache and A. Apon. Grid computing in the undergraduate
classroom: Topics, exercises and experiences. In Proceed-
ings of the Second International Workshop on Collaborative
and Learning Applications of Grid Technology and Grid Ed-
ucation, May 2005.
[22] A. McGettrick, M. Theys, D. Soldan, and P. Srimani. Com-
puter engineering curriculum in the new millennium. IEEE
Transactions on Education, 46(4):456462, Nov. 2003.
[23] The network simulator - ns-2, 2006. <http://www.
isi.edu/nsnam/ns/>, last accessed March 2007.
[24] A. Orebaugh, G. Morris, E. Warnicke, and G. Ramirez.
Ethereal Packet Sniffing. Syngress Publishing, 2004. Soft-
ware available at <http://www.ethereal.com>.
[25] p2psim, 2005. <http://pdos.csail.mit.edu/
p2psim/>, last accessed March 2007.
[26] Peersim: A peer-to-peer simulator, 2006. <http://
peersim.sourceforge.net/>, last accessed March
2007.
[27] V. K. Saini and Q. Duan. Building an experimental globus-
based grid computing system in an university environment.
Journal of Computing Sciences in Colleges, 21(5):188188,
2006.
[28] S. Sivakumar, W. Robertson, M. Artimy, and N. Aslam. A
Web-based remote interactive laboratory for internetwork-
ing education. IEEE Transactions on Education, 48(4):586
598, Nov. 2005.
[29] TCPDUMP public repository, 2006. <http://www.
tcpdump.org/>, last accessed March 2007.
[30] TWiki Enterprise wiki & collaboration platform, 2007.
<http://twiki.org/>, last accessed March 2007.
[31] R. Walters, D. Millard, P. Bernnett, D. Argles, S. Crouch,
L. Gilbert, and G. Wills. Teaching the grid: Learning dis-
tributed computing with the m-grid framework. In Pro-
ceedings of the World Conference on Educational Mul-
timedia, Hypermedia & Telecommunications (ED-MEDIA
2006), 2006.
[32] P. Wankat. Analysis of the first ten years of the Journal of
Engineering Education. Journal of Engineering Education,
93(1):1321, 2004.
[33] D. Wiley, editor. The Instructional Use of Learning
Objects. Association for Instructional Technology and
Association for Educational Communications and Tech-
nology, 2001. Online Version available at <http:
//www.reusability.org/read//>, last accessed
March 2007.
[34] A. Yang, K.-B. Yue, M. Liaw, G. Collins, J. T. Venkatraman,
S. Achar, K. Sadasivam, and P. Chen. Design of a distributed
comptuer security lab. Journal of Computing Sciences in
Colleges, 20(1):332346, 2004.
[35] W. Yang and N. Abu-Ghazaleh. GPS: A general peer-to-
peer simulator and its use for modeling BitTorrent. In Pro-
ceedings of 13th Annual Meeting of the IEEE International
Symposium on Modeling, Analysis, and Simulation of Com-
puter and Telecommunication Systems (MASCOTS 2005),
Sept. 2005.