Octopus: An Upperware based system for building personal pervasive environments

Oe

FL

a

ARRAA

KSOP

1

twEbb

tdTnc

pWtrti

T

(

0d

The Journal of Systems and Software 85 (2012) 1637–1649

Contents lists available at SciVerse ScienceDirect

The Journal of Systems and Software

journa l homepage: www.e lsev ier .com/ locate / j ss

ctopus: An Upperware based system for building personal pervasivenvironments�

rancisco J. Ballesteros ∗, Enrique Soriano, Gorka Guardiolaaboratorio de Sistemas, Universidad Rey Juan Carlos, Madrid, Spain

r t i c l e i n f o

rticle history:eceived 31 January 2011eceived in revised form 31 January 2012ccepted 6 February 2012vailable online 15 February 2012

eywords:

a b s t r a c t

As of today, there is no operating system suitable for pervasive computing. Such system must integrateand coordinate heterogeneous devices and systems but, at the same time, it should provide a single systemimage to let the user feel that there is only a single “pervasive” computing environment. Such illusionmust consider the Internet as the system backbone, because users move. The challenge is providing anovel system while permitting the seamless integration of traditional legacy systems, which may berequired to run on many computers and devices, if only to run their applications. We argue that to build

mart spacesperating systemservasive computing

such a system, we should abandon Middleware and use a different technology, that we call Upperware.To back up our claim, we have built an actual system using Upperware: the Octopus. The Octopus hasbeen in use for several years both to build pervasive applications like smart spaces and to provide ageneral-purpose computing environment. We have been using it through wide area networks, on a dailybasis. In this paper we discuss the Upperware approach and present the Octopus as an actual system built

ng so
out of Upperware, includi
. Introduction

If Weiser’s vision (Weiser, 1995) is to come true, users must feelhat they are using a “personal pervasive computer”, no matterhich devices they might be using or where they are in the world.

ach user must be provided with the illusion of using a single, invisi-le, personal virtual computer, even while overseas and when usingorrowed devices and computers.

However, today users must face a myriad of heterogeneous sys-ems and services, even if we consider research systems built toate. The work described here is intended to address this issue.hat is, we aim at a single-system image, which is a very conve-ient abstraction to develop services and applications for pervasiveomputing.

We treat the terms “pervasive computing” and “ubiquitous com-uting” as synonyms, like other authors do (Satyanarayanan, 2002).e define a Personal Pervasive Environment as a personal dis-

ributed computer environment in which a user is able to use her
esources no matter which machine exports them, the location ofhe machines, and the location of the user. Resources considerednclude (i) devices (e.g. printers, cameras, or speakers), (ii) data (e.g.
� This work is supported in part by grants CAM CLOUDS S2009/TIC-1692 and MCyTIN-2007-67353-C02-02.∗ Corresponding author.

E-mail addresses: [email protected] (F.J. Ballesteros), [email protected]. Soriano), [email protected] (G. Guardiola).

164-1212/$ – see front matter © 2012 Elsevier Inc. All rights reserved.oi:10.1016/j.jss.2012.02.011

me evaluation results.© 2012 Elsevier Inc. All rights reserved.

data files or system properties), and (iii) applications (e.g. desktopapplications, viewers, or browsers). We use the term “smart space”to describe a physical space surrounding the user (a room or a build-ing) provided with infrastructure such as sensors, actuators, andcomputers, perhaps embedded, which integrate the physical spacewith the computing facilities.

Our interest is to build a system capable of being used asa general-purpose (pervasive) computer. Otherwise, users wouldperceive two separate worlds: a pervasive environment equippedwith some interesting services like location, etc., and the actualcomputer they use to do the real work on a daily basis. This breaksWeiser’s vision. We wanted both environments to become one andthe same and, as a result, we have built a system: The Octopus.The Octopus is the system running the smart space that we builtat our office (and part of our homes) as well as it is the system weuse for the daily job (including developing software and writingthis paper). We are not claiming that the system we built solves allproblems present in pervasive computing. It only introduces a newway for providing and using services and makes the user feel thatthere is a single, uniform, pervasive computing environment.

Much research has been done in this area. In general, we couldsay that there are two different approaches to provide servicesneeded for building pervasive applications: providing them usingMiddleware, e.g. Roman et al. (2002), and modifying the native OS
to provide them, e.g. Ballesteros et al. (2007b).
• The former approach (using Middleware) has the problem thatapplications must be able to use Middleware-provided services

dx.doi.org/10.1016/j.jss.2012.02.011

http://www.sciencedirect.com/science/journal/01641212

http://www.elsevier.com/locate/jss

mailto:[email protected]



dx.doi.org/10.1016/j.jss.2012.02.011

1 ystems and Software 85 (2012) 1637–1649

•

woUnbvatMMp

fiteoifiNa

ttWivasmtcrb

itsfihIw

ja

638 F.J. Ballesteros et al. / The Journal of S

to exploit the new capabilities of the environment (know theirlocation, handle context, etc.). It has the good property that anyexisting system may be left intact, yet the Middleware can inter-operate. But applications need to be rewritten or learn to usenew services. For example, in Roman et al. (2002), Middlewareoperates on native applications to integrate them into a pervasiveenvironment, but existing legacy applications can hardly exploitthe new services introduced.The later approach (modifying the underlying OS) has theproblem that existing conventional systems require serious mod-ifications, even in the best case. Taking Ballesteros et al. (2007b)as an example, it does provide a uniform environment for nativeapplications; but it also requires running a new native OS in mostcases.

We argue in favor of a middle way: using Upperware. Upper-are is software that provides new services and executes on topf conventional OSes, like Middleware does. Unlike Middleware,pperware provides the new services directly to the OS, and doesot have other software layers on top of it. That is the key differenceetween Upperware and Middleware: new services are not pro-ided just to a set of brand new applications, but to the OS itself;nd therefore, to both new and legacy applications. Applicationshat rely on Middleware services normally have to be aware of the

iddleware and interact directly with it using APIs chosen by theiddleware provider. When using Upperware, an application never

erceives that there is Upperware behind a given service.

Upperware preserves the native system interfaces used by appli-cations while retaining the portability and interoperability ofMiddleware, which makes it perfect to provide services for per-vasive computing.

Our implementation of Upperware is based on synthetic networklesystems. A synthetic filesystem, also known as virtual filesys-em, is a program with a file-oriented interface (Killian, 1984; Piket al., 1990). Data read from a virtual file is dynamically generatedr synthesized on demand. Data written to a virtual file is dynam-cally processed by its file server. Because resources seem to beles, all applications (even legacy ones) are capable of using them.o changes are required for applications to use the new services,s known since UNIX (Killian, 1984) and Plan 9 (Pike et al., 1990).

In this paper we discuss the Upperware approach and a systemhat we have built, the Octopus, which is made out of Upperware. Inhe Octopus, each user is given a dedicated computer “in the cloud”.

e call it the PC (Personal pervasive computer). All resources ofnterest for the user (devices, application services, etc.) are pro-ided through file interfaces by the machines involved; such filesre made accessible to the PC using the network. The resulting namepace of resources, assembled on the PC, is made available to theachines the user interacts with. These machines are known as

erminals. All access is centralized in the PC. Therefore the PC is aentral point of failure. This can be overcome with different, knowneplication techniques (see for example Saito and Shapiro (2005)),ut this problem is out of the scope of the present paper (Fig. 1).

The organization of the system is user-centered in order to maket scale. It is in effect a single user system, which does not meanhat the Octopus (for a user) cannot interact with other Octopusystems, owned by other users. The Octopus uses a novel networkle protocol, Op, capable of supporting network links with veryigh latency, which permits users to integrate any resource on the

nternet into the PC. This permits the Octopus to operate world-
ide.
The resulting system is quite different from any other, asustified later. There are many systems addressing a particularpplication type and even ad hoc solutions that have existed for a

Fig. 1. Middleware vs. Upperware.

long time (e.g. remotely controlling X10 home automation devices(Introduction, in press) or playing a remote CD from our favoriteEmacs editor). But things are quite different when what we want isa system providing a uniform interface for all resources of interest,and not for just one.

This is an empirical paper, in the line of works like Ballesteroset al. (2007b), Garlan et al. (2002), Gribble et al. (2000), Grimm andBershad (2002), Johanson et al. (2002), Roman et al. (2002), and vanSteen et al. (1999). It describes a real, fully implemented researchsystem, which has been in production for several years. Althoughthey might be useful if available, some theoretical topics, such as amathematic model for the system, are out of the scope of this paper.The seminal ideas behind Upperware were sketched in Ballesteroset al. (2010). A description of Op, including the detailed seman-tics of the operations and an in-depth description of the messages,was previously presented in Ballesteros et al. (2007a). In short, thecontributions of this paper are:

(1) Introducing the architectural principles of Upperware, asopposed to Middleware and native systems.

(2) Introducing the Octopus system, an actual system built out ofUpperware.

(3) Presenting multiple examples of the use of Upperware, usingthe Octopus as a case example.

(4) Presenting evaluation and experience results, after using Octo-pus for more than three years.

We begin by describing the Upperware approach and presentingsome examples. Then, in Section 3 we describe the main compo-nents of the Octopus, a system built upon Upperware. In Section4 we illustrate the potential of the approach by presenting furtherexamples. We provide details about the implementation and someperformance measurements in Section 5. Then, in Section 6, wediscuss the related work. Last, we conclude in Section 7.

2. Upperware

Our implementation for Upperware provides services to theunderlying OS through a synthetic file-based interface. The localOS is able to connect to the Upperware and mount it as a filesystem.Any application can access Upperware services by using the OS’s
filesystem interface.
These files are exported over a network using a networkfilesystem protocol, to glue the different computers together. Thefilesystem protocol has to be capable of dealing with synthetic files

ystems

aw

rlariiMbmpaia

aeaiOfiUvetiwt

its

•

•

•

adgAf

ewAaSo

vol 100

F.J. Ballesteros et al. / The Journal of S

nd must tolerate high latency links if we expect this approach toork on wide area networks.

An Upperware device driver abstracts and exports a localesource to the rest of the system. The idea is to do so at a highevel of abstraction, for portability. For instance, a machine can runn Upperware driver to export an audio device. This device does notefer to the sound card of the machine, but to its capability of play-ng a standard audio file. In our implementation, the audio devices not abstracted as a device accepting PCM frames, but complete

P3 files instead. All current desktop and mobile systems are capa-le of playing MP3 audio without installing extra software, whicheans that it is easy to wrap their heterogeneous audio devices to

rovide a homogeneous Upperware service accepting MP3. Shouldn application have to play an audio file in other format (e.g. WAV),t must convert it before using the Upperware device, but that is notproblem in practice.

Only features known to be available everywhere are madevailable through Upperware interfaces. Following the previousxample, all desktop systems are able to control the volume, stopnd pause the playing, and seek in the audio track. These capabil-ties are abstracted and supported by the Upperware audio device.n the other hand, not all systems are able to embed lyrics in MP3les. Therefore, this feature should not be included in the standardpperware device. This principle helps to provide a single-systemiew, building a homogeneous system out of many highly het-rogeneous components and computers. But there are two wayso provide non standard features and still preserve the commonnterface: (1) create a new driver for the capability not found every-

here, and (2) separate the file system interface (i.e. the “files”) forhe new feature from that of the common ones.

Upperware devices need to access resources in the host systemn order to provide their services to the rest of the system (e.g.he player device needs to know how to play MP3 files in its hostystem). This can be achieved by different means:

The operation can be performed by executing a single commandon the host system. For example, the Upperware printer device forLinux and Mac OS X executes the lp command. The voice device,which permits to send speech messages to the user, executesfestival when running on Linux systems.In some cases, there is no command to do the job and it is nec-essary to execute custom binaries or scripts in the host system.These custom programs are part of the Upperware device. Theycan be implemented in any language and use any API availableon the host operating system (including GUI automation to accessapplications). For instance, the Upperware player device invokesa custom AppleScript to control iTunes when executed on MacOS X.In other cases, configuration files and databases can be used tocontrol local resources. For example, our web browser devicemanipulates some XML files and databases to deal with bookmarkand history entries.

Upperware drivers can be quite simple in general. Some of themre data sources supported by a synthetic file that provides theesired data, like the camera device. This device provides one sin-le file that, when opened, takes a picture with the host’s camera.fterwards, the file appears to contain the captured data in JPEG

ormat, and may be read as a regular file.Other Upperware drivers are data sinks, implemented as spool-

rs. That is the case of the view device, which is used to open a fileith the appropriate application in the underlying host system.
spooler Upperware device behaves like a directory that performs
ctions on files when they are copied in it, similar to droplets (Applehiny Droplets). Any file copied to the view device’s directory ispened in the host system by executing the default application for

and Software 85 (2012) 1637–1649 1639

it. For instance, when a doc document is copied, it is opened usingthe default word processor application (e.g. MS Word), just as if theuser double-clicked on the file’s icon.

Upperware drivers may be used in different ways. For exam-ple, we assume that all machines have word processing softwareand document viewers installed. Therefore, we use a single viewdevice to open any document. Of course, if a machine has documentviewers and is running view, but it does not have word processingsoftware, view will not be able to open a Word document. Thatis because this machine is breaking our assumption. In this case, itwould be better to consider that document viewers are one service,and word processing a different one. Machines with both serviceswould run two Upperware devices; those with just viewers wouldrun one.2.1. Upperware by example

Upperware is best understood by example. Here, all examplesare expressed in the Rc shell syntax and assume that devices aremounted on /mnt. This is just a compact way of illustrating howUpperware may be used. But note that the use of Upperware is notlimited to the shell command line. Any program, language, or toolcapable of dealing with files is able to control Upperware driversand the system’s components.

The player driver abstracts the music player application of thehost system and permits to play one a song at a time. It knows howto start, pause, resume, stop, and seek, and allows the user to adjustthe volume level of the music player.

The driver is implemented as a spooler directory, equipped withan additional control file, ctl, to control the playing. To play a song,it suffices to copy a file to the directory. To stop it, it suffices toremove the file from the directory. Some operations that are con-venient for programmatic interfaces may seem awkward for endusers (e.g. to remove a file to stop the music player), but that is atrade-off the Upperware driver designer has to make.

This command plays “surfin bird” (the “;” is the prompt of theshell):

; cp surfin bird.mp3 /mnt/playTo pause and resume the playing, we can write the text pause

and playing to the ctl file. Let’s imagine that a pervasive applica-tion needs to pause the music while delivering a speech messageto the user. Assuming /mnt/voice is the mount point for the voicedriver:; echo pause > /mnt/play/ctl

; echo you have new mail > /mnt/voice/speak

; echo playing > /mnt/play/ctl

The ctl file accepts a command to set the percentage of vol-ume in the application. The command is formed by the percentagepreceded by the text string vol. Thus, to mute the player we canexecute:

; echo vol 0 > /mnt/play/ctlWriting the string pos followed by an absolute position mea-

sured in seconds, performs a seek into the song. To re-start thecurrent song, we can execute:

; echo pos 0 > /mnt/play/ctlWhen ctl is read, it provides the status of the device in plain

text. The first line is the status of the player (pause or playing).The second one is the volume. The third one is the position. Thelast three lines are the MP3 metadata for the artist, song, and albumnames. In this example, the song is being played, the player volumeis set to 100%, and the position of the song is second 23:; cat /mnt/play/ctl

playing

pos 23

song Fiberglass Jungle

artist Crossfires

album Cowabunga - Surf Box


isc

ssvut;

;

vt

ci;

;

;

;

;

;

rlbnl

btfi

dd

tatf

3

dbttfat(t(a

t

•

•


You can save the status of the device and restore it later by copy-ng the ctl file. Should the user want to keep on listening to theame song when moving to another office, the pervasive applicationan simply copy a file to do so.

If no song is being played, the ctl file contains the stringtopped. It provides the status of the player even if it is playingome music not commanded by this Upperware driver. Thus, per-asive applications are able to detect if the user is listening to musicsing this device. For example, we can announce the hour only ifhere is no music playing:

sts=‘{sed 1q /mnt/play/ctl}if(∼ $sts stopped) date > /mnt/voice/speak

The first line stores the first text line of ctl in the environmentariable sts. The second line tests if sts is equal to stopped. Inhat case, it sends the speech message to the user.

The browser device works in a similar way. The next exampleaptures the current full state of a browser ($from) and replicatest on another browser ($to):

cat $from/browser/open > /tmp/open

echo inactive > $from/browser/ctl

cp $from/browser/bookmarks $to/browser/bookmarks

cp $from/browser/history $to/browser/history

echo active > $to/browser/ctl

cat /tmp/open > $to/browser/open

The first line dumps all open sites of the old browser to a tempo-al file. The second closes the old browser. Using cp, the next twoines copy bookmarks and history entries from the old to the newrowser. The last two lines activate (open) the web browser on theew place, and re-open all sites previously recorded (by the first

ine).Except /tmp/open, files used in the example are not real files,

ut synthetic files provided by the driver. What happens behindhe scenes depends on the underlying web browsers used, but thelesystem interface offered remains uniform.

History entries are represented as text lines beginning with theate of the browsing. It would be easy to merge and sort them byate using cat and sort.

These were just a few examples, but the underlying ideas andools are generic. A “follow-me PC” might be implemented withfew shell command lines that dump and restore the state when

he user moves from one location to another. More examples willollow once we describe Octopus.

. Octopus: Upperware in practice

To clarify how Upperware works in practice, this sectionescribes the Octopus, a system aimed at providing support touild pervasive applications. Octopus relies on Upperware serviceso provide a uniform computing system. It provides reconfigura-ion mechanisms to adapt to changes and high level interfacesor the heterogeneous resources (devices and applications) thatre available in a pervasive computing environment. Most ofhe Octopus is implemented in Limbo, within the Inferno OSDorward, 1997), which executes hosted on popular OSes. Notehat Inferno (as well as other UNIX descendants, like Plan 9Pike et al., 1990)) does not provide such support for pervasivepplications.

The organization of the system is depicted in Fig. 2. There arewo different kinds of machines in the system:

A per-user central service, the PC, in charge of controlling the restof computers in the system. There is only one PC for each user.The PC runs in a single (virtual or real) machine.The remaining user machines connect to the PC when they runOctopus. Then, they register their resources and import all theresources available in the system (including their own ones).

Fig. 2. Terminals export their resources and import the common name space.

The main idea is to centralize the control and some services inthe PC to facilitate the creation of a single-system view. Centralizingthe control in the PC simplifies the system’s architecture and avoidsscalability issues. Centralized services (e.g. a shared clipboard tocopy and paste text among native applications running on differentterminals) reinforce the feeling of working with a single virtualcomputer.

Our former system, Plan B (Ballesteros et al., 2007b), was basedon a peer-to-peer scheme, in which services were dynamically dis-covered. This approach introduces complexity and leads to relaxedcoherency between data at different machines (at least regard-ing the name spaces). We found that the dynamic peer-to-peerscheme did not provide any actual advantage in practice; sponta-neous interactions at disconnected locations were rare in our case,and we could still rely on a remote central point while connected.Moreover, we noticed that, in most cases, there is always a singlepoint of failure (e.g. a central storage server, a context data server,an authentication server, and so on). We simply decided to run thecentral part of the system there.

Centralizing the control does not imply that the system’sresources are centralized. In our system, resources are distributedamong the user’s terminals. If centralized control becomes an issue,the central coordinator, i.e. the PC, could be replicated and automat-ically replaced upon failure. This is not different from the approachtaken by the Google File System (Ghemawat et al., 2003), whichcentralizes control but distributes data. The same idea has beenapplied here.

Although the system coordinates the resources belonging to asingle user, it can serve the user’s resources (i.e. files) to differentauthenticated users. That is, different Octopus systems can inter-operate to provide shared services. An Octopus system belongs toa single user, but different Octopus systems can work together.

The proposed system is based on the assumption that the user isconnected to the Internet when using the pervasive environment.Nowadays, cell phones are used more for data than they are forvoice calls. Continuous connectivity to the Internet is a reality formost users. This fact is exploited by massive web services like thoseprovided by Google, MSN, Twitter, Facebook, and many other real-world services. We exploit this fact to provide a personal pervasivecomputing environment.

Therefore, there is no concept of logging in or logging out. Octo-pus is always running on behalf of his user (i.e. the PC is alwaysrunning). There is only a single Octopus session for each user; i.e.that running on the PC.

3.1. The PC

The architecture for the PC is depicted in Fig. 3. This central,per-user, node provides a common name space to access all system

F.J. Ballesteros et al. / The Journal of Systems and Software 85 (2012) 1637–1649 1641

sn(ha

loT

asofih

lwtvt/fet

tvi3

bfilOna

aeaSttpp/

Netget is used to register the terminal’s resources in the centralregistry on the PC. This component periodically updates the reg-istry, refreshing the attributes of the resources. Attributes, among

Fig. 3. Architecture for the PC.

ervices and resources. This is the central idea of the system. Theame space is a hierarchical file tree used to resolve resource namesi.e. file names) similar to a mount table in UNIX. Once a file nameas been resolved, the client is able to attach to it and perform readnd write operations.

The PC manages a central registry for the system. The registry,ike the other components, has a synthetic filesystem interface. Itffers dynamic registration and supports attribute-based queries.erminals use the registry to look up resources.

The name space provided by the PC permits the user to namend access resources on a global basis without requiring a globalynthetic filesystem. There are different tiny filesystems executingn different machines, each one providing a different and smallle tree, and the name space is the glue to join them in a singleierarchy.

There are some important conventions which must be fol-owed by the common name space. They make the system

ork, because all programs in the system assume where to lookhings up and where to find files that interface to particular ser-ices. For example, the registry is mounted on /mnt/registry;he default voice device on /mnt/voice; context for users onmnt/who (e.g. /mnt/who/nemo/where records the last locationor nemo). Each terminal is given a directory under /mnt/terms,.g. /mnt/terms/helm/camera is the camera device found at theerminal with name helm.

Two components are used to discover the available services inhe system. Ports provides a general-purpose event delivery ser-ice. Watcher observes the central registry and generates events ofnterest through ports. Service discovery is explained in Section.5.

Jointly, ofs and oxport provide remote access to files. Note thaty file we mean both conventional files (data on disk) and syntheticles. They speak Op, a new filesystem protocol optimized for high

atency links, briefly described in Section 3.3. Ofs implements thep protocol client and oxport implements the server. Both compo-ents are present in the PC because machines export files to the PC,nd then the PC exports the common name space back to terminals.

Mux is a resource multiplexer used to reconfigure the systemnd adapt it to context changes. Mux selects a default resource ofach class employing some heuristics that rely on context datand attributes associated to available resources, as described inection 3.6. As resources come and go, or their attributes change,he name space adapts by replacing portions that no longer meethe user requirements. This provides location and context trans-
arency. For example, the default printer device on /mnt/print isrovided by mux; this printer might be actually the one found onmnt/terms/helm/print.
Fig. 4. Architecture for a terminal.

Mux allows the user (or program) to directly locate the defaultresource of each class. The user only has to know the name of theclass (which is a convention of the system). Moreover, the user isalso able to locate specific resources exported by a concrete ter-minal. The naming conventions and the scale of the system permitit. Note that the name space is per-user. The number of terminalsactually used by one can be of the order of tens, but certainly nothundreds. Of course, other resources exported by near-by machines(e.g. services provided by a smart space infrastructure or resourcesshared by other users) can be also discovered and made available tothe user name space, but that is not a problem, considering the scale(which is always restricted to the physical location in this case).

Other optional services can be hosted on the PC. In particular,our PCs import the context infrastructure from our smart space tomanage information about physical location of users and things(Ballesteros et al., 2007b). Any other context infrastructure can beintegrated with the system. In order to do that, it only has to providethe /mnt/who interface (i.e. a file hierarchy).

Our PCs also import a shared NAS providing us a replicatedfilesystem with daily snapshots. This is our primary storage ser-vice and it is used as the root of the hierarchical file tree exportedby our PCs.

3.2. Terminals

For each user, terminals are machines other than her PC. The usercan own or borrow a machine from someone else, start Octopus,and use it as a terminal for a while. The architecture of a terminalis depicted in Fig. 4.

Like the PC, terminals execute oxport and ofs, to exporttheir resources to the PC and to import the common name spaceback, respectively. Resources from the terminal’s host system areexported to the PC with Upperware, as explained in Section 2. Thelist of resources exported by a terminal is part of its configuration.1

The host local filesystem can also be exported to the PC. Therefore,any terminal is able to access data files from any other terminal,because the common name space includes the local filesystems ofall terminals (in fact, all volumes mounted in all terminals).

1 In the current version of the system, it is an init shell script. There is a defaultinit script with the most common used devices.

1 ystems

oato

es2tt

iotiboTo(

wtvdit;

p

u

l

tnllohtasmOlt(

twsbw

3

fiwe

S

r

c


ther information, include the physical location of the resource (e.g.specific office or room) and the RTT (Round-Trip Time) to reach

he PC. These two attributes are valuable to select default resourcesf each class according to the context.2

Netget retrieves the physical location of the terminal from anxternal context data infrastructure. As stated before, our currentystem uses a previous context infrastructure (Ballesteros et al.,007b) to locate users and things. Our terminals estimate their loca-ion (either by static configuration, by using sensors, or by askinghe user) and store it in the context infrastructure.

The system is agnostic with respect to the meaning of locationdentifiers. Location identifiers are just text strings (e.g. 129 forffice number 129). The meaning and granularity of location iden-ifiers are up to the users. These strings may represent a hierarchyf needed (e.g. using DNS names), but our current location model isased on a flat space of rooms. That is, a user may be at a specificffice (e.g. 129), at the lab (e.g. 134), at home (e.g. paurea’s), etc.his permits our system to switch between the different resourcesf the same class that are available in the same physical locationi.e. room) when needed.

Upperware drivers running in the terminal serve a text file, ndb,hich describes general properties of the device. Among other

hings it describes the location of the device and the terminal pro-iding it. The example below illustrates the ndb file of a printerevice owned by user esoriano and served by the terminal ignatz

n a Mac OS X host. The device is located at office 129, and the RTTo reach the PC is 77 ms:

cat /mnt/print/ndb

ath /terms/ignatz/print sys ignatz

ser esoriano arch MacOSX386

oc 129 rad 77 lease 60

Another terminal’s component, idle, collects information fromhe underlying system to guess whether the user is using the termi-al or not. Considering that each terminal makes a guess about its

ocation, idle provides reasonable statistics to guess not just theast terminal accessed by the user, but also his or her location. Inrder to guess if the terminal is being used, idle employs a simpleeuristic. It consists of an algorithm that polls the I/O devices of theerminal (e.g. mouse and keyboard). In short, if (i) there is activityfter a period of inactivity or (ii) there is continuous activity forome time, then the context infrastructure is updated (the last ter-inal used by the user is updated with the name of this terminal).ur context infrastructure reacts to this change and updates the

ocation of the user.3 This component permits the system to locatehe user when she is working at places without location sensorse.g. her home).

Octopus terminals integrate a WebDAV server in order to servehe common name space to the underlying host system as a net-ork volume. Note that this server is used only to provide a file

ystem interface to the underlying OS in a portable way. FUSE coulde used instead, which would be more efficient but would requireriting a different implementation for each different host OS.

.3. Communication

As stated in previous sections, all resources are exported as
les through the network. An Octopus user accesses the Upper-are using a network filesystem protocol to reach the name space
xported by the PC.4 In addition, terminals are potentially far away

2 Our implementation is using just the location for this purpose as discussed inection 3.6. RTTs help the user to discover how far are resources from the PC.3 Note that this information expires after some time, depending on the configu-

ation of the context infrastructure.4 This can be short-circuited for “close by” terminals or local Upperware in some

ases, as an optimization.

and Software 85 (2012) 1637–1649

from the PC. Even though modern networks have higher band-widths, there is a strict boundary on latency for long distances.

We had to design and implement a new protocol to use theOctopus from our homes through ADSL, Cable-Modem, and WANconnections. This protocol is named Op. In what follows wedescribe just enough of Op to give a glimpse of the protocol andshow how it supports Upperware and how it fits in the Octopus.Further details of the protocol can be found in Ballesteros et al.(2007a).

Octopus is implemented on Inferno, and its protocol, Styx (Pikeand Ritchie, 1999), works fine within low latency regular local areanetworks, but it behaves badly over high latency links because anyoperation done in the filesystem requires many synchronous RPCs,even in those cases when a single RPC would suffice. Retrieving afile (small or not) using Styx requires one or more RPCs to resolvethe file name and even more RPCs to actually read or write data.Each of these RPCs takes a round-trip, which is very costly in highlatency networks. Moreover, interactive use (when the user is inthe loop waiting for the actions to happen) is unbearable with thisstrategy.

One way to deal with this problem would be to perform cachingat the client, but synthetic files are not cacheable in most cases andwould not benefit from this approach. Another possible solution toavoid latency problems would be to send RPC requests concurrentlywithout waiting for the replies, and then blocking the client untilall replies are received. But a serious drawback of this approach isthat it requires changes to existing applications and libraries. Syn-thetic files are also used sometimes to wait for things to happen, forinstance by blocking on a read. In this case none of the approachesabove alleviates the cost.

A last resort would be to batch requests, as done by NFSv4(Pawlowski et al., 2000). However, there is the problem of decidingwhat to batch. A protocol designed to work well in this environmenthas no other choice but to minimize when possible the number ofround-trips required to perform any operation.

Op is still a general network filesystem protocol. It follows theRPC model used by Styx, but minimizes the number of RPCs neededto perform the most frequent series of operations. Op uses thefollowing strategies:

• The Op protocol is based on a new set of messages. Each of therequest messages is analogous to a group of Styx messages.

• Messages are not strictly request and response pairs, yet the pro-tocol is RPC-based. The point is that a single request message (inthe RPC) can trigger more than one response message in orderto accelerate the dialog between client and server. This way, theprotocol can deal with high latencies when reading large files.

• If a file is small enough to fit in a single message, Op supportsretrieving/updating it (including the file name resolution andmetadata) in a single RPC.5 This is precisely the common casewhen using Upperware.

• Unlike other protocols (e.g. HTTP) Op still provides full file seman-tics including protection, metadata, support for file descriptors,etc.

• Open and close are implicit in the operations but the resultingfile descriptor can be reused in order not to resolve the file nametwice in the server.

Op messages are the following: Attach introduces the user to
the server. It corresponds to a mount operation. The put operationis used to write data or metadata to a file or directory. Get readsdata or metadata from a file or directory; and may lead to multiple
5 In the current implementation the message size is 16 KiB, but it can be config-ured.

ystems

rdr

Iacsc

tp

smsea

cotf

3

twi

eEo

m

dOtrsabd

a

tt;

;

;

;

Trl

witd


esponses, up to a maximum specified in the request. Removeeletes a file or directory. Flush is used to abort an outstandingequest.

The Op client is able to cache file metadata and directory entries.t can be configured to provide strict coherence (essential to oper-te on synthetic files provided by Upperware devices) or relaxedoherence. Note that relaxed coherence may be fine for the user,ince the architecture is intended for a single user and, therefore,ontention is very low.

The design principles described above resulted in a protocolhat outperforms Styx and other widely used network filesystemrotocols when latency increases, as shown in Section 5.2.

As depicted in Figs. 3 and 4, ofs and oxport (Op client anderver) are employed as a bridge to transparently interconnect ter-inals to the PC. All other components in Octopus rely on the

tandard Inferno protocol, Styx, and may remain unaware of thexistence of Op; yet they can be used over wide-area networks orny link with poor latency.

Oxport serves a file tree over a connection to an Op client. Theonnection is assumed to be trusted and authenticated on the namef the first user attaching to the exported file tree. Ofs is the coun-erpart to oxport and provides a file tree (via the Styx protocol)rom a remote Op server (speaking Op).

.4. Event delivery

The Octopus provides a general-purpose event delivery subsys-em. Ports is a synthetic file server running in the PC. It is availableithin the common name space, so any terminal is capable of using

t to send or receive events.Ports serves a directory with a post file that can be used to post

vents. Each write operation on this file is considered an event.vents are supposed to be small enough to fit in a single writeperation,6 and they are handled as text strings.

For example, when Octopus is started in a terminal, this com-and is used to notify of the event:; echo arrived:$sysname > /mnt/ports/postTo listen for events, additional files may be created in the ports

irectory. Each file created represents a listener for a type of events.nce created, a regular expression must be written to the file,

o make it listen for matching events. Events not matching thisegular expression are not queued on this file. The regular expres-ion can be changed by further writes, but it will not affect eventslready queued for delivery. Therefore, ports provides an event-ased communication style that enables subscriptors to react toifferent events.

This command creates a new port, terms, which listens forrrivals and departures of terminals:

; echo ‘(arrived|gone):.*’ > /mnt/ports/termsAt this point, we can receive events by reading from terms. In

his example, to notify the user about a terminal arrival or depar-ure, we can execute:

event=‘{read < /mnt/ports/terms}name=‘{echo $event | sed ’s/.*://’}didwhat=‘{echo $event | sed ’s/:.*//’}echo terminal $name $didwhat > /mnt/voice/speak

he first line (blocks until it) reads an event. When the event isead, it is stored in the environment variable event. The next twoines get the name of the terminal and the name of the event (i.e.

6 If an application needs to generate events that exceed the maximum size of arite operation (e.g. to attach an image), it can store the data in a temporal file and

nclude the path to this file in the event. As long as the terminals and the PC sharehe common name space, the receivers of the event are able to locate and read theata file.

and Software 85 (2012) 1637–1649 1643

“arrived” or “gone”). The last line sends a speech message to theuser.

3.5. Service discovery

Terminals use a component named netget to register theirresources (i.e. Upperware devices) when they connect to the PC.In the PC, the Inferno OS registry is used to manage the informa-tion about available resources. Resources are specified by a nameand a specification string that includes several attributes. The namedetermines the class of the resource. For instance, voice is used forthe voice driver, which processes speech messages.

The specification string for a resource is defined as a set ofattribute/value pairs. At least one attribute is expected, to specifythe path for the resource in the terminal. Netget adds the prefix/mnt/terms/sysname before the path supplied in order to makeit portable across different terminals, where sysname is the nameof the terminal. Other attributes may include other valuable infor-mation, as the physical location, the latency to reach the PC (RTT inms), and the host system type.

In the PC, watcher watches out the registry for changes andnotifies interested parties about them, through ports. When a ter-minal is started, it registers an entry for its ofs component. For eachnew entry in the registry with name ofs, watcher delivers an eventnotifying of the arrival of the terminal whose name is reported bythe sys attribute as found in the entry (like we did in the examplesin the previous section).

Watcher also reports departures. When the ofs entry is gone(either because of a lack of refresh for its lease or because of aremoval from the registry) watcher sends an event notifying thedeparture of the corresponding terminal.

3.6. Adaptation and reconfiguration

Upperware drivers export tiny trees of synthetic files. The namespace used in the PC selects which ones to mount at well-knownplaces on the file tree, depending on their attributes and availability.When a mounted resource fails or gets disconnected, the system isable to replace it with another equivalent to the one gone. This isdone by mux.

The PC exports resources that are subject to dynamic reconfigu-ration by executing an instance of mux for each of them. Mux is givena set of constraints and, by looking at the registry, selects a resourcematching the constraints and serves its file tree in very much thesame way a proxy would do. Applications use files provided by muxinstead of relying on the service provider, to adapt to changes. Theresources to be multiplexed (and the constrains to be matched) arepart of the configuration of the system. For example, we usuallystart one mux for each class of resource, specifying the constraintsto switch them according to the physical location of the user.

If resource availability changes (or attributes no longer match),mux updates its selection and switches to a new resource instance,if any. Mux queries the central registry to get the list of resourcesmatching the specified constrains. Then, it tests the file systemsof the resources in the list. There can be several unresponsive fileservers in the list before the first responsive one is reached (andselected).

Constraints are specified as attribute/value pairs whereattributes are interpreted dynamically. As a result, automaticresource selection can still be adjusted by the user, by modifyingattributes for resources. Note that the names of the attributes areconventions of the system.

The name attribute specifies an agreed-upon name describingthe resource (e.g. voice). The loc attribute specifies the location(of a resource) as known to the system. Therefore, Mux can select adefault resource depending on a specified location.

1644 F.J. Ballesteros et al. / The Journal of Systems and Software 85 (2012) 1637–1649

F ce. Mua

imoten

uato

aa

udri

ssmB

ig. 5. Three terminals exporting some resources and importing the whole name spand the user’s data are external services integrated into the name space.

For example, /mnt/voice is the default voice synthesis servicen Octopus. This directory is provided by mux, so that when the user

oves to another office, the default voice device switches to a newne found at the new location, if any. If there is none to switcho, /mnt/voice would still work as a directory, but it would bempty. Fig. 5 depicts an example configuration and the resultingame space.

For example, the command; mux -m /mnt/voice name voice loc 136makes /mnt/voice become any voice device (owned by the

ser) available at location 136. If the one in use goes away andnother one becomes available with name voice and location 136,he new one is transparently put in place. The same happens tother devices. This is just one example out of many.

In those cases when, after a switch, there is no matching devicend the directory for the resource becomes empty, it is up to thepplication (or the user) what to do.

The special location $user means “the current location of theser”, whatever it might be. The next example mounts any voiceevice colocated with the user. When the user changes location, muxeevaluates the constraints given as arguments to see if the devicen use still shares the location with the user or a switch is needed.

; mux -m /mnt/voice name voice loc ‘$user’For mux, location is just an attribute and its value is simply a

tring to match. Remember that such values describe rooms ormaller spaces in our location model, so that device switchingakes sense in practice for the users of our particular environment.

ut mux is unaware of semantics.

x is in charge of multiplexing the default resource of each class. Context information

After a device switch, internal references to the file tree structureare cleanly switched to use files in the new resource and the entirefile tree is kept working. Applications may remain using the filetree as if nothing had happened. However, open files for the failedresource report an I/O error to the client program. Thus, applica-tions should in general open, use, and then close files every timethey need to work with them. Reporting I/O errors for files open inthe middle of a switch is important because there might be ongoingupdates to files and it is not reasonable to do them in part on theold location and in part on the new one.

Trying to hide these errors from the user (be it an application ora real user) introduces other errors because the environment mayhave changed, or the resources not be there any more. The useror the application may have to decide the appropriate course ofaction (e.g. should the operation be retried? Should the applicationabort?) A joke told out loud using the Upperware voice device athome may not be so funny in the office. A half written file mayhave to be saved again in another path if the device exporting thefilesystem changes. Dealing with the error is user and applicationdependent and cannot be hidden.

We have to say that, in practice, we have found that thisapproach works well. Seldom, editors report errors (due to the I/Oerror on device switching), and the user clicks again to save thefile.

Note that caching multiplexed files still works. While the oldfile descriptor is still open and the application has not seen theerror, data may come from the cached version of the old file. Afterthe switch and the I/O error, the file will be closed and a new

ystems

co

3

etattccst

ntmwa

ptp

3

Ow

•

•

•

•

•

so

fiaronb

k

Capturing the state of a terminal is needed to recreate the user


ached version for the file will be used. Both files never get mixedr confused in the cache.

.7. Protection

Resources are supposed to be accessed only by the user. How-ver, the system could be configured to permit other users to accesshem. As stated in previous works (Ballesteros et al., 2006b, 2007b),bstracting resources as files simplifies the protection scheme ofhe system. In Octopus, standard UNIX file permissions are usedo control access to resources. Nevertheless, each filesystem serveran implement its own access control policy. For example, a spe-ific device can refuse to perform permission changes or to accessome files for any user but the owner (ignoring the permissions forhe group and others).

By default, ofs authenticates the client and encrypts the con-ection using RC4. The key file used for authentication followshe standard convention used in Inferno. In terminals, the key file

ay be stored within the Inferno subtree in the local filesystem, inhich case authentication ultimately depends on the host system’s

uthentication and access control schemes.An Octopus terminal running on a borrowed machine has the

rivileges of the local user in this machine (i.e. the privileges ofhe guest account). The access control mechanisms of the host OSrevail over the mechanisms of the Octopus system.

.8. Upperware based user interface

An interesting component of the Octopus for the end user is/live, both a UIMS and a window system. O/live exploits Upper-are in several interesting ways:

The clipboard is provided by an Upperware driver. Therefore thereis a single clipboard shared among all terminals, we can copy datain one terminal and paste it in another one.The focus (i.e. the information of which UI element is the userworking with) is provided by an Upperware driver. Therefore, theuser can select text at one machine and then, execute a commandat a different machine to operate on it (e.g. use a Linux program toautomatically indent source code that we are editing on a near-byWindows).An Upperware voice device is used to notify the user when needed(e.g. its command execution service relies on this to notify theuser when a command that took more than 2 seconds to completefinishes).Handling of complex data formats (e.g. PDF files, MS Word doc-uments, etc.) and URLs is performed by relying on Upperwaredrivers. Native applications are used to view images, videos, openweb sites, etc.The O/live UI itself is exported to both users and applications asan Upperware interface. For example, a program may search theUI directory for a file representing a play button, and then writesome text in the file to press the button.

In O/live, UI elements are represented as an abstract set ofynthetic files, describing their state. O/live aware applicationsperate on these files to update the corresponding widgets.

A file server, running in the PC, provides the UI elements (i.e.les) and dynamically processes operations over them. This way,ll the state of the UI is kept in the PC. UI subtrees may be freelyeplicated and re-arranged without disturbing the application, byperating on their corresponding files. The O/live file server run-
ing on the PC coordinates replication and concurrent access fromoth applications and UI viewers.
O/live has been written with high latency links in mind; iteeps most of the interaction local to the terminal. All I/O and

and Software 85 (2012) 1637–1649 1645

editing activity is confined to viewers running in the terminals.Viewers choose UI trees or subtrees to display by remotelyaccessing file subtrees. As the state is managed by the PC, viewerscan come and go as terminals do, and the UI layout and state ispreserved.

O/live aims at providing support for User Interfaces for ubiq-uitous computing applications. Here we have described just how itexploits Upperware, but it is a complete system by itself.

4. The potential of the Octopus approach

This section provides further examples in order to illustrate thepotential of the Octopus to create personal pervasive computingenvironments and provide a single, virtual computer. Notice thatthese examples would require complex programs and/or manualcontrol in other systems. When using the Octopus, they only requirea few lines of code (or zero).

We use the Rc shell and the C language in the examples. Thisdoes not mean they are the primary interface for the system. Allusers and programming languages (e.g. Python, Java, Prolog, etc.)know how to read and write files (in fact, a file manager may sufficefor most users).

Because the terminals export their devices and resources asUpperware, any program running in the PC has complete accessto all the devices the user owns. Simple scripts and programs canbe executed in the PC to control the terminals.

The file manager of any conventional OS is a good example.Because of Upperware, it becomes a distributed context-awareapplication. It can be used, for example, to browse our files and copyone of them to the default printer directory (that is, /mnt/print inthe common name space). Simple drag and drop suffices. Similarly,any text editor can be used to handle an X10 device (open its file,type “off”, and save to switch the device off), etc.

The PC is not the only place where we can run applications andexploit Upperware. Terminals export the common name space tothe underlying host system (our implementation uses a WebDAVserver accepting connections from the local host). As a result, thename space of the PC is seen on each terminal as a regular filesys-tem. Simple mobile machines which can use a filesystem can takeadvantage of this.

Context-aware programming is required to create pervasiveapplications. In the Octopus, a simple C function using only filesystem calls is ready to use new system services, like speech syn-thesis. This code is already context aware, because /mnt/voiceis the voice device co-located with the user (as selected bymux):void

speak(char *msg)

{int fd;

fd = open(”/mnt/voice/speak”, O WRONLY);

if(fd > = 0){write(fd, msg, strlen(msg));

close(fd);

}}

Also, note how trivial it would be to develop tiny libraries fordifferent languages providing wrapper functions like the previousone, should ADTs or Objects be desired instead of files. Abstract-ing resources as synthetic files dramatically reduces the amountof software to be developed and maintained. Files are well under-stood.

session in another machine when she moves. This is important ifwe want to provide the illusion of a single virtual computer. Thisscript, running in the PC, captures the state of the terminal whenthe user leaves (as detected by the idle device):


#

#

e

#

{

aUs

iaaaw

tsm#

#

c

c

e

c

e

c

uama

pga(

betoe

Pnuittusttd

ttj

omt

ftrs

Table 1SLOC for Octopus.

System components Lines of source code

Octopus services 15,274Upperware (portable) 1495

The performance of the Octopus is determined by remote fileI/O over high latency networks, because (i) the components of the


! /bin/rc

create a port channel to listen for events

cho ‘gone:.*’ > /mnt/ports/terms

for each event execute the dump script

while {x=‘{read < /mnt/ports/terms}} {dump $x}} &

The dump command, used in the last line, captures the state ofpplications running on the terminal on behalf of the user, usingpperware interfaces (which means just copying some files, ashown in previous examples).

Embedded devices and sensor networks can be exported follow-ng the same approach. We have had at different points in time X10nd KNX sensors and devices, and Hexamite Ultrasonic devices,ll abstracted as filesystems (Ballesteros et al., 2005). Later, otheruthors have followed the same approach to export sensor net-orks (Horey et al., 2008).

In our implementation, these devices are integrated in the sys-em to help in context and location services and to make our smartpace smart. The following script relies on X10 devices and imple-ents a simplified home surveillance pervasive application:! /bin/rc

$hometerm is the home terminal’s mount point

at $hometerm/x10/livingroom > /dev/null

p $hometerm/camera/ctl /tmp/photo.jpg

cho vol 100 > $hometerm/play/ctl

p /lib/sounds/alarm.mp3 $hometerm/play

cho intruder at home > /mnt/voice/speak

p /tmp/photo.jpg /mnt/view

Note that this simple example could be implemented in min-tes. Moreover, operations have been accomplished by usingncient commands never meant to perform this kind of tasks. Onceore, this is just a single example of the power of the Upperware

pproach.Daily computing tasks can be performed using Octopus. This

aper was written using the Octopus, i.e. using Upperware. This hasiven us a great advantage over traditional systems; over sharingn NFS/Samba volume or connecting through a remote terminale.g. SSH) to a central server.

Using Op as the network protocol means that we get all theenefits of a network file system and tolerate high latency links,ffectively working as if everything was local in any place ofhe world. Thus, we can have all the data, like the source filef the paper we are editing, centralized on the PC and availableverywhere.

We typeset the ( ) code by executing commands in theC, so we do not depend on the software installed in the termi-al (except the Octopus itself). At the same time, we are able tose any software installed in the terminal (e.g. to edit the figures

ncluded in the manuscript). Each time we need to review a draft ofhe manuscript, we just open it, which uses the view device to openhe document executing the default local application. When we aresing different terminals at the same time, we commonly use onecreen to show the draft manuscript and the other one to showhe ( ) source file. Our system is able to automatically showhe PDF in the desired screen, by using the corresponding viewevice.

When we need to use a spell command only available at anothererminal, we just select the text and execute the spell command onhe selection. When we need a paper copy of the manuscript, weust copy the PDF to the print device.

Some of the tasks described here can be done by combining NFS,r SMB, and SSH, but only within a LAN and forcing the user toanually control each operation. When using the Octopus, we get

he illusion of a single computing environment.We have been using the system for more than three years

or everyday tasks, which include writing code, preparing lec-ure and lab materials, giving talks, and writing papers. Pleaseefer to http://lsub.org/ls/demos.html for demonstrations of theystem.

Upperware (non-portable) 2525Total 19,294

5. Evaluation

This section provides evaluation for Octopus and Upperware bydiscussing the implementation and presenting some results on theperformance of the system.

5.1. Implementation

Octopus has been implemented in Limbo (Dorward, 1997).Limbo is compiled to byte-code. The byte-code is interpreted bya virtual machine called Dis, which is part of Inferno. Therefore, thesame implementation of Octopus can be used for all host operatingsystems.7

The current implementation is quite small considering the func-tionality of the system. Table 1 gives numbers for SLOC of variouscomponents: system services (e.g. mux, ofs, etc.), portable and sys-tem dependent (e.g. MacOS X) source of Upperware drivers. Thistable does not include the UIMS O/live, which accounts for 10141SLOC on its own.

Upperware drivers are usually formed by a portable module anda system-dependent module. Portable modules are implementedin Limbo and implement the file system interface for the driver.System-dependent modules implement the required operations toaccess the host system. These modules may either execute a nativeprogram on a particular system, generate and execute a script, orrely on any other system interface that might be used to do the job,as explained in Section 2.

Developing Upperware is trivial in most cases by leveragingexisting libraries for implementing synthetic file systems (e.g.adding voice required just 60 lines of source code). Also, there aretools supporting common Upperware behavior. For example, viewand print rely on a generic spool module. This module providesa synthesized directory and delegates to specific implementationshow to handle files in it. A per-driver module supplies three func-tions: Start, invoked when a new file is placed in the directoryin order to start the processing of the file; Stop, invoked when afile is removed from the spool directory, to stop processing it andto release its resources; and Status, which provides the currentstatus for the request. The Upperware for view, which uses spool,required only 117 lines of source code.

Development of Upperware may be difficult in some casesbecause of the lack of support for introspection in existing appli-cations and systems with poor support for scripting. If would bedesirable for them to be more scriptable so that programs couldeasily operate on them. Another difficulty is that Upperware driversthat manipulate configuration files (e.g. the browser device) arehighly dependent on the application version and need more sup-port from developers that other Upperware drivers.

5.2. Performance

7 Inferno can be executed on bare hardware or hosted on other systems, such asPlan 9, Plan B, Linux, Mac OS X, Windows and FreeBSD.

http://lsub.org/ls/demos.html

F.J. Ballesteros et al. / The Journal of Systems and Software 85 (2012) 1637–1649 1647

. (b) C

stpp

wbPb

m

wh

(

(

(

Twmn

5

tMTt

tnmmdt

mr

Fig. 6. (a) Number of RPCs for Op and Styx

ystem are synthetic file systems and (ii) the Octopus is a dis-ributed system connected by the Internet. Thus, the overallerformance of the Octopus depends on the network file systemrotocol, Op.

The experiments shown in Sections 5.2.1–5.2.3 compare Opith other file system protocols. These experiments show that Op

ehaves better than the others when latency increases. When theC is far away from the terminals, Op makes the difference betweeneing able to use the system interactively or not.

The experiment described in 5.2.4 shows that the Upperwareechanisms overhead is not noticeable by final users.To compare Op with other protocols we used three different

orkloads over non-synthetic files (most other protocols do notandle synthetic files appropriately):

1) Compiling the code of ofs by executing mk.8 This reads severalfiles (the rules file, source code files, libraries, and so on) andcreates new files.

2) Cleaning up the distribution by executing mk clean. This readsdirectory entries and removes several files.

3) Listing the directory by executing lc.9 In this case, most oper-ations are reading directory entries.

Latencies for the experiments vary from 1 ms to 100 ms of RTT.hese numbers are quite conservative and favor Op competitors,hich perform poorly as latency increases. Some ADSL links nor-ally have 100–200 ms of RTT. This can be even worse in mobile

etworks.

.2.1. Experiment: comparing Op and StyxFig. 6(a) shows the number of RPCs required for executing the

hree workloads sequentially. This experiment was performed onac OS X 10.4 using a 2.3 GHz Intel Core Duo with 2 Gb of memory.

he client and server ran in the same machine and communicatedhrough the loopback interface.

The experiment compares Styx (with no latency) and Op forhree latency values (1, 50, and 100 ms). The figure shows theumber of RPCs for different coherency windows. The ofs imple-entation accepts a parameter defining a coherency window, inilliseconds, for its cache. If cached information is within that win-

ow, no new read operations are issued to validate (or invalidate)he cached entries.

The number of RPCs for Op is considerably reduced (approxi-ately half). Therefore, the impact of latency will be considerably

educed.

8 A program similar to UNIX’s make.9 A command similar to UNIX’s ls.

ompared time for Op and other protocols.

5.2.2. Experiment: comparing Op and Styx, strict coherencyReading all the source and manual files (one file at a time) of

the system (about 400 KiB) using Op required 63.73 s across a realADSL line with 52 ms of RTT according to ICMP. Using Styx required86.06 s.

In this case, Op was configured to maintain strict coherency. Thisexperiment was performed on Mac OS X 10.4 using a 2.3 GHz IntelCore2 Duo machine with 2 Gb of memory.

5.2.3. Experiment: comparing Op, Styx, CIFS, and NFSv3Fig. 6(b) presents the average time required to execute workload

(1) for Op, Styx, CIFS, and NFSv3. This experiment was performedon FreeBSD 6.2 using a Pentium 4 3.2 GHz with 1 Gb of memory.The version of CIFS was Samba 3.0. The NFSv3 implementation wasas supplied with FreeBSD version 6.2. They were tested with thedefault configuration. NFS was tested over TCP, to be fair. The clientand server ran in the same machine and communicated through theloopback interface.

When latency is high (100 ms of RTT), the accumulated timefor this experiment for SAMBA is approximately three times thetime required for Op. Op also behaves better than NFSv3 (it takesapproximately twice the time taken for Op).

5.2.4. Experiment: Upperware mechanisms overheadThis experiment shows that the overhead introduced by Upper-

ware I/O mechanisms is imperceptible to the user. It was performedon Mac OS X 10.4 using a 2.0 GHz Intel Core Duo with 2 Gb ofmemory. Commands are executed in an Inferno shell and accessthe terminal’s Upperware devices directly (that is, the PC is beingbypassed):; time cp /term/camera/ctl /tmp/pic.jpg

0.001l 3.103r 3.104t

; time cp /term/camera/ctl /term/view/pic.jpg

0.018l 3.142r 3.16t

The first command takes a picture with the camera device of theterminal and stores it in the local disk. The second command takesa picture and copies it to the terminal’s view device, involving twodifferent Upperware devices. For reference, the time measured fortaking a picture using the native command in Mac OS X was 3.08 s.

The following commands send a speech message through thevoice device:; time echo this is an experiment > /term/voice/speak

0.001l 1.519r 1.52t

; time echo this is an experiment > \ };; /mnt/terms/ignatz/voice/speak

0l 1.521r 1.521t

The first command uses the device from the terminal directly.The second one uses the device using the PC name space, with the
terminal and the PC on the same LAN. Executing the command inthe PC takes longer because the network needs to be crossed. Thesame command was executed from home through a Cable-Modemlink with 225 ms of RTT, and it took 1.606 s to execute.

1 ystems

6

eaf

ic2UfPc

dtCiomaowtvfifiacnc(

ur

Sa2npi

c2stact

cGbba

etucDs

o


. Related work

Describing here all relevant related work would require anntire paper on its own and therefore it is unfeasible. We apologizend try to focus here only on those systems that are representativeor those not mentioned.

Plan 9 (Pike et al., 1990) and Inferno (Dorward, 1997) use filenterfaces, but they do not use Upperware and do not adapt tohanges in the environment. Plan B (Ballesteros et al., 2006a,b,007b) uses file interfaces and adapts to changes, but it does not usepperware; it runs on bare hardware. Thus, all the machines were

orced to run Plan B instead of a mainstream operating system. Also,lan B followed a decentralized scheme and Octopus centralizesontrol on the PC, which makes it simpler.

GAIA’s CFS (Roman et al., 2002) provides access to the users’ata files adapting to changes. As users physically enter and leavehe Active Space, their data files are integrated into the file tree.FS also converts the data format of some kinds of files depend-

ng on the context (i.e. the kind of the device). User’s data isrganized depending on defined properties and the context infor-ation. In this aspect, it is similar to mux. However, mux multiplexes

ll resources (devices, applications, and data files), not just regularn-disk files. Note that mux is just a component of the Octopus,hich is a complete system for pervasive computing. In order to

ransform CFS to a system similar to the Octopus, it should be pro-ided with mechanisms and schemes to bind dispersed (remote)le systems in one name space, wrap devices and applications asle systems (the Upperware), provide the resources to other OSes,nd so on. Moreover, it would require a network filesystem proto-ol well suited to handle devices and perform well over wide areaetworks. GAIA provides its own services to create pervasive appli-ations, but these services are not based on synthetic filesystemsthey are based on a middleware architecture).

Some databases like (Oracle, 2009), and SFS (Gifford et al., 1991)se file interfaces. They differ in that they do not interface to allesources and do not provide a system for pervasive computing.

Octopus differs from Middleware based systems like Globe (vanteen et al., 1999), GAIA (Roman et al., 2002), One.world (Grimmnd Bershad, 2002), iROS (Johanson et al., 2002), Aura (Garlan et al.,002), and Ninja (Gribble et al., 2000) in that applications do noteed to see any “Middleware” interface: there is no need to recom-ile or change them to adapt them to the Middleware, because there

s none.Desktop applications have been used to build pervasive appli-

ations and “Follow-me PCs” in other systems (Johanson et al.,002; Roman et al., 2002), perhaps migrating the user’s sessiontate (Garlan et al., 2002). The Octopus is not focused on migratinghe state for certain (e.g. Office) applications; instead, it providesgeneral-purpose system to the user, reachable from any other

omputer. For example, we may use simultaneously many differenterminal machines at the same time, within the same session.

Other works aim to share objects for world-wide area appli-ations, so they must provide worldwide scalability. Most notablylobe (van Steen et al., 1999). That is not an issue in the Octopus,ecause the number of user terminals grows linearly with the num-er of machines owned (or borrowed) by the user, and there is alsoreasonable limit on this number.

Some systems rely on code shipping (Yu et al., 2006) or permit toxecute code in the web browser, like NaCl (Yee et al., 2009). Unlikehem, Upperware does not move any code to client machines. If theser moves, the system updates its name space and adapts. NaCl isloser to the infrastructure Upperware needs to execute (Inferno
orward, 1997 in this case) than to Upperware itself, except its
andbox is too restrictive.Virtual machines (VMs) can be used to export virtual devices to

ther machines in order to build pervasive applications (Baratto

and Software 85 (2012) 1637–1649

et al., 2004; Rudolph, 2009; Jujjuri et al., 2010). But this doesnot solve the problem of what to do with other legacy OSes andtheir applications, and most do not work well across high latencylinks, as Octopus does. Others move VMs or their state (Rudolph,2009; Satyanarayanan et al., 2009), e.g. to offload computation frommobile devices, but they do not provide the basic services to buildpervasive applications and combine resources imported from dif-ferent systems. Another difference is that the Octopus does notrequire a VM to operate, it just provides the services to the nativesystem and applications running over it.

Web services aim at providing services to the users at throughthe Internet, like we do. However, they rely on a different set ofinterfaces (i.e. Web based), which introduces a whole plethora ofproblems like protection, metadata handling, providing access toremote devices, supplying interfaces acceptable for legacy nativeapplications, etc. On the other hand, it is well known how to addresssuch issues using files, since the times of UNIX (Killian, 1984). Octo-pus and Upperware leverages on that. Web services do not, andare hard to combine (Bronsted et al., 2010). REST Web Services(Fielding, 2000) try to bring back file-like interfaces on top of weblayers. Instead, Octopus uses files directly.

File protocols like SMB Protocols for X/Open PC Interworking:SMB, Version 2, NFS (Pawlowski et al., 2000), and Styx (Pike andRitchie, 1999) differ from Op in that: (i) Op tolerates high latencieseven for interactive use; and (ii) Op can work for accessing devices.None of them does both.

7. Conclusions and future work

This paper introduces the Upperware architecture, whichabstracts resources for the system, including native unmodifiedapplications from different systems, as opposed to the approachesbased on Middleware and native systems. Using Upperware we suc-cessfully manage heterogeneous software and hardware, withouthaving to rewrite, modify, or even recompile existing applications.The advantages of the Upperware approach are quantifiable: wealready have hundreds of programs (e.g. the UNIX programmingenvironment) that work with our pervasive environment withoutany modification.

We have presented the Octopus and its architecture, as an exam-ple of a system using this approach. It is a complete system basedon Upperware that enables per-person pervasive environments.

We have described the services provided by the system to buildpervasive applications out of Upperware, some details about a newfilesystem protocol optimized for high latency links, diverse exam-ples of use, a description of a complete implementation of theproposed architecture and the protocol, and its evaluation.

We included some lessons learned from developing two differ-ent architectures for building pervasive environments, Octopus andits predecessor, Plan B.

We have been using the Octopus and several Upperware devicesfor more than three years, as the computing environment for ourdaily work (Ballesteros et al., 2010). We have also used it from othercountries (EU and overseas). We believe the system is successfulin providing pervasive access to our resources. Some Upperwaredevices resulted highly useful, and we use them on a daily basis(e.g. view and voice). On the other hand, some other devices endedup being proof-of-concept prototypes and were replaced by otherservices (e.g. browser).

As stated before, the PC is a central point of failure. Future workincludes a scheme for replicating the PC and replacing it upon fail-
ure. Another assumption that could be removed from the designis the permanent availability of the network connections. This canbe addressed by (i) partially replicating the data to support discon-nected operation (following the Coda (Kistler and Satyanarayanan,

ystems

1(

pa

••

R

A

B

B

B

B

B

B

B

B

D

R

FG

G

G

G

G

H

I

J

J


992) approach), and (ii) supporting reconnections (like Plan BBallesteros et al., 2007b)).

The present paper has been written and typeset using the Octo-us to combine resources from the environment, Mac OS X, Linux,nd Plan 9 machines.

See also:

http://lsub.org/ls/demos.html.http://lsub.org/ls/octopus.html.

eferences

pple Shiny Droplets. http://www.apple.com/downloads/macosx/productivitytools/shinydroplets.html.

allesteros, F.J., Guardiola, G., Soriano, E., Leal, K., 2005. Traditional systems can workwell for pervasive applications A case study: Plan 9 from Bell Labs becomesubiquitous. In: Proceedings of the IEEE PerCom 2005, pp. 295–299.

allesteros, F.J., Soriano, E., Leal, K., Guardiola, G., 2006a. Plan B: an operating systemfor ubiquitous computing environments. In: Proceedings of the IEEE PerCom2006, pp. 126–135.

allesteros, F.J., Soriano, E., Guardiola, G., Leal, K., 2006b. The Plan B OS for ubiquitouscomputing. Voice, security, and terminals as case studies. Pervasive and MobileComputing Journal 2 (4), 472–488.

allesteros, F.J., Guardiola, G., Soriano, E., Lalis, S., 2007a. Op: Styx batching for highlatency links. In: Proceedings of the 2nd International Workshop on Plan 9, BellLabs, Murray Hill, New Jersey, USA.

allesteros, F.J., Soriano, E., Guardiola, G., Leal, K., 2007b. Plan B: using files instead ofmiddleware abstractions for pervasive computing environments. IEEE PervasiveComputing 3 (6), 58–65.

allesteros, F.J., Guardiola, G., Soriano, E., 2010. Upperware: bringing resources backto the system. In: Proceedings of the PerCom Workshops, Middleware Supportfor Pervasive Computing Workshop 2010, Mannheim, Germany.

aratto, R., Potter, S., Su, G., Nieh, J., 2004. Mobidesk: mobile virtual desktop com-puting. In: Proceedings of the 10th ACM Annual International Conference onMobile Computing and Networking.

ronsted, J., Hansen, K.M., Ingstrup, M., 2010. Service composition issues in pervasivecomputing. IEEE Pervasive Computing 9 (1), 62–70.

orward, S.M., 1997. The Inferno operating system. Bell Labs Technical Journal 2 (1),5–18.

.T. Fielding, 2000. Architectural styles and the design of network-based softwarearchitectures Doctoral dissertation, University of California, Irvine. ISBN:0-599-87118-0.

USE. Filesystem in userspace http://fuse.sourceforge.net.arlan, D., Siewiorek, D., Smailagic, A., Steenkiste, P., 2002. Project Aura: toward

distraction-free pervasive computing. IEEE Pervasive Computing 4, 22–31.hemawat, A.S., Gobioff, A.H., Shun-Tak Leung, A., 2003. The Google File System 19th

ACM Symposium on Operating Systems Principles.ifford, D., Jouvelot, P., Sheldon, M.A., O’Toole Jr., J.W., 1991. Semantic file systems.

ACM SIGOPS Operating Systems Review 25 (5), 16–22.ribble, S.D., et al., 2000. The Ninja architecture for robust Internet scale systems

and services. Computer Networks. Special Issue on Pervasive Computing 35 (4).rimm, R., Bershad, B., 2002. Future directions: system support for pervasive appli-

cations. In: Proceedings of FuDiCo.orey, J., Tournier, J.C., Widener, P., Maccabe, A.B., Kilzer, A., 2008. A filesystem

interface for sensor networks. In: The Fifth Workshop on Embedded NetworkedSensors (HotEmNets 2008).

ntroduction to X10 Home Automation Technology. O’Reilly Media.http://www.oreillynet.com/pub/a/network/2005/01/10/x10 hmhck.html.

ohanson, B., Fox, A., Winograd, T., 2002. The interactive project: experience withubiquitous computing rooms. IEEE Pervasive Computing 2, 71–78.

ujjuri, V., Van Hensbergen, E., Liguori, A., Pulavarty, B., 2010. VirtFSA virtualizationaware File System pass-through. In: Ottawa Linux Symposium 2010, Ottawa,Canada.

and Software 85 (2012) 1637–1649 1649

Killian, T.J., 1984. Processes as files. In: Proceedings of the Summer 1984 USENIXConference.

Kistler, J.J., Satyanarayanan, M., 1992. Disconnected operation in the Coda File Sys-tem. ACM Transactions on Computer Systems 10 (1), 3–25.

Oracle DataBase Secure Files and Large Objects Developers Guide. 11G rel 2. 2009.Pawlowski, B., Noveck, D., Robinson, D., Thurlow, R., 2000. The NFS version 4

protocol. In: Proceedings of the 2nd International System Administration andNetworking Conference SANE 2000.

Pike, R., Ritchie, D.M., 1999. The Styx Architecture for Distributed Systems. Bell LabsTechnical Journal 4 (2), 146–152.

Pike, R., Presotto, D., Thompson, K., Trickey, H., 1990. Plan 9 from Bell Labs. In:Proceedings of the Summer 1990 UKUUG Conference, pp. 1–9.

Protocols for X/Open PC Interworking: SMB, Version 2. Technical Standards. ISBN:1-87263-045-6. 1992.

Roman, M., Hess, C.K., Cerqueira, R., Ranganat, A., Campbell, R.H., Nahrstedt, K.,2002. Gaia: a middleware infrastructure to enable active spaces. IEEE PervasiveComputing 1, 74–82.

Rudolph, L., 2009. A virtualization infrastructure that supports pervasive computing.IEEE Pervasive Computing 8 (4), 8–13.

Saito, Y., Shapiro, M., 2005. Optimistic replication. ACM Computing Surveys 37 (1),42–81.

Satyanarayanan, M., Bahl, P., Caceres, R., Davies, N., 2009. The case for VM-BasedCloudlets in mobile computing. IEEE Pervasive Computing 8 (4), 14–23.

Satyanarayanan, M., 2002. A catalyst for mobile and ubiquitous computing. IEEEPervasive Computing 1 (1), 2–5.

van Steen, M., Homburg, P., Tanenbaum, A.S., 1999. Globe: a wide-area distributedsystem. IEEE Concurrency 7 (1), 70–78.

Weiser, M., 1995. The computer for the 21st century. Scientific American 272 (3),78–89.

Yee, B., Sehr, D., Dardyk, G., Chen, J.B., Muth, R., Ormandy, T., Okasaka, S., Narula, N.,Fullagar, N., 2009. Native Client: a sandbox for portable, untrusted x86 nativecode. In: Proceedings 2009 IEEE Symposium on Security and Privacy.

Yu, P., Cao, J., Wen, W., Lu, J., 2006. Mobile agent enabled application mobilityfor pervasive computing. LNCS. Ubiquitous Intelligence and Computing 4159,648–657.

Prof. Francisco J. Ballesteros leads the Laboratorio de Sistemas at URJC. He receivedhis MS in Computer Science in 1993, and his PhD in Computer Science in 1998,both from the Technical University of Madrid. Currently, he is a professor teach-ing Operating Systems and Computer Programming lectures, and conducts researchon Operating Systems and system software in general. He has a strong backgroundin system software design and development, and has published numerous papersin related fields. Besides being the author of system software for both Plan 9 fromBell Labs and Linux (e.g., the STREAMS framework), he has worked on several otheroperating systems. He developed Off++, a kernel for the 2K operating system, atUIUC. He also designed and implemented the core components of Plan B, the Octo-pus, and NIX (three different operating systems). He is also the author of severalwindow systems, including Omero and O/live, and many other system components.His interests include operating systems, adaptable systems, window systems, filesystem protocols, scuba diving, and sport cars.

Enrique Soriano-Salvador is an associate professor at the Universidad Rey JuanCarlos of Madrid and member of the Laboratorio de Sistemas. He earned his MSin computer engineering in 2002. He received a predoctoral grant (FPI) from theSpanish Government and obtained his PhD from the Rey Juan Carlos University inOctober, 2006. He has been part of the team of Plan B and the Octopus operating sys-tems. He is also author of several research papers on system software, security, andpervasive computing. His research interests include operating systems, distributedsystems, security, and concurrent programming.

Gorka Guardiola is an associate professor at the Universidad Rey Juan Carlos andmember of the Operating Systems Lab (Laboratorio de Sistemas). He received his MSin telecommunication engineering in the Carlos III University in 2003 and his PhD in
computing science from the Universidad Rey Juan Carlos in 2007. He has been partof the team of Plan B and the Octopus operating systems and an active developeron the Plan 9 operating system. He is currently part of the team developing theNix operating system. His research interests include operating systems, concurrentprogramming, embedded computing, pure mathematics and rollerblading.
http://lsub.org/ls/demos.html

http://lsub.org/ls/octopus.html

http://www.apple.com/downloads/macosx/productivity_tools/shinydroplets.html

http://www.apple.com/downloads/macosx/productivity_tools/shinydroplets.html

http://fuse.sourceforge.net

http://www.oreillynet.com/pub/a/network/2005/01/10/x10_hmhck.html

Documents

Octopus: An Upperware based system for building personal pervasive environments