Content uploaded by Surendar Chandra
Author content
All content in this area was uploaded by Surendar Chandra
Content may be subject to copyright.
Beacond: A Peer-to-Peer System to Teach Ubiquitous
Computing
Surendar Chandra
Department of Computer Science and Engineering
University of Notre Dame
Notre Dame, IN 46556
surendar@cse.nd.edu
Abstract
This paper describes a peer-to-peer (p2p) system (beacond)
that is suitable for teaching important concepts in ubiqui-
tous computing. The system exposes issues in peer location,
p2p services, security and privacy issues. The system pro-
vided enough background to compliment class lectures and
assisted students in designing their own course projects. Stu-
dents continue to explore ideas exposed by beacond; some of
these ideas are being further developed for publication in re-
search conferences [1]. We present our experiencesin using
this framework for three different course offerings.
Categories & Subject Descriptors
K.3.2 [Computer and Information Science Education]:
Computer science education
General Terms
Design, Experimentation
Keywords:
Ubiquitous Computing, Computer Networks
1 Introduction
Mobile devices (e.g. laptops, PDAs) using wireless network
technologies offer a stepping stone to build ubiquitous and
pervasive computing applications. Ubiquitous computing
is a popular course being developed in several institutions
to introduce the systems research issues in a connected fu-
ture. This new course offering is designed to give students
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, or republish, to post on servers orto redistribute
to lists, requires prior specific permission and/or a fee.
SIGCSE’03, February 19-23, 2003, Reno, Nevada, USA.
Copyright 2003 ACM 1-58113-648-X/03/0002...$5.00
hands-on training in building and evaluating emerging sys-
tems through course projects.
The ubiquitous computing field is still in its nascent stages;
course materials are typically designed around topical re-
search papers. This course is built on the student’s under-
standing of core operating systems and networking back-
ground. Even though this course is usually taught at an
advanced graduate level, we adopted this topic for a senior
undergraduate level class. The challenge in designing this
course was to provide an hands-on introduction to our un-
dergraduates who may not have the necessary background
of a more advanced graduate class. A significant portion of
our student population were active users of applications such
as napster and gnutella. Hence, we wanted to leverage their
familiarity with these applications to provide a hands-on ex-
perience with the ubiquitous technologies. Some of the fun-
damental ubiquitous computing technologies that we wanted
to introduce to the students include:
•Location management: Locating other devices is usually
the first step in accessing service provided by other de-
vices. System entities need to be named first before being
able to locate them. For example, in the cooltown project
[2] beacons are identified using web urls. Cooltown uti-
lized techniques such as direct and indirect sensing to an-
nounce the web presence of beacons.
•Remote services in a partitioned p2p setup: The ubiq-
uitous devices provide a wide range of services to other
devices that are in the vicinity.Typical ubiquitous devices
utilize technologies such as IrDA (www.irda.org), Blue-
tooth (www.bluetooth.org) and offer limited range con-
nectivity options to contact and receive services from
nearby neighbors. For example, a printer might print a
document from a PDA using a IrDA link. The range of
these devices restrict the devices that can directly talk to
each other. However, requests can be routed through other
connected devices.
•Security: Security and privacy issues play an important
role in allowing these connected devices to provide ser-
vices to their connected peers. Unauthorized accesses are
B1 B2 B3
Network Partition 1 Network Partition 2
Figure 1: Beacond Architecture
especially an important problem for mobile devices that
communicate with unknown neighbors.
Our goal was to develop a simple project that, not only com-
pliments the class lectures for new technologies but also al-
low the students to further explore the techniques discussed
in class. We wanted the system to provide basic infrastruc-
ture so that students can build further interesting services and
applications. Our experience suggests that the system in fact,
allowed students to further develop several application sce-
narios based on the technologies developed in this projects.
The remainder of the paper is organized as follows: we de-
scribe the general architecture of our beacond architecture
in Section 2. Section 3 describes four project ideas and our
experience in using them with a senior level undergraduate
class. Section 4 outlines some ideas on how this architecture
can be exploited to teach related courses such as computer
networks and distributed systems. We present our conclu-
sions in Section 5.
2 System Architecture
The beacond system was designed to be general enough to
expose students to issues in location management, remote
service discovery and security; while still amenable to stu-
dents with limited systems exposure. The beacond archi-
tecture was influenced by research prototypes such as active
badges [5], bayou [4] and cooltown [2].
The general system architecture is illustrated in Figure 1.
The system consists of a number of beacons. Beacons are
software representations of physical entities. For example,
beacons can represent LCD projectors, people, microwave
ovens, etc. Depending on the underlying network topology,
not all beacons can communicate with every beacons. For
example, in Figure 1 we note that, beacon B1 does not know
about beacon B3 directly. Beacons B2 knows about all the
other beacons directly because it belongs to both the network
partitions 1 and 2. Each beacon provides certain services.
For example, a printer beacon can print documents; an mp3
player can consume as well as provide mp3 files for sharing.
Since beacons do not know about all other beacons; location
and service queries have to be routed through other beacons.
Care has to be taken in reducing the effects of such query
flooding. Beacons should also make sure that service is only
provided to the appropriate peer for auditing and access con-
trol purposes.
3 Our experience
We have used our infrastructure for 3 different course offer-
ings, twice for “Ubiquitous Computing” and once for “Com-
puter Networks”. For our class, we assigned four small in-
dividual projects based on the general system architecture;
each of two weeks in duration. Each project built on tech-
niques developed in earlier projects; with reference imple-
mentations for the past projects provided. Students were free
to choose a programming language of their choosing; stu-
dents chose Java, C, C++ and Perl running on Linux, Win-
dows and Solaris platforms for their implementations. Stu-
dents used the knowledge gleaned from these projects to de-
sign their own group course project. For all the projects, the
students chose their own implementation strategy. The stu-
dents were required to provide a written report explaining
their particular approach and the interoperability and scala-
bility tradeoffs.
In this section, we describe how the general beacond ar-
chitecture described in the previous section was applied for
our class projects. We present our experiences from student
feedback. We also report our experience with the influence
these projects had on students’ final course project. Next we
will describe the four projects assigned in our class:
3.1 Locating beacons
The goal of this project was to locate beacons that were cur-
rently online and accessible. Beacons identify each other by
exchanging their name, the Internet address and port num-
ber where the beacon can be reached. In general, there are a
number of different ways for beacons to identify other bea-
cons. Some popular techniques are:
1. Central Server: This approach utilizes a centralized
server that keeps track of beacons that are online. Every
beacon registers itself with this server. One would query
this central server to search and locate other beacons. Bea-
cons have to first know where this central server is located
before they can locate other beacons (boot-strap problem).
Beacons can keep this centralized location information
updated using periodic updates initiated by the beacons
or periodic polling queries from the central server.
2. Peer-to-peer: Here the beacons directly locate other bea-
cons without any centralized data structures. Beacons can
utilize multicasting (all beacons listen on the same mul-
ticast channel) or broadcasting to identify other beacons.
Beacons can broadcast a query asking other beacons to
identify themselves or new beacons can initially broadcast
their identity in order to join the community.
The students were required to provide a written report ex-
plaining their particular approach to locate other beacons;
how they solved the boot strap problem in a centralized ap-
proach or how they identified beacons outside the multicast
range. They were also required to discuss the implications
of their approach on interoperability (how the beacons rec-
ognizes beacons in a different host/operating system?), scal-
ability (in case their beacon system becomes wildly popu-
lar (ala napster), can the system handle tens of millions of
beacons?) and consistency (how quickly do beacons realize
when a beacon crashes so that the results accurately reflect
the beacons that are currently online?)
Discussion This project allowed students to catch up on
their networking fundamentals; the project was conceptually
simple enough that most students were able to utilize sample
networking code from popular textbooks to build their sys-
tem. Most students preferred the centralized approach; some
adventurous students chose complex hierarchical multicast-
based approaches. In order to level the playing field, we
forced the students to uniformly use the p2p approach during
the second iteration of the course offering, while increasing
the assigned time. The students did not report significantly
more difficulty with this p2p approach.
3.2 Accessing Remote Services
This project built on the earlier project (Section 3.1, locate
other beacons that are currently online and accessible). Bea-
cons knew where the other beacons were and how to com-
municate with them (the Internet address and port fields were
exchanged as part of the location process). The goal of this
project was for the beacons to provide a simple service. De-
pending on the object that a beacon is attached to, beacons
can provide any number of different services. For example,
a beacon attached to a printer can advertise the printers ca-
pabilities (postscript/PCL, color/grayscale etc), accept jobs
for printing and provide status information (printer jam, out
of paper, etc.). A more complex beacon can make requests
to other beacons to accomplish its tasks. For example, the
printer beacon can contact a clearinghouse to charge the user
for the printing costs.
For our project, the beacons provided a service that will list
and serve files on the Internet address and port exchanged
as part of the location exchange. The beacons provided the
following services:
•open(key): Beacons need a mechanism to authenticate
and create an association with a particular beacon. Hence,
all requests to a beacon were preceded by the open() func-
tion. For this project, we assumed that any key is valid.
The beacons responded with a token that identified a par-
ticular session. Further requests to this beacon should be
accompanied with this token for service. Requests without
a valid token are denied.
•list(token),get(token, file),put(token, file): These ser-
vices list all the files that were available at the beacon,
download the contents of the requested file as well as up-
load the contents of the file, respectively. The students
were free to choose the specific files serviced. Care must
be taken to make sure that the files serviced with a get()
request was among the files listed in the list() service. Re-
quests for a file that is not available should be denied.
•close(token) This service will end the session with this
particular beacon.
In fact, the beacons provide a rudimentary service for file
exchange; similar to the services provided by systems such
as gnutella, napster etc. As usual, the students reported
their own implementation strategy and the implications of
their approach on: robustness: (how reliable was the system
against failures? If a beacon crashes and came back online
immediately, can the system continue to provide service to
existing clients?) scalability: (if the beacon suddenly be-
comes popular because of the files services, how much load
can the system tolerate before the system crashes? Does the
service degrade gracefully? Is the system immune to denial-
of-service attacks?) and security: (how secure is the sys-
tem regarding key management? If a beacon opens a session
with another beacon and passed the session token to a friend,
would they be able to utilize the key to access files? Can a
beacon access files not listed by the list() service?)
Discussion This project built on students’ experience in
building network applications from the previous project.
Many students preferred a centralized approach as it was
deemed easier to implement and debug. Students frequently
ran into buffer overflow and other common errors that al-
lowed service to unlisted files. Similarity of this project to
popular p2p applications such as gnutella and napster piqued
students interest enough to develop fancy GUI extensions to
improve the ease of using the system. This project also as-
sisted the instructor in explaining mobile replications sys-
tems such as Bayou [4] and Coda [3].
3.3 Services in a partitioned network
The first two projects located other beacons that were online
as well as provided a simple file service. The next step was
the ability to access files that were available in beacons that
were not directly known to the current beacon. Such agent
applications can be built on top of a centralized or distributed
implementations to locate other beacons. Beacons utilizing
p2p approaches did not require any special modifications to
locate beacons in a partitioned network. However, beacons
using a central server based approach for locating other bea-
cons were extended to be able to communicate with at least
two different central servers.
12
64
3
S1 S2
5
Figure 2: Beacons that can communicate with multiple cen-
tralized beacon location servers
An extended central server based approach utilizing two cen-
tral servers is illustrated in Figure 2. In this scenario, bea-
cons 1 and 6 communicate exclusively with beacon loca-
tion server S1, beacons 3 and 4 communicate exclusively
with beacon location server S2, while beacons 2 and 5 can
communicate with both beacon location servers S1 and S2.
Using the modified central server based approach, beacon
1 knows that beacons 1, 2, 6 and 5 are online. However,
beacon 2 knows that beacons 1, 6, 5, 3 and 4 are online by
communicating with beacon location servers S1 and S2.
In this project, we extended the beacon service mechanism
to allow beacons to request service from beacons that are
not directly accessible. For example, beacon 1 can access
files serviced by beacon 4 (even though beacon 1 does not
directly know that beacon 4 is online). This extended serving
mechanisms allows the beacons to search for services, even
while the network is partitioned (as long as there is some
path from the source to the destination).
The goal of this project was to extend the beacon service to
access files in beacons that were not directly accessible to
them. The services provided by beacons was extended as
follows:
•searchget(token, serviceFile, hopCount) If the re-
quested file serviceFile was available in the particular bea-
con, the contents of the file was sent back. If the file ser-
viceFile was not available, a recursive searchget() is initi-
ated by the beacon (on behalf of the requestor) on all the
beacons that it knows of. The search was bounded by the
hopCount. Every such forwarding decrements the hop-
Count. Once the hopCount reaches 0 without successfully
finding the file, the search returns an error message.
The students chose their particular search strategy. For ex-
ample, in the scenario illustrated in Figure 2, suppose beacon
1 is searching for file hw1.tar available in beacon 4. Bea-
con 1 can issue a searchget(token, ’hw1.tar’, 5) to beacons
2, 5 and 6. Each one of them in turn, request hw1.tar from
their neighbors till the file is located in beacon 4. Note that
the particular implementation might return multiple copies
of the same file. It might also return an FileNotFound er-
ror, even though there is a path available from the source to
the destination. For example, suppose beacon 1 requested
searchget(token, ’hw1.tar’, 3), the request might get for-
warded to beacons 2, 5 and 6 to return an FileNotFound error
message (hopCount becomes 0), even though a route through
beacons 2 and 4 is feasible and could have returned the re-
quested file.
As usual, the students were free to choose their own imple-
mentation strategy. The students were required to provide
a written report explaining their particular implementation
strategy with regard to robustness (how reliable was the sys-
tem against failures? Does the system recognize forwarding
loops? (wherein the requests are forwarded around in a loop
without making progress towards the destination)) and scal-
ability (does the service degrade gracefully? Was it immune
from denial-of-service attacks?)
Discussion This project was significantly more complex
than the earlier projects. Students had more trouble success-
fully completing the project. However, the project sparked
plenty of questions regarding the implications of such p2p
searches on performance and security during the correspond-
ing class lectures. The project formed a nice backdrop
to lectures on distributed authentication and authorization
schemes.
3.4 Security
Throughout the first three projects, beacons provided a
mechanism for identifying themselves using a name:key
pair. When a beacon logged into the system, it provided its
name:key pair. On successful validation of this authentica-
tion key, a beacon is provided with an authorization token.
This token was used for all further transactions.
In this project, the students provided an simple authorization
service. They developed a key server that took the name:key
pair to issue an authorization token. Each token was valid
for a fixed time interval. The key server was also used to
validate an authorization token. The beacons provided a new
service that will utilize one or more key servers to validate
authorization tokens. Such validation could allow beacons
to selectively provide service to certain clients.
Key Service The key service provided simple authentica-
tion service. The key server provided authentication func-
tionality to other beacons and hence need not provide an API
for end user interactions. The students implemented the key
server either as a single server or utilized p2p technologies
to provide a robust key service mechanism. The key service
provided the following functionality:
•authenticate(name, key) The key server authenticated
the name:key pair and returned an authorization token.
Each token was valid for a fixed time interval (set to 30
seconds for ease of testing).
•validate(token) The key server validated the authentica-
tion token and returned the name that was used to create
this token. The key server should return an error message
for invalid or expiredtokens.
•revoke(token) The beacons can revoke() and invalidate
tokens even before they expire. For example, a beacon
can revoke() a token after the requested file was received,
freeing up resources on the key service.
Beacon extensions The beacons were extended to utilize
the authentication key service to implement the authentica-
tion primitives outlined in the first three projects (get(),put(),
close() and searchget() services). Hence, services that used
to work might fail because of an expired or an invalid token.
For this project, the beacons were also extended to provide
the following service for ease of testing:
•validate(token) The beacons utilized the key service to
validate() a token. The beacon printed the name asso-
ciated with the token or an error message for invalid or
expired tokens.
As usual, the students were required to provide a written re-
port explaining their particular approach. They were also
required to discuss the implications of their approach on ro-
bustness and scalability issues.
Discussion This project benefited from corresponding
class lectures on authentication and authorization issues for
ubiquitous information access. In fact, based on the prior
experience with the first three projects, several students ac-
tually suggested the general idea for this project. Prior to this
project, the consistent complaint from students was the ap-
parent lack of detailed security in typical ubiquitous comput-
ing prototypes. This project helped drive the ideas of trusted
computing bases and the need for end-to-end authorization
through companion lectures. Students learnt to appreciate
the fact that end-to-end security is much more complex than
simple authentication.
3.5 Overall experience
In general, we found these projects better complemented the
class lectures. For their own course projects, the students fur-
ther developed several application scenarios that exploited
the beacond system for realistic applications. The parallels
between beacond and popular p2p systems such as gnutella,
napster etc. piqued students interest in further understand-
ing those technologies. Some of the students are exploring
research issues identified by the beacond infrastructure.
4 Future Educational Use
We believe that the technologies exposed by beacond system
can be utilized in the instruction of courses such as com-
puter networks and distributed systems. The p2p nature of
beacond lends itself to teaching mobile and ad-hoc scenarios
in computer networks. For our course, the project benefited
from similarity to popular p2p applications. Such interest led
the students to go beyond the stated project requirements to
think of better ways to implement, say napster, while achiev-
ing the instructors teaching goals for this course. We believe
that this enthusiasm would translate to similar positive re-
sults for related systems courses.
5 Conclusions
In this paper, we describe a distributed p2p system that was
utilized to compliment class lectures in topics in ubiquitous
computing. The system provided hands on experience to im-
portant system technologies. The system allowed students
to further develop several application scenarios basedon the
technologies developed in this projects. We also feel that this
system has further applicability in teaching related systems
courses such as computer networks and distributed systems.
The reference code and project descriptions will be available
online at the instructors’ course web page.
Acknowledgments
We wish to thank the students for their valuable comments
and feedback. Beacond was developed while the author
was a faculty at the University of Georgia, Athens, GA. We
would also like to thank Norma Brown for her helpful in-
sights.
References
[1] Collins, E., and Chandra, S. Ringnet: A generalized
scheme to maintain path-connected topology in dynamic
p2p networks. (in preparation), 2002.
[2] Kindberg, T., Barton, J., Morgan, J., Becker, G.,
Caswell, D., Debaty, P., Gopal, G., Frid, M., Krishnan,
V., Morris, H., , Schettino, J., Serra, B., and Spasojevic,
M. People, places, things: Web presence for the real
world. In Workshop on Mobile Computing Systems and
Applications (WMCSA) (Monterey, CA, Dec. 2000).
[3] Satyanarayanan, M., Kistler, J. J., Kumar, P., Okasaki,
M. E., Siegel, E. H., and Steere, D. C. Coda: A highly
available file system for a distributed workstation envi-
ronment. IEEE Transactions on Computers 39, 4 (Apr.
1990).
[4] Terry, D. B., Theimer, M. M., Petersen, K., Demers,
A. J., Spreitzer, M. J., and Hauser, C. H. Managing up-
date conflicts in a weakly connected replicated storage
system. In Proceedings of the 15th SOSP (Dec. 1995).
[5] Want, R., Hopper, A., Falcao, V., and Gibbons, J. The
active badge location system. ACM Transactions on In-
formation Systems 10, 1 (Jan. 1992), 91–102.
