Session 1999-2003 Project Advisor Dr. Mansoor Sarwar ... · Dr. Mansoor Sarwar Submitted By Muneeb...

CONTEXT-AWARE NETWORK SOCKETS

Session 1999-2003

Project Advisor Dr. Mansoor Sarwar

Submitted By

Muneeb Ali 2003-02-0133 Danial Ranjha 2003-02-0233

Sara Shah 2003-02-0180 M. Bilal Siddiqui 2003-02-0113

Department of Computer Science Lahore University of Management Sciences

Lahore

CO

NTEX

T-AW

AR

E NETW

OR

K SO

CK

ETS

BSc

May 30, 2003

Context-Aware Network Sockets

i

A report submitted to the

Department of Computer Science

In partial fulfillment of the requirements for the

Degree

Batchelor of Science Honors

In

Computer Science

By

Muneeb Ali Danial Ranjha

Sara Shah M. Bilal Siddiqui

Lahore University of Management Sciences

May 23, 2003


ii

Acknowledgements This project could not have been possible without the help of a few certain people. Foremost among them is Dr. Mansoor Sarwar, who was there to guide us in each step of the way. He held weekly meetings with us, despite his hectic schedule, so that he could remain updated with our project. It was his genuine and sincere encouragement which made us strive to do even better. We are grateful to Dr. Umar Saif for providing the vision and scope of the project. This project was his brainchild and he helped us through out the journey. Also we are grateful to Dr. Shafay Shumail for coordinating the whole project and for helping in providing expensive special required hardware for the experiments. Thanks also goes to our colleague Bilal Ahmed, whose knowledge in Linux related matters proved invaluable to us. We would also like to thank Tashfeen, who partnered us in our researched of the Cricket location system. Lastly, thanks to our friends and family who have always provided support and motivation to us.

(Signed) Muneeb Ali 2003-02-0133 Danial Ranjha 2003-02-0233 Sara Shah 2003-02-0180 M. Bilal Siddiqui 2003-02-0113 Date May 23, 2003

DISCLAIMER The work described in this BS Thesis is a re-creation of Dr. Umar Saif’s Service Oriented Network Sockets (SONS) work. The reader is referred to the following papers for details on the original work:

• Umar Saif, and Justin Mazzola Paluska, “Service-oriented Network Sockets”, In USENIX Annual Conference on Mobile Systems, Applications, and Services - MobiSys 2003.

• Umar Saif, Justin Mazzola Paluska, and Vijay Praful Chauhan, “Practical Experience with Adaptive Service Access”, In ACM Mobile Computing and Communications Review (MC2R), Jan 2005.

The papers are available from ACM Digital Library and also from the author’s website: URL: http://cag.lcs.mit.edu/~umar/


iii

Abstract

We present the design and implementation of “Context Aware Network Sockets” (CANS). CANS can be used for accessing services/resources in a, dynamically changing, wireless networked environment (a pervasive environment).

As opposed to traditional BSD sockets which require a fixed IP address to connect to a server, CANS take a high-level description of a service and try to connect to the best provider of that service in the rapidly changing mobile environment. CANS handle the case of resources entering and leaving the dynamically changing environment by continuously monitoring, evaluating the available resources and, if needed, migrate the connection to the resource that best satisfy the requirements specified by the application. The connection migration is done using the LCS-MIT Migrate protocol.

Context Aware Network Sockets are based on an extensible architecture to leverage the wide-range of emerging technologies for discovering and locating resources in a mobile system. CANS integrate a service-oriented abstraction with the traditional operating system interface for accessing network services, making it simpler to develop pervasive, mobile applications.

Opposed to the current MIT Project Oxygen standard INS (Intentional Naming System) which is a content-based routing system, CANS is an end-host system functioning at the session-layer. The advantage of having an end-host system performing the resource discovery is that the resource discovery is not done in the critical path of routing and more complex queries could be performed in comparison to the mere pattern match of INS.

CANS extend the traditional BSD sockets by using TESLA which catches all network I/O calls of applications at the session layer and allows the insertion of arbitrary layers at the session layer. CANS use the underlying traditional sockets for performing some of their operations and they are compatible with all traditional applications.


iv

List of Figures Figure 1: TCP Connection Migration ................................................................................................. 21 Figure 2: Cricket Beacon ................................................................................................................... 27 Figure 3: Cricket Listener .................................................................................................................. 27 Figure 4: Discovering The DA ........................................................................................................... 29 Figure 5: CANS Inserted At Session Layer using TESLA ................................................................. 50 Figure 6: CANS Code Of SETSOCKOPT() ....................................................................................... 52 Figure 7: CANS API ........................................................................................................................... 53 Figure 8: LAG Beacon Unit ................................................................................................................ 57 Figure 9: LAG Hand-Held Unit ........................................................................................................... 57 Figure 10: LAG Beacon ...................................................................................................................... 58 Figure 11: SSH Application Successfully Running With CANS ........................................................ 62


v

Table of Contents

Statement Of Submission ......................................................................................................................i Acknowledgements ...............................................................................................................................ii Abstract................................................................................................................................................. iii List Of Figures ......................................................................................................................................iv Table Of Contents..................................................................................................................................v Chapter 1: Introduction .............................................................................................................. ………1 1.1 Pervasive Computing .................................................................................................... ………2 1.1.1 Introduction................................................................................................................. ………2 1.1.2 Defining Pervasive Computing ................................................................................... ………2 1.1.2.A Effective Use of Smart Spaces ............................................................................ ………2 1.1.2.B Invisibility......................................................................................................................... 3 1.1.2.C Localized Scalibility......................................................................................................... 3 1.1.2.D Masking Uneven Conditioning ........................................................................................ 3 1.2 System Directions For Pervasive Computing Applications ...................................................... 4 1.2.1 Data And Functionality .......................................................................................................... 4 1.2.2 Programming For Change..................................................................................................... 5 1.2.3 The Need For A Common Platform....................................................................................... 5 1.3 Project Oxygen ......................................................................................................................... 6 1.3.1 Introduction................................................................................................................. ………6 1.3.2 Devices And Networks ............................................................................................... ………7 1.3.2.A E21 – Stationary Devices......................................................................................... ……7 1.3.2.B H21 – Hand-held Devices .................................................................................... ………7 1.3.2.C N21 – Networks ................................................................................................... ………7 1.3.3 Software Architecture ................................................................................................. ………8 1.3.4 Spoken Language, Sketching And Visual Clues........................................................ ………8 1.3.5 Knowledge Access ..................................................................................................... ………8 1.3.6 OXYGEN Today ......................................................................................................... ………8 Chapter 2: Problem Statement ................................................................................................ ………10 2.1 Challenges Facing An Application Model For Pervasive Computing..................................... 11 2.1.1 Design-Time ........................................................................................................................ 11 2.1.1.A Programming Model........................................................................................... ………11 2.1.1.B Development Methodology ................................................................................ ………12 2.1.2 Load-Time ................................................................................................................ ………12 2.1.2.A Dynamic Discovery ............................................................................................ ………13 2.1.2.B Requirements And Capability Negotiation ......................................................... ………13 2.1.2.C Presentation Selection, Adaptation and Composition ....................................... ………13 2.1.3 Run-Time.................................................................................................................. ………14 2.1.3.A Monitering And Redistribution............................................................................ ………14 2.1.3.B Disconnection..................................................................................................... ………15 2.1.3.C Failure Detection And Recovery ........................................................................ ………15 Chapter 3: Background Research ........................................................................................... ………16 3.1 Intentional Naming System (INS) ................................................................................ ………17 3.1.1 Name Syntax ............................................................................................................ ………17 3.1.2 Self-Configering Resolvers....................................................................................... ………17 3.1.3 Late Binding.............................................................................................................. ………17 3.1.4 Name Discovery ....................................................................................................... ………18


vi

3.1.5 Scaling.................................................................................................................... ………19 3.1.5.A Domain Space Resolvers .................................................................................. ………19 3.1.5.B Partitioned Virtual Spaces.................................................................................. ………20 3.2 Migrate......................................................................................................................... ………20 3.2.1 Session Layer........................................................................................................... ………21 3.2.2 TCP Connection Migration ....................................................................................... ………21 3.3 TESLA ......................................................................................................................... ………22 3.3.1 Introduction............................................................................................................... ………22 3.3.2 Architecture .............................................................................................................. ………24 3.3.2.A Interposition........................................................................................................ ………24 3.3.2.B The Flow_Handler API....................................................................................... ………24 3.3.2.C Handler Method Semantics ............................................................................... ………24 3.3.2.D Process Management........................................................................................ ………24 3.3.3 Session Migration in TELSA..................................................................................... ………25 3.4 Cricket.......................................................................................................................... ………26 3.4.1 Introduction............................................................................................................... ………26 3.4.2 Technology ............................................................................................................... ………27 3.4.3 Results...................................................................................................................... ………27 3.5 OpenSLP: Resource Discovery................................................................................... ………28 3.5.1 The Available Options .............................................................................................. ………28 3.5.2 Service Location Protocol (SLP) .............................................................................. ………29 3.5.2.A Discovery of The Directory Agent ...................................................................... ………29 3.5.2.B Operational Modes............................................................................................. ………29 3.5.2.C Service Advertisments ....................................................................................... ………30 3.5.2.D Operation In Larger Network Enviornments ...................................................... ………30 3.3.2.E Additional Features ............................................................................................ ………31 3.5.3 Jini ............................................................................................................................ ………31 3.5.4 Salutation.................................................................................................................. ………31 3.5.5 Universal Plug n Play (UPnP) .................................................................................. ………32 3.5.6 Bluetooth Service Discovery Protocol (SDP) ........................................................... ………32 3.5.7 A Comparision of SLP, Jini, Salutation and UPnP ................................................... ………32 3.5.7.A Evalutaion of UPnP............................................................................................ ………32 3.5.7.B Evalutaion of Salutation ..................................................................................... ………32 3.5.7.C Evalutaion of Jini................................................................................................ ………33 3.5.7.D Evalutaion of SLP .............................................................................................. ………33 Chapter 4: Final Problem Statement ....................................................................................... ………34 Chapter 5: Requirements And Analysis .................................................................................. ………36 Chapter 6: Prototype ............................................................................................................... ………38 Chapter 7: Analysis, Design, Implementation ......................................................................... ………41 7.1 Introduction.................................................................................................................. ………42 7.2 CANS Architecture ...................................................................................................... ………42 7.2.1 Main Module (Nano-Kernel) ..................................................................................... ………42 7.2.2 Evaluator Module...................................................................................................... ………43 7.2.3 Resource Discovery Module..................................................................................... ………45 7.2.4 CANS Resource Discovery Framework ................................................................... ………46 7.2.4.A Conctext of Discovery ........................................................................................ ………47 7.2.4.B Probing Vs Advertising....................................................................................... ………47 7.2.4.C Directory-Based Vs Peer-to-Peer Discovery ..................................................... ………48 7.2.5 Connection Migration Module................................................................................... ………48 7.3 Implementation Of CANS ............................................................................................ ………49 7.4 LAGS: Design And Implementation............................................................................. ………54 7.4.1 LAGS Hardware ....................................................................................................... ………54 7.4.1.A LAPE Beacon Unit ............................................................................................. ………54


vii

7.4.1.B The Microprocessor ........................................................................................... ………54 7.4.1.C RF Module ......................................................................................................... ………54 7.4.1.D Display Module .................................................................................................. ………54 7.4.1.E Communications Module ................................................................................... ………55 7.4.2 LAGS Optimization and Tradeoffs............................................................................ ………55 Chapter 8: Results ................................................................................................................... ………59 Chapter 9: Conclusion And FutureWork.................................................................................. ………63 Chapter 10: References .......................................................................................................... ………66 Appendix 1 The Cricket Location Support System.................................................................. ………69 Appendix 2 The Design and Implementation of an intentional naming system ...................... ………81 Appendix 3 An End-to-End Approach to Host Mobility............................................................ ………97 Appendix 4 TESLA: A Transparent, Extensible Session-Layer Architecture .......................... ………93


viii


ix


1

Chapter 1 Introduction


2

1.1 Pervasive Computing 1.1.1 Introduction ‘‘The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it’’ [1]. This describes perfectly the vision held about ubiquitous computing, now also called pervasive computing. Pervasive computing promises a computing infrastructure that seamlessly and ubiquitously aids users in accomplishing their tasks and that renders the actual computing devices and technology largely invisible. The basic idea behind pervasive computing is to deploy a wide variety of smart devices throughout our working and living spaces. These devices coordinate with each other to provide users with universal and immediate access to information and support users in completing their tasks. When first introduced, this was a vision too far ahead of its time since the hardware technology needed to achieve it simply did not exist at that time. Many critical elements of pervasive computing that were once considered rare are now viable commercial products: handheld and wearable computers; wireless LANs; and devices to sense and control appliances. Also pervasive computing projects have emerged at major universities and in industry. Examples of universities include Project Aura at Carnegie Mellon, Endeavour at UC Berkeley, Oxygen at MIT, and Portalano at Washington. Industry examples include work at AT&T Research in Cambridge, U.K. and at the IBM TJ Watson Research Center. Each of these projects addresses a different mix of issues in pervasive computing, and a different blend of near-term and far-term goals. Together, they represent a broad communal effort to make pervasive computing a reality. 1.1.2 Defining Pervasive Computing The study done and the advances made in the fields of distributed systems and mobile computing have contributed a lot towards pervasive computing itself. Since motion is an integral part of everyday life, a technology such as pervasive computing must support mobility; otherwise, a user will be acutely aware of the technology by its absence when he moves. Hence, the research agenda of pervasive computing subsumes that of mobile computing, but goes much further. Specifically, pervasive computing incorporates four additional research thrusts into its agenda: 1.1.2.A Effective Use of Smart Spaces A space may be an enclosed area such as a meeting room or corridor, or it may be a well-defined open area such as a courtyard or a quadrangle. By embedding computing infrastructure in building infrastructure, a smart space brings together two worlds that have been disjoint until now. The fusion of these worlds enables sensing and control of


3

one world by the other. A simple example of this is the automatic adjustment of heating, cooling and lighting levels in a room based on an occupant’s electronic profile. Influence in the other direction is also possible — software on a user’s computer may behave differently depending on where the user is currently located. Smartness may also extend to individual objects, whether located in a smart space or not. 1.1.2.B Invisibility The ideal situation is complete disappearance of pervasive computing technology from a user’s conciousness. In practice, a reasonable approximation to this ideal is minimal user distraction. If a pervasive computing environment continuously meets user expectations and rarely presents him with surprises, it allows him to interact almost at a subconcious level. At the same time, a modicum of anticipation may be essential to avoiding a large unpleasant surprise later — much as pain alerts a person to a potentially serious future problem in a normally-unnoticed body part. 1.1.2.C Localized Scalability As smart spaces grow in sophistication, the intensity of interactions between a user’s personal computing space and his surroundings increases. This has severe bandwidth, energy and distraction implications for a wireless mobile user. The presence of multiple users will further complicate this problem. Scalability, in the broadest sense, is thus a critical problem in pervasive computing. Previous work on scalability has typically ignored physical distance — a web server or file server should handle as many clients as possible, regardless of whether they are located next door or across the country. The situation is very different in pervasive computing. Here, the density of interactions has to fall off as one moves away — otherwise both the user and his computing system will be overwhelmed by distant interactions that are of little relevance. 1.1.2.D Masking Uneven Conditioning This is the development of techniques for masking uneven conditioning of environments. The rate of penetration of pervasive computing technology into the infrastructure will vary considerably depending on many non-technical factors such as organizational structure, economics and business models. There will and are huge differences in the ‘‘smartness’’ of different environments — what is available in a well-equipped conference room, office, or classroom may be more sophisticated than in other locations. This large dynamic range of ‘‘smartness’’ can be jarring to a user, detracting from the goal of making pervasive computing technology invisible. One way to reduce the amount of variation seen by a user is to have his personal computing space compensate for ‘‘dumb’’ environments. Complete invisibility may not be possible for some time, but reduced variability is well within the reach.


4

1.2 System Directions for Pervasive Computing Applications Though the hardware devices and networking infrastructure necessary to realize the vision of pervasive computing are increasingly becoming a reality, yet precious few applications run in this infrastructure. Notable exceptions are email for communication and the World Wide Web as a medium for electronic publishing and as a client interface to multi-tier applications. This lack of applications is directly related to the fact that it is difficult to design, build, and deploy applications in a pervasive computing environment. The pervasive computing space has been mapped as a combination of mobile and stationary devices that draw on powerful services embedded in the network to achieve users’ tasks. The result is a giant, ad-hoc distributed system, with tens of thousands of devices and services coming and going. Consequently, the key challenge for developers is to build applications that continue to provide useful services, even if devices are roaming across the infrastructure and if the network provides only limited services or none at all. According to [3], existing distributed computing technologies are ill-suited to meet this challenge. This is not to say that discovery services or application-aware adaptation are not useful in a pervasive computing environment. On the contrary, we consider them clearly beneficial for pervasive computing applications. However, they are not sufficient to successfully design, build, and deploy applications in the pervasive computing space. The current approaches to building distributed applications are deeply flawed along three axes, which [3] calls fault lines. These concern: 1.2.1 Data and Functionality The first fault line concerns the relationship between data and functionality and how they are represented. Several distributed systems are targeted at a global computing environment and have explored the use of objects as the unifying abstraction for both data and functionality. The problem with that is twofold, First, objects as an encapsulation mechanism are based on two assumptions: (1) Implementation and data layout change more frequently than an object’s interface, and (2) it is indeed possible to design interfaces that accommodate different implementations and hold up as a system evolves. However, these assumptions do not hold for a global distributed computing environment. Increasingly, common data formats, such as HTML or PNG, are specified by industry groups or standard bodies, notably the World Wide Web Consortium, and evolve at a relatively slow pace. In contrast, application vendors compete on functionality, leading to considerable differences in application interfaces and


5

implementations and a much faster pace of innovation. Second, it is preferable to store and communicate data instead of objects, as it is generally easier to access passive data rather than active objects. Its argued that for pervasive computing data and functionality should be kept separate rather then encapsulating both in objects. At the same time, data and functionality depend on each other, especially when considering data storage and mobile code. On one hand, data management systems already rely on mobile code for their services. On the other hand, mobile code systems have seen limited success in the absence of a standard data model and the corresponding data management solutions. The result is considerable tension between integrating data and functionality too tightly — in the form of objects — and not integrating them tightly enough. Basically data and functionality need to be supported equally well in large distributed systems, yet also need to be kept separate. 1.2.2 Programming for Change The second fault line is caused by transparent access to remote resources. By building on distributed file systems or remote procedure call packages, many existing distributed systems mask remote resources as local resources. This transparency certainly simplifies application development. From the programmer’s viewpoint, accessing a remote resource is as simple as a local operation. However, this comes at a cost in failure resilience and service availability. Network connections and remote servers may fail. Some services may not be available at all in a given environment. As a result, if a remote service is inaccessible or unavailable, distributed applications cannot provide their services, because they were written without the expectation of change. In [3], its suggested that this transparency is misleading in a pervasive computing environment, because it encourages a programming style in which a failure or the unavailability of a resource is viewed as an extreme case. But in an environment where tens of thousands of devices and services come and go, the unavailability of some resource may be the common (or at least frequent) case. They are thus advocating a programming style that forces applications to explicitly acquire all resources, be they local or remote, and to be prepared to reacquire them or equivalent resources at any time. This style of programming for change imposes a strict discipline on applications and their developers. Yet, programming for change also presents an opportunity by enabling system services that make it easier to build applications. 1.2.3 The Need for a Common Platform The third fault line is rooted in the considerable and inherent heterogeneity of devices in a pervasive computing environment. Computing devices already cover a wide range


6

of platforms, computing power, storage capacity, form factors, and user interfaces. This heterogeneity is expected to increase over time rather than decrease, as new classes of devices such as pads or car computers become widely used. Today, applications are typically developed for specific classes of devices or system platforms, leading to separate versions of the same application for hand-helds, desktops, or cluster-based servers. As heterogeneity increases, developing applications that run across all platforms will become exceedingly difficult. As the number of devices grows, explicitly distributing and installing applications for each class of devices and processor family will become unmanageable, especially in the face of migration across the wide area. We thus argue for a single application programming interface (API) and a single binary distribution format, including a single instruction set, which can be implemented across the range of devices in a pervasive computing environment. A single, common API makes it possible to develop applications once, and a single, common binary format enables the automatic distribution and installation of applications. 1.3 Project Oxygen 1.3.1 Introduction Oxygen in itself is nothing more than a project at MIT, but it is hailed as the “Next Computing Jump”, revolutionary enough to change the way people live their daily lives faster than the Internet did. Basically Oxygen is a project relating to Pervasive Computing and there are other projects like Oxygen going on in the world right now as well, Project Aura at University of California Berkeley is one of them. The Oxygen technologies work together and pay attention to several important themes:

• Distribution and mobility — for people, resources, and services. • Semantic content — what we mean, not just what we say. • Adaptation and change — essential features of an increasingly dynamic

world. • Information personalities — the privacy, security, and form of our

individual interactions with Oxygen. Oxygen is an integrated software system that will reside in the public domain. Its development is sponsored by DARPA and the Oxygen Alliance of industrial partners, who share its goal of pervasive, human-centered computing. Realizing that goal will require a great deal of creativity and innovation, which will come from researchers, students, and others who use Oxygen technologies for their daily work during the course of the project. The lesCANS they derive from this experience will enable Oxygen to better serve human needs.


7

1.3.2 Vision For forty years, computer systems have catered to machines. Purporting to serve people, they actually have forced people to serve them. They have been difficult to use. They have required us to interact with them on their terms, speaking their languages and manipulating their parts. They have not been aware of our needs or even of whether we were in the room with them. In the future, computation will be human-centered: it will enter the human world, handling our goals and needs and helping us to do more by doing less. Computation will be pervasive, like batteries, power sockets, and the oxygen in the air we breathe. Configurable generic devices, either handheld or embedded in the environment, will bring computation to us, whenever we need it and wherever we might be. As we interact with these “anonymous” devices, they will adopt our information personalities. They will respect our desires for privacy and security. We won’t have to type, click, or learn new computer jargon. Instead, we’ll communicate naturally, using speech and gestures that describe our intent (“send this to Hari” or “print that picture on the nearest un-congested Printer”), and leave it to the computer to carry out our will. New systems will boost our productivity. They will help us automate repetitive human tasks, control a wealth of physical devices in our environment, find the information we need (when we need it, without forcing our eyes to examine thousands of search-engine hits), and enable us to work together with other people through space and time. To support highly dynamic and varied human activities, the Oxygen system must master a number of technical challenges. It must be accessible anywhere. It must adapt to change, both in user requirements and in operating conditions. It must never shut down or reboot — components may come and go in response to demand, errors, and upgrades, but Oxygen as a whole must be available all the time. Advances in digital electronics coupled with revolution in the communication technology have made possible building human-computer interactive environments where mobile users can have ubiquitous access to versatile services. This new frontier of Computer Science is known as “Pervasive Computing” or “Ubiquitous Computing”. 1.3.3 Devices and Networks People access Oxygen through stationary devices (E21s) embedded in the environment or via portable hand-held devices (H21s). These universally accessible devices supply power for computation, communication, and perception in much the same way that wall outlets and batteries deliver power to electrical appliances. Although not customized to any particular user, they can adapt automatically or be modified explicitly to address specific user preferences. Like power outlets and batteries, these devices differ mainly in how much energy they can supply.


8

1.3.3.A E21 - Stationary Devices Embedded in offices, buildings, homes, and vehicles, E21s enable us to create situated entities, often linked to local sensors and actuators, that perform various functions on our behalf, even in our absence. For example, we can create entities and situate them to monitor and change the temperature of a room, close a garage door, or redirect email to colleagues, even when we are thousands of miles away. E21s provide large amounts of embedded computation, as well as interfaces to camera and microphone arrays, thereby enabling us to communicate naturally, using speech and gesture, in the spaces they define. 1.3.3.B H21 – Hand-held Devices Users can select hand-held devices, called H21s, appropriate to the tasks they wish to perform. These devices accept speech and visual input, can reconfigure themselves to perform a variety of useful functions, and support a range of communication protocols. Among other things, H21s can serve as cellular phones, beepers, radios, televisions, geographical positioning systems, cameras, or personal digital assistants, thereby reducing the number of special-purpose gadgets we must carry. To conserve power, they may offload communication and computation onto nearby E21s. 1.3.3.C N21 – Networks N21s support dynamically changing configurations of self-identifying mobile and stationary devices. They allow us to identify devices and services by how we intend to use them, not just by where they are located. They enable us to access the information and services we need, securely and privately, so that we are comfortable integrating Oxygen into our personal lives. N21s support multiple communication protocols for low-power local, building-wide, and campus-wide communication, enabling us to form collaborative regions that arise, adapt, and collapse as needed. 1.3.4 Software Architecture Oxygen’s software architecture supports change above the device and network levels. The software architecture matches current user goals with currently available software services, configuring those services to achieve the desired goals. When necessary, it adapts the resulting configurations to changes in goals, available services, or operating conditions. Thereby, it relieves users of the burden of directing and monitoring the operation of the system as it accomplishes their goals. Several important technologies harness Oxygen’s pervasive computational, communication, and perceptual resources to advance the human-centered goal of enabling people to accomplish more with less effort:


9

1.3.5 Spoken Language, Sketching and Visual Cues Spoken language and visual cues, rather than keyboards and mice, define the main modes of interaction with Oxygen. By integrating these two technologies, Oxygen can better discern our intentions, for example, by using vision to augment speech understanding through the recognition of facial expressions, gestures, lip movements, and gaze. These perceptual technologies are part of the core of Oxygen, not just afterthoughts or interfaces to separate applications. They can be customized quickly in Oxygen applications to make selected human-machine interactions easy and natural. Graceful switching between different domains (e.g., from a conversation about the weather in Rome to one about airline reservations) supports seamless integration of applications. 1.3.6 Knowledge Access Individualized knowledge access technologies offer greatly improved access to information — customized to the needs of people, applications, and software systems. Universal access to information is facilitated through annotations that allow content-based comparisons and manipulations of data represented in different formats and using different terminologies. Users may access their own knowledge bases, those of friends and associates, and other information publicly available on the Web. , easy-to-use, customizable, and 1.3.7 OXYGEN Today • Distribution and mobility. The Cricket location support system provides an indoor

analog of GPS. The Intentional Naming System (INS) provides resource discovery based on what services do, rather than where they are located. The Self-Certifying (SFS) and Cooperative (CFS) File Systems provide secure access to data over distrusted networks without requiring centralized control.

• Perceptual interfaces. Multimodal systems enhance recognition of both speech and

vision. Multilingual systems support dialogs among participants speaking different languages. The SpeechBuilder utility supports development of spoken interfaces. Person tracking, face, gaze, and gesture recognition utilities support development of visual interfaces. Systems that understand sketching on white boards provide more natural interfaces to traditional software packages.

• Semantic content. Haystack and the Semantic Web support personalized information

management and collaboration through metadata management and manipulation. ASSIST helps extract design rationales from simple sketches.


10

• Security and privacy. Trusted software proxies provide secure, private, and efficient access to networked and mobile devices and people. Decentralization in Oxygen aids privacy: users can locate what they need without having to reveal their own location.

• Software and hardware architectures. MetaGlue is a robust architecture for

software agents. The GOALS ystem integrates software services to accomplish user-defined goals. RAW and Scale expose hardware to compilers, which optimize the use of circuitry and power. StreamIt provides a language and optimizing compiler for streaming applications.


11

CHAPTER 2 PROBLEM STATEMENT


12

2.1 Challenges Facing an Application Model for Pervasive Computing

Pervasive computing is maturing from its origins as an academic research area to a commercial reality. This transition has not been a smooth one and the term itself, pervasive computing, still means different things to different people. To model the applications needed for pervasive computing, it is necessary to consider the lifecycle of an application. This lifecycle can be divided into three parts: design-time, load-time and run-time. The authors of [4] present a new application model from the perspectives of application design-time, load-time and run-time. They show how the attributes of the new model support the precepts “device as portal", “application as task" and “physical surroundings as computing environment". 2.1.1 Design Time If “devices are portals" as the authors suggest, then the application should not be written with a specific device in mind. The developer should not make any assumptions about the screen size or device capabilities, or even that there is a screen at all. The user interface of the application must not include any information specific to a device or set of devices. Instead, the application front-end should be device-neutral. If the environment of an application is to be context aware, then the developer should not make assumptions about the services that are available. Services that the application needs in order to run should not be explicitly named, but rather specified in an abstract manner. Furthermore, there may be services available to the application at run-time that are not known or available to the developer at design-time, but may be useful for the task. Applications should be able to use such services. When appropriate, the designer can abstractly specify optional services that, if present at run-time, enhance the application. 2.1.1.A Programming Model The programming model must allow for the description of abstract user interfaces and abstract services. The structure of the program should be described in terms of tasks and subtasks. The granularity at which these tasks are presented to the user is a load-time issue, and therefore the relationship among the tasks must be rich enough that the user interface can be actualized at the various granularities. This relationship is named navigation, as it specifies how the user will navigate the sub-tasks that make up the application. The challenges for this programming model are:


13

• Identifying abstract interaction elements. These abstract interaction elements must capture user intent, not device mechanism. That is, base elements of user interaction must abstract away the differences in the devices.

• Specifying an abstract service description language. Application logic may

use existing services or infrastructure, as well as service instances unanticipated by the designer. A means is needed to express the expected function of a service, allowing for different services to provide this function when the application is running. This must allow for services to be declared optional as well.

• Creating a task-based model for program structure. The application should

be delineated into tasks and subtasks. A task includes the abstract interaction and the application logic, including the use of the services. The structure is used by the system to generate device specific “presentation units"; e.g., screens.

• Creating a navigation model. The navigation specifies what causes a task

to begin and end (e.g., a user action), and what tasks precede and follow it. This information is complementary to the task structure, and is used by the system to automate the flow of the “presentation units" when the application is running.

2.1.1.B Development Methodology The purpose of a development methodology is to take the developer through a step-by-step process of realizing the application from a set of requirements. An ideal methodology for building an application is to focus on the user task, rather than the user's interaction with an interface on a specific device in a specific environment. The major challenge here is to build a development environment that supports the above methodology. This methodology is not captured by current programming tools. Certain parts of the methodology, such as navigational flow, may lend themselves to visual interfaces, whereas others such as scripting logic may not. 2.1.2 Load-Time An application model derived from the basis of the three precepts requires a more dynamic load-time approach than is traditionally supported. Devices must dynamically discover what applications are available, and the system must adapt the applications to the device resources available. An application must be specified in terms of its requirements, the device must be described in terms of its capabilities, and some


14

mediating algorithm must be used to negotiate a match between these competing constraints. To realize the concepts of “application as task" and “physical surroundings as computing environment"[4], the system must be dynamic at load-time. That is, the tasks that a user wishes to perform may depend on the physical surroundings. Such tasks are enabled by contextual services. The system must, therefore, be able to discover and compose the services that are available in the physical environment, in order to perform desired tasks. This is in contrast to today's model, where applications are loaded onto a device manually from a CD or other storage medium, and managed by the user rather than the system. 2.1.2.A Dynamic Discovery Applications and services live in the surrounding physical distributed environment. Discovery mechanisms allow a mobile device to dynamically identify and enumerate the applications and services in its local vicinity. The major challenge posed by dynamic discovery is the definition of a service adaptation layer. A standard definition is needed, to both hide the differences between heterogeneous service frameworks and to maximize the use of legacy code. 2.1.2.B Requirements and Capability Negotiation At load-time, a device needs to negotiate with a server that hosts applications and services for several reasons. First, the device may not have all of the resources needed to run some of the applications and services. The set of available software needs to be pruned so that only the hostable functions are presented to the user. Second, application performance is a concern, so it may be desirable to split the execution burden between the device and available servers. This split, which we call apportioning, uses information about the currently available resources and the resource demands of the application. 2.1.2.C Presentation Selection, Adaptation and Composition A good user interface must exhibit qualities such as consistency and style, which are difficult to quantify and synthesize. Indeed these qualities are subject to human taste. These qualities are embodied differently on devices with different interface modalities and form factors (e.g., a graphical input device versus one with a speech interface). Thus, it may be desirable to have multiple abstract representations of the application interface, one for each combination of interface modality and form factor. These will most likely need to be generated by human designers, perhaps through semi-automated tools. Challenges facing this are:

• The system needs to support dynamic selection of an appropriate application interface from a set of available interfaces, based on the device's resources and form-factor.


15

• The system needs to seamlessly integrate the applications and services

found in the environment. This involves composing the functionality (e.g., a discovered map application should be able to use a discovered GPS service) as well as the user interface.

2.1.3 Run-Time To realize the precept “device as portal," the run-time must monitor the resources for the currently active portal, or portal set, and appropriately adapt the application to those resources. In addition, the run-time must respond to changes initiated by the user. For example, the user may choose a different set of portal devices. To realize “application as task," the run-time must allow a user to initiate and perform a task in an uninterrupted manner, despite changes in the environment and portal devices. The run-time should support handoff of task context from one environment (e.g., office) to another (e.g., car), possibly through a disconnected state. The key to supporting a task-oriented application is that a user's access to the task be continuous. To realize “physical surroundings as computing environment," the run-time must be able to take advantage of services provided by the environment and the physical resources available within it. The run-time must handle unexpected failures, such as exhausting batteries or a service crash. Existing failure detection and recovery mechanisms may need to be re-examined for their applicability in this new paradigm. 2.1.3.A Monitoring and Redistribution The application model proposed in this paper requires the run-time to detect changes in the resources of any portal device or environment hosts that participate in application execution. Resource changes include changes in available network bandwidth, introduction of new devices into the environment, introduction of new users and/or applications, etc. In response to detected changes, the run-time must initiate a reapportionment and/or relocation of application components. The challenges introduced by this monitoring and redistribution include:

• Non-obtrusive re-apportioning. Resource changes may impact the user's interaction with the application. However, some changes may be transient and unseen by the user. Transient resource changes should be recognized as such and should not impact the application. When changes are significant and long-lived, the application should be automatically re-apportioned, with minimal impact on the user.

• User initiated re-apportioning. The user may initiate re-apportionment of the

application. Reasons for re-apportionment may range from anticipated change in


16

the connectivity of devices to a mobile user entering the proximity of new devices.

2.1.3.B Disconnection One of the resources that must be considered when making apportionment decisions is the communication network. If the network connection between client and server is detected to degrade via run-time monitoring, the apportioner may react by migrating code from the server to the client to reduce the application's demand for communication. In this way, a running application can react to dynamic changes in the quality of the network connection. For some applications and devices, it may be feasible to migrate the entire application to the client in order to accommodate brief, sporadic network disconnections. However, this approach is not viable for devices with limited resources, or for sudden, unanticipated network disconnections. Because of this, explicit support for disconnected operation needs to be added to the model. In other words, the model needs to be augmented in order to bridge the desire of using a device (along with its accompanying resource limitations) as a portal while minimizing the impact of network disconnections. The major challenge in this area is automating disconnection and reconnection as much as possible. The run-time should prepare for disconnection without a user's intervention whenever possible (e.g., automatic migration as described above). For those scenarios where user intervention is needed, there should be a natural way for a user to prepare for disconnection, minimizing overall task disruption. 2.1.3.C Failure Detection and Recovery Many existing failure detection and recovery techniques may be applicable to pervasive environments. However, they may need to be modified to better serve the particular requirements of these environments. Some challenges to this are regarding adapting check-pointing strategies. Requirements on the type and timing of check-pointing required for pervasive environments may be different from the current state of the art. Secondly, the distinction between failure and disconnection is often blurred in conventional systems. In this application model, the distinction is important. Disconnections should not be treated as failures, as they are part of the expected specification of the environment.


17

CHAPTER 3 BACKGROUND RESEARCH


18

3.1 Intentional Naming System (INS) A classic work from Professor Hari at LCS MIT, INS is to Oxygen what DNS is to the internet. INS is an abbreviation of Intentional Naming Service, as apparent from the name the main aim of the protocol is to enable resources to be accessed without knowledge of their actual physical location i.e. IP address. It is a resource discovery protocol and is currently heavily used in pervasive environments to locate and use resources. It has the following interesting characteristics about the way it names resources and the way names are resolved.

3.1.1 Name Syntax

Names are intentional; they describe application intent in the form of properties and attributes of resources and data, rather than simply network locations of objects (which is the way most traditional naming systems like the DNS work today). Names express and satisfy queries about information and their providers. One can think of these names as properties and queries expressed in a language similar to XML. Intentional names are query expressions (in INS, they are called name-specifiers) in a carefully designed query language supporting exact matches of arbitrary application-specified attributes (variables) and values. Our design also includes other operators for range matches. However, the name resolution architecture in INS is largely independent of the naming syntax (except in how lookups work) and incorporate ideas that generalize to other ways of naming resources as well.

3.1.2 Self-Configuring Resolvers

INS resolvers are called Intentional Name Resolvers, or INRs. In any domain, INRs configure themselves into an application-level overlay network based on performance metrics and exchange meta-data about names and the corresponding network locations. The configuration protocols will enable the system to work with no manual intervention, incorporating machinery to bootstrap INRs, spawn and terminate INRs, maintain neighbor relationships, and perform load management across both the local and wide-area Internet.

3.1.3 Late Binding

INS advocates the integration of name resolution and message forwarding. In this mode, applications name resources they seek (in any syntax, e.g., in XML-like descriptions) and


19

these messages, piggybacked with application payload, traverse the resolver overlay network (configured automatically by the above protocols) and get looked-up and forwarded amongst the INRs before being delivered to the node(s) that satisfy the names. Thus, resolvers affect routing decisions, leading to a flexible data delivery mechanism that allows applications to track rapid change (e.g., user or network mobility), changing data attributes. The level of indirection provided by these names allows us to handle mobility, group communication, and service replication. It also allows applications to influence routing decisions by having resolvers route on the basis of application-specific metrics like load on servers. Of course, INS also supports early bindings of names to locations, where an INR returns a list of end-hosts (typically a set of IP addresses) corresponding to the name, without forwarding messages to them. This is useful, in ensuring that an application can bind to the same end node(s) if it so desires; for example, after using INS to get to the closest, least loaded printer near you, you'd like to have all the pages of your file print out on the same printer!

3.1.4 Name Discovery

To learn and share information about names, the INRs communicate via a name discovery protocol. The protocol uses periodic updates to convey name information, and uses triggered updates for fast changes. In addition, INS incorporates a novel optimization to implicitly learn about names by inferring information from source message headers of messages traversing the INR network. To achieve robustness and availability, INRs exchange name information much like IP routers exchange network routes, treating names as soft state, using periodic refreshes to achieve eventual consistency on change.

3.1.5 Scaling

In addition to achieving the above properties, an important challenge in INS is scaling to a large number ("millions") of names and services across the Internet. Unlike IP routing which relies almost solely on hierarchy to scale well, INS cannot, because of names aren't necessarily hierarchical. To combat this, INS uses two ideas to scale the system:

3.1.5.A Domain Space Resolvers (DSRs)

Names are administratively scoped with administrative zones, much like DNS names. The default scope for an intentional name is the zone in which it was created, e.g., lcs.mit.edu. Each domain will have a set of "external" resolvers (DSRs) that will


20

exchange information in a concise way about services in its domain that are reachable from the outside.

3.1.5.B Partitioned Virtual Spaces

Since names need not be hierarchical within an administrative zone (in general they could be hierarchies of orthogonal attributes and values), we partition the entire namespace amongst INRs, with each INR having to only resolve for a subset of all the active virtual spaces in a domain. A virtual space is an arbitrary, application- or user-chosen description of the "class" to which a name belongs, such as "cameras," "printers," "fax machines," "students in 6.033 in spring 2000," and so forth. DSRs maintain a soft-state cache of active (and dormant) INRs in a domain and a mapping between virtual spaces and INRs.

To summarize, the INS resolver architecture consists of a wide-area inter-domain resolver network of DSRs and an intra-domain self-configuring resolver network composed of INRs. It integrates resolution and forwarding that tracks change, and uses soft-state name discovery protocols that enable robust operation.

3.2 Migrate

Migrate also known as End-to-End Approach to host mobility, is a new end-to-end framework for Internet mobility being developed at MIT's Lab for Computer Science. By providing a unified framework to support address changes and disconnectivity, Migrate allows legacy applications to adapt to today's highly-mobile environment, and provides mobile-aware applications with a robust set of system primitives for disconnectivity support, resource conservation, and rapid re-instantiation of network connections. Unlike current Internet mobility solutions, Migrate treats disconnection as a fundamental component of mobility, and enables applications to gracefully reduce their resource consumption during periods of disconnection and rapidly resume sessions upon reconnection.

Migrate, basically extends the TCP/IP protocol to support transparent session migration. At connection time the client sends a Migrate enabled signal with the SYN, if the servers protocol stack supports Migrate it replies with a migrate enabled SYN too. Then the communication continues as normal until the client needs to migrate. At this time the client sends a Migrate signal and then starts communicating with the server after obtaining the new IP, the server recognizes the client not as a new one but the same client which migrated and the connection is resumed as normal.


21

The Migrate system currently has two main components: a session layer that handles the vast majority of mobility issues, and a highly-efficient TCP extension that supports the rapid rebinding of endpoints for established TCP connections.

3.2.1 Session Layer

Migrate support for UNIX is being developed as a user-level, session-layer library that manages session-based network activity and resource allocation for applications. Applications linked against the Migrate library communicate with a system-wide Migrate daemon, which monitors the status of open network connections, detects network partitions, and supports rebinding network connections across address changes.

Legacy applications are supported through Tesla, an interposition agent that allows the insertion of arbitrary session-layer services.

3.2.2 TCP Connection Migration

The Migrate and Migrate Permitted TCP options support the migration of an active TCP connection across IP addresses. A peer can migrate an open connection to any other IP address simply by sending a new SYN packet from the desired IP address with the Migrate option enabled. Security is provided through the use of a secret cryptographic cookie negotiated through an Elliptic Curve Diffie-Hellman exchange during the initial connection establishment as part of the Migrate Permitted option negotiation.

Since both the original and migrated connections use the same sequence space, acknowledgement flow is not disturbed by the new SYN exchange, and standard TCP semantics are preserved across the migration. Furthermore, unlike previous approaches, no


22

modification is required to the TCP header or packet format, and no additional information is included in data packets, as opposed to proposed flow-identifier schemes.

We have also leveraged the end-to-end connection migration provided by the TCP Migrate Options to develop a novel approach server load balancing. Our system achieves connection-level fail-over across both local- and wide-area server replication, without requiring a front-end transport- or application-layer switch.

3.3 Tesla 3.3.1 Introduction This thesis described the design and implementation of TESLA, a framework to implement session layer services in the internet. These services are gaining importance: for example connection multiplexing, congestion state sharing, application level routing, mobility/migration support, compression and encryption. TESLA incorporates three principles to provide a transparent and extensible framework: first, it exposes network flaws as the object manipulated by session services, which are written as flow handlers without dealing with socket descriptors; second, it maps handlers onto processes in a way that provides for both sharing and protection; and third, it can be configured using dynamic library interposition, thereby being transparent to end applications. TESLA can be used to design several interesting session layer services including encryption, SOCKS and application controlled routing, flow migration, and traffic rate shaping, all with acceptably low performance degredation. Modern network applications must meet several increasing demands for performance and enhanced functionality. Much current research is devoted to augmenting the transport-level functionality implemented by standard protocols as TCP and UDP. Examples abound:

• Application-level routing, where applications route traffic in an overlay network to the final destination.

• End-to-end session migration for mobility across network disconnections. • Encryption services for sealing or signing flows.

These examples illustrate the increasing importance of session-layer services in the Internet—services that operate on groups of flows between a source and destination, and produce resulting groups of flows using shared code and sometimes shared state.


23

TESLA (a Transparent, Extensible Session Layer Architecture), is a framework that facilitates the development of session layer services like the ones mentioned above through a systematic approach to developing session-layer services compared to the largely ad-hoc point approaches used today. TESLA is presented by its maker in [5], and they believe that their frustrations with the development and implementation of these services at the user level were the prime motivation behind TESLA and led to three explicit design goals.

• The standard BSD sockets API is not a convenient abstraction for programming session-layer services. It is undesirable to require each service author to implement the entire sockets API. In response, TESLA exports a higher level of abstraction to session services, allowing them to operate on network flows (rather than simply socket descriptors) and treat flows as objects to be manipulated.

• There are many session services that are required ex post facto, often not

originally thought of by the application developer but desired later by a user. For example, the ability to shape or police flows to conform to a specified peak rate is often useful, and being able to do so without kernel modifications is a deployment advantage. This requires the ability to configure session services transparent to the application. To do this, TESLA uses an old idea—dynamic library interposition taking advantage of the fact that most applications today on modern operating systems use dynamically linked libraries to gain access to kernel services. This does not, however, mean that TESLA session-layer services must be transparent. On the contrary, TESLA allows services to define APIs to be exported to enhanced applications.

• Unlike traditional transport and network layer services, there is a great diversity in

session services as the examples earlier in this section show. This implies that application developers can benefit from composing different available services to provide interesting new functionality. To facilitate this, TESLA arranges for session services to be written as event handlers, with a callback-oriented interface between handlers that are arranged in a graph structure in the system.

To avoid making changes to the operating system or to the application itself, TESLA transparently interposes itself between the application and the kernel, intercepting and modifying the interaction between the application and the system—acting as an interposition agent. It uses dynamic library interposition to modify the interaction between the application and the system. This technique is popular with user-level file systems and several libraries that provide specific, transparent network services such as SOCKS, and Migrate etc. Each of these systems provides only a specific service, however, not an architecture usable by third parties.


24

3.3.2 Architecture Many tools exist that, like TESLA, provide an interposition (or “shim”) layer between applications and operating system kernels or libraries. However, TESLA raises the level of abstraction of programming for session-layer services. It does so by introducing a flow handler as the main object manipulated by session services. Each session service is implemented as an instantiation of a flow handler, and TESLA takes care of the plumbing required to allow session services to communicate with one another. 3.3.2.A Interposition To achieve the goal of application transparency, TESLA acts as an interposition agent at the C-library level. 3.3.2.B The flow_handler API Every TESLA session service operates on flows and is implemented as a derived class of flow handler. To instantiate a downstream flow handler, a flow handler invokes its protected plumb method. TESLA handles plumb by instantiating handlers which appear after the current handler in the configuration. Flow handler methods are asynchronous and eventdriven— each method call must return immediately, without blocking. 3.3.2.C Handler method semantics Many of the virtual flow handler methods have semantics similar to the corresponding non-blocking function calls in the C library. These methods are invoked by a handler’s input flow. Since, in general, handlers will propagate these messages to their output flows (i.e., downstream), these methods are called downstream methods and can be thought of as providing an abstract flow service to the upstream handler. Many handlers, such as the encryption handler, perform only simple processing on the data flow, have exactly one output flow for one input flow, and do not modify the semantics of other methods 3.3.2.D Process management TESLA developers choose to separate the context in which TESLA flow handlers run from the application processes that generate the corresponding flows. When an application is invoked through the tesla wrapper (and hence linked against the stub), the stub library creates or connects to a master process, a process dedicated to executing handlers. Each master process has its own handler configuration determined by the user. When the application establishes a connection, the master process determines whether the


25

configuration contains any applicable handlers. If so, the master instantiates the applicable handlers and links them together in what we call a TESLA instance. The application and master process communicate via a TESLA-internal socket for each application-level flow, and all actual network operations are performed by the master process. When the application invokes a socket operation, TESLA traps it and converts it to a message which is transmitted to the master process via the master socket. The master process returns an immediate response (this is possible since all TESLA handler operations are non-blocking, i.e., return immediately). 3.3.3 Session Migration in TELSA TESLA has been used to implement transparent support in the Migrate session-layer mobility service. In transparent mode, Migrate preserves open network connections across changes of address or periods of disconnection. Since TCP connections are bound to precisely one remote endpoint and do not survive periods of disconnection in general, Migrate must synthesize a logical flow out of possibly multiple physical connections (a new connection must be established each time either endpoint moves or reconnects). Further, since data may be lost upon connection failure, Migrate must double-buffer in-flight data for possible re-transmission. This basic functionality is straightforward to provide in TESLA. A handler is created that splices its input flow to an output flow and conceals any mobility events from the application by automatically initiating a new output flow using the new endpoint locations. The handler stores a copy of all outgoing data locally in a ring buffer and re-transmits any lost bytes after reestablishing connectivity on a new output flow. Incoming data is trickier: because received data may not have been read by the application before a mobility event occurs, Migrate must instantiate a new flow immediately after movement but continue to supply the buffered data from the previous flow to the application until it is completely consumed. Only then will the handler begin delivering data received on the subsequent flow(s). Note that because Migrate wishes to conceal mobility when operating in transparent mode, it is important that the handler be able to override normal signaling mechanisms. In particular, it must intercept connection failure messages (the “connection reset” messages typically experienced during long periods of disconnection) and prevent them from reaching the application, instead taking appropriate action to manage and conceal the changes in endpoints. In doing so, the handler also overrides the getsockname() and getpeername() calls to return the original endpoints, irrespective of the current location.


26

3.4 Cricket

3.4.1 Overview

Cricket is indoor location system for pervasive computing environments, such as those envisioned by MIT's Project Oxygen. These environments take advantage of emerging network-enabled devices and the promise of ubiquitous network connectivity.

A compelling set of applications in pervasive environments are context-aware, being able to discover the external context in which they run and adapt accordingly. An important example of context is location, such as the position (in some coordinate system) of a device or user, the geographic space in which a device or user is (e.g., the room or portion of a room), and the orientation of a device within some coordinate system.

Knowledge of location in the form of coordinate position, spatial resolution, and orientation (a.k.a. "directionality" or "heading") enables a wide variety of pervasive computing applications such as resource discovery, "point-and-use" interfaces, navigation, and augmented reality.

While location information in outdoor environments may be obtained via the Global Positioning System or using the cellular infrastructure (with the emerging E-911 services) augmented with a magnetic compass, such capabilities are unavailable in indoor environments or around tall buildings where line-of-sight to GPS satellites is usually unavailable. We assert that location-aware applications inside buildings, such as offices (and campuses), shopping malls, airports, homes, etc. has the potential to fundamentally change the way we interact with our immediate environment where computing elements will be "ubiquitous" or "pervasive".

Obtaining location information for applications in an indoor environment in an unobstrusive and private manner is a challenging task. Indoor environments are harsher than outdoor ones in their treatment of radio signals because of multipath effects and dead spots inside buildings. A traditional magnetic compass doesn't work well in many buildings with computers and monitors because of EM interference. User-privacy concerns are an important consideration in the successful deployment of these applications, especially if the users of the system are to extend beyond the researchers who develop the technology. The administration of the hardware and software infrastructure used for this must be minimal because of the large number (potentially over several thousand in a typical building) of devices and networked services that need this information.


27

3.5.2 Technology Cricket uses a combination of RF and ultrasound technologies to provide a location-support service to users and applications. Wall- and ceiling-mounted beacons are spread through the building, publishing information on an RF signal operating in the 418 MHz AM band. With each RF advertisement, the beacon transmits a concurrent ultrasonic pulse. Listeners attached to devices and mobiles listen for RF signals, and upon receipt of the first few bits, listen for the corresponding ultrasonic pulse. When this pulse arrives, they obtain a distance estimate for the corresponding beacon. The listeners run maximum-likelihood estimators to correlate RF and ultrasound samples (the latter are simple pulses with no data encoded on them) and to pick the best one. Even in the presence of several competing beacons vying for attention, our goal is to accurately pinpoint the right one within a small number of seconds.

The Cricket Compass provides position (x,y,z coordinate) information and orientation (the direction at which the device is pointing) information.

3.4.3 Results Cricket uses active beacons and passive listeners, which has two significant benefits. First, it is not a tracking system where a centralized controller or database receives transmissions from users and devices and tracks them. Second, it scales well as the number of devices increases; a system with active transmitters attached to devices wouldn't scale particularly well with the density of instrumented devices. Third, its decentralized architecture makes it easy to deploy. This does not mean it is hard to manage; a centralized front-end allows easy management and control.


28

Cricket can estimate position to a few centimeters of accuracy and angles to within 3-5 degrees of the true value. It can determine which space a device is in by detecting boundaries to within about 2 feet. These combined capabilities are better than other available location systems that we know of.

3.5 OpenSLP: Resource Discovery The number of services that will become available in networks is expected to grow enormously. Besides classical services, such as those offered by printers, scanners, fax machines, and so on, more and more totally new services will be available. Examples are services for information access via Internet, music on demand, and services that use computational infrastructure that is being deployed within the network. Ideally, users would like to obtain access to services automatically, without requiring that they must re-configure their system. For example, they do not want to search for the IP address of the desired service or manually upload device drivers. Especially with the widespread deployment of network enabled mobile devices (such as notebooks, PDAs, and enhanced cellular phones), dynamic discovery of services in a visited foreign network and automatic system configuration will be very useful features. This task is addressed by newly emerging service discovery protocols, like SLP (Service Location Protocol), Jini, UPnP (Universal Plug and Play), and Salutation. A lot of research was done before deciding upon openSLP as our choice of the resource discovery protocol to use in our project. 3.5.1 The Available Options A variety of service discovery protocols are currently under development. The most well known so far and the ones we researched on are:

• Service Location Protocol (SLP), developed by the IETF (openSLP is an open source version)

• Jini, which is Sun's Java based approach to service discovery

• Salutation • Microsoft's Universal Plug and Play (UPnP) • Bluetooth Service Discovery Protocol (SDP)


29

3.5.2 Service Location Protocol (SLP) SLP establishes a framework for resource-discovery that includes three “agents” that operate on behalf of the network based software:

• User Agents (UA): perform service discovery on behalf of client software. • Service Agents (SA): advertise the location and attributes on behalf of the

services • Directory Agents (DA): aggregate service information into what is initially a

stateless repository.

Figure 4: Discovering the DA 3.5.2.A Discovery of The Directory Agent

• Active Discovery: UAs User Agents and Service Agents multicast SLP requests to locate Directory Agents on the network.

• Passive Discovery: DAs multicast advertisements for their services and continue

to do this periodically in case any UAs or SAs have failed to receive the initial advertisement.

3.5.2.B Operational Modes SLP has two main modes of operation:


30

• When a DA is present, it collects all service information advertised by SAs, and UAs unicast their requests to the DA.

• In the absence of a DA, UAs repeatedly multicast the same request they would

have unicast to a DA. SAs listen for these multicast requests and unicast responses to the UA if it has advertised the requested service.

When a DA is present, UAs receive faster responses, SLP uses less network bandwidth, and fewer (or zero) multicast messages are issued. Aside from unsolicited announcements sent by DAs, all messages in SLP are requests that elicit responses 3.5.2.C Service Advertisements Services are advertised using a Service URL, which contains the service’s location: the IP address, port number and, depending on the service type, path. Client applications that obtain this URL have all the information they need to connect to the advertised service. The actual protocol the client uses to communicate with the service is independent of SLP Service Templates define the attributes associated with service advertisements. Templates specify the attributes, and their default values and interpretation, for a particular service type. SAs advertise services according to attribute definitions in the Service Templates, and UAs issue requests using these same definitions. This ensures interoperability between vendors because every client will request services using the same vocabulary, and every service will advertise itself using well-known attributes. 3.5.2.D Operation In Larger Network Environments A DA may serve thousands of clients and servers, so SLP gives administrators ways to improve overall performance and scalability of an SLP deployment as DAs become more loaded. Steps that can be taken to enhance performance are:

• More DAs. First of all, administrators can simply activate more DAs to enhance SLP performance. Because SAs register with each DA they detect, all DAs will eventually contain the same service information, provided that all SAs can find them all. (Of course, sometimes this is neither possible nor desirable.) Adding more DAs creates roughly duplicate repositories of service information without requiring any formal database synchronization between them. Moreover, since UAs can choose any available DA to issue requests to, the load will be shared among DAs. Additional DAs also provide robustness in cases where one fails or becomes overloaded.

• Scope. The second mechanism for increasing SLP scalability is scope. A scope is

a string used to group resources by location, network, or administrative category.


31

SAs and UAs are by default configured with the scope string “default.” Note that services may be available in multiple scopes. UAs can accumulate DA advertisements to form lists of all available scopes. When no DAs are present, UAs can multicast requests for SA advertisements to create lists of scopes supported by the SAs.

3.5.3.E Additional Features The essential function of SLP is service discovery. SLP has also been designed to provide security, extensibility, support for browsing operations, and operation over IPv6. These features extend the utility of SLP, and will be especially useful once a standardized security infrastructure has been widely adopted on IP networks. 3.5.3 Jini Jini technology is an extension of the programming language Java and has been developed by Sun Microsystems. It addresses the issue of how devices connect with each other in order to form a simple ad hoc network (a Jini “community"), and how these devices provide services to other devices in this network. Each Jini device is assumed to have a Java Virtual Machine (JVM) running on it. Devices and applications register with a Jini network using a process called Discovery and Join. To join a Jini network, a device or application places itself into the Lookup Table on a lookup server, which is a database for all services on the network (similar to the Directory Agent in SLP). Besides pointers to services, the Lookup Table in Jini can also store Java based program code for these services. This means that services may upload device drivers, an interface and other programs that help the user to access the service. When a client wants to utilize the service, the object code is downloaded from the Lookup Table to the JVM of the client. This code mobility replaces the necessity of pre-installing drivers on the client. 3.5.4 Salutation The Salutation architecture is being developed by an open industry consortium, called the Salutation Consortium. The Salutation architecture consists of Salutation Managers (SLMs) that have the functionality of service brokers. Services register their capabilities with an SLM, and clients query the SLM when they need a service. After discovering a desired service, clients are able to request the utilization of the service through the SLM. Salutation is a rather settled approach, with few commercial implementations, such as fax devices and Windows enablers (95/98 and NT), e.g., from IBM and Axis.


32

3.5.5 Universal Plug and Play (UPnP) Universal Plug and Play (UPnP) is being developed by an industry consortium which has been founded and is lead by Microsoft. One can say that it extends Microsoft's Plug and Play technology to the case where devices are reachable through a TCP/IP network. Its usage is proposed for small office or home computer networks, where it enables peer-to-peer mechanisms for auto-configuration of devices, service discovery, and control of services. In UPnP's current version (re-lease 0.91) there is no central service register, such as the DA in SLP or the lookup table in Jini. The Simple Service Discovery Protocol (SSDP) is used within UPnP to discover services. SSDP uses HTTP over UDP and is thus designed for usage in IP networks. 3.5.6 Bluetooth Service Discovery Protocol (SDP) Bluetooth is a new short range wireless transmission technology. The Bluetooth protocol stack contains the Service Discovery Protocol (SDP), which is used to locate services provided by or available via a Bluetooth device. It addresses service discovery specially for an ad-hoc environment and thus focuses on discovering services, where it supports the following inquiries: search for services by service type; search for services by service attributes; and service browsing without a priori knowledge of the service characteristics. SDP does not include functionality for accessing services. Once services are discovered with SDP, they can be selected, accessed, and used by mechanisms out of the scope of SDP, for example by other service discovery protocols such as SLP etc. 3.5.7 A Comparison of SLP, JINI, SALUTATION, AND UPNP Although all protocols are using similar architectures, there are several differences. 3.5.7.A Evaluation of UPnP Universal Plug and Play is the youngest of these protocols, and it is still in an early state of development. Up to now there do not exist any commercial implementations of UPnP, but Microsoft plans to implement it for all Windows platforms. The specifications and a sample source code are available freely. UPnP is designed for TCP/IP networks only. In its current version, it does not allow clients to search for service attributes (as, e.g., SLP is able to). UPnP is supported by a large number of companies. Among them are many global players in Internet and telecommunications. This will probably make UPnP a successful approach in a couple of years from now. 3.5.7.B Evaluation of Salutation Service discovery in Salutation is defined on a higher layer, and the transport layer is


33

not specified. Thus, Salutation is independent on the network technology and may run over multiple infrastructures, such as over TCP/IP and IrDA. It is not limited to HTTP{over{UDP{over{IP, as UPnP is. Moreover, Salutation is independent on the programming language, i.e., it is not limited to nor does it have a prerequisite for Java (as Jini). Its major advantage compared to UPnP and Jini is that there already exist commercial implementations. 3.5.7.C Evaluation of Jini Jini is also a rather new approach and no products are in the market yet. Jini distinguishes from the other approaches mainly by the fact that it is based on Java. On the one hand, this concept makes Jini independent of the platform and operating system to run on. Most important, Jini uses Java Remote Method Invocation (Java RMI) protocols to move program code around the network. This introduces the possibility to move device drivers to client applications, which is its main advantage over the non-Java based service discovery concepts. On the other hand, the fact that Jini is tightly tied to the programming language Java makes it dependent on the programming environment. It also requires its devices to run a JVM, which consumes memory and processing power. This can be a hard requirement for large device drivers and might not be fulfilled in embedded systems. Due to the dynamic nature of ad hoc networks, Jini employs the concept of leasing. Each time a device joins the network and its services become available on the network, it registers itself only for a certain period of time, called a lease. This is especially useful for very dynamic ad hoc network scenarios. 3.5.7.D Evaluation of SLP The Service Location Protocol is standardized and well documented through the IETF, and there exist several reference implementations as well as commercial products. SLP offers a flexible and scalable architecture and the utilization of service templates make service browsing and human interaction possible. Since SLP is able to operate with or without a DA, it is suitable for networks of different sizes, ranging from very small ad hoc connectivity to large enterprise networks. SLP also includes a leasing concept with a lifetime that defines how long a DA will store a service registration. Whereas Jini is dependent on Java, SLP is independent on the programming language. The SvrLoc working group is working actively on improving the protocol. DHCP options to configure SLP are already defined. Under development is a concept to use LDAP (Lightweight Directory Access Protocols) servers as a back-end for SLP, i.e., DAs may use LDAP servers as their repository. Furthermore, SLP will be adapted to use with IPv6 and DHCPv6. Last but not least, SLP is developed by an open and vendor-independent forum and its implementation is freely available. Hence after learning all this we expect SLP will play a major role in service discovery and hence choose it as the protocol to use in our project.


34

CHAPTER 4 FINAL PROBLEM STATEMENTS


35

In light of the background research done, we would propose that a resource discovery system in a pervasive environment must meet the following, to successfully provide opportunistic access to services in a dynamically changing system:

• Resource Discovery and Selection: The system must be able to discover resources based on a high-level service specification. Additionally, the system must define a planning framework capable of evaluating and comparing the properties of available alternatives in order to find the closest match to application requirements.

• Expressiveness: An application must be able to state its requirements such that

they can be used for both discovering and, subsequently, comparing the suitability of available alternatives. An application must be able to state the attributes required in a suitable resource, the range of acceptable values for each attribute, the preferred values for an attribute and the relative importance of each attribute to the application.

• Extensibility: In order to support a diverse set of applications in a variety of

network characteristics and standards, the system must not enforce any fixed policies that could limit the use or efficacy of the system. Instead, the system must define an architecture that may be extended to handle different application requirements, network characteristics and standards.

• Connection Rebinding Semantics: It must be possible for an application to configure the semantics of rebinding a network session when a better alternative becomes available. Based on our target applications, we identify the following parameters to provide an application with the flexibility to configure the semantics of session rebinding.

• Performance: Where the system must include a planning function capable of

evaluating and comparing a set of resources competing against application requirements, this planning task must be fast enough to quickly respond to changes in the system. Furthermore, as our system is interposed at the operating system socket level, it must be comparable in performance with the traditional socket-based communication. Finally, it must not introduce an overhead for applications that do not require service-oriented communication


36

CHAPTER 5 REQUIREMENTS & ANALYSIS


37

First of all, let us consider some of the potential drawbacks of the Intentional Naming System:

• INS only supports UDP-style data-gram packet connection-less communication and there is no-support of connection oriented communication.

• The resource location decision is made in the critical path of routing a packet and

the same process is repeated for each UDP packet, this can lead to inefficiency.

• While discovering resources INS merely performs a pattern match and offers closest matching resource. Incase of more than one match an INS ANYCAST is more often then not is the answer.

• INS by nature makes a tree structure between resources (it is implemented as an

overlay network) and hence, if one link in the tree is broken many resources could potentially become blocked from the user.

There is a tendency of potential “hot-spots” in the INS routing tree, as the root nodes would get more traffic but this has been somewhat cleverly handled, INS, and is not that big an issue. We propose to develop an end-system using the traditional OS Socket interface. Such a system has the potential to give us the following benefits

• It is possible to have connection-oriented communication in a pervasive environment.

• As being part of the OS, such a system can perform much more complex resource

comparison before selecting them. Also the Constraint Description Language in CANS would give more flexibility and power over the process of evaluating and comparing resources.

• It doesn’t make resource discovery decisions in the critical path of routing and in

fact resources are discovered and evaluated before making a connection. But this also calls for constant monitoring of changing network resources (but that can be achieved at minimal cost)

• CANS could take benefit from any available resource discovery protocol. Adding

a new protocol for resource discovery is very easy in CANS and in fact as different resources register to different discovery protocols, CANS has the potential of combining them all together in one interface.


38

CHAPTER 6 PROTOTYPE


39

For implementation and testing of our solution we needed to build a prototype. First of all we needed to simulate a pervasive environment. For this purpose we reserved four computers in lab2 of LUMS and setup Linux Red Hat 7.3 on these systems. These terminals were provided with LinkSys Wireless cards for simulating the wireless communication paradigm central to all pervasive environments. The LinkSys Wireless PCI Card is fully compliant with the 802.11b wireless network standard, transferring data at up to 11Mbps in the 2.4GHz radio band. And the wireless communications are protected by up to 128-bit encryption, so the data stays secure. These wireless cards were configured to communicate in an ad-hoc fashion.

The next thing in simulating the pervasive environment was to setup INS, Migrate, Tesla, OpenSLP, and Cricket. The source code of INS, Migrate, Tesla are available from the Networks and Mobile Systems Group at Laboratory for Computer Science, MIT. Migrate runs as a background daemon in Linux providing migration facilities to users. Tesla is installed as a dynamically linked library intercepting and inserting dynamic session layers on the Linux Network Protocol Stack. INS is implemented as an overlay network of resolvers build using the concept of a Distributed Hash Table (DHT) based routing protocol for data-lookup Chord from LCS-MIT. OpenSLP is an open implementation of Service Location Protocol. It is freely available over the Internet under the General Public License. Help on setting up TESLA is provided below; this help should familiarize the reader with the general concept of configuring and installing open source research software on Linux.

To build and install TESLA:

autoconf ./configure make make install ; # As superuser

Note that if you have any handlers already installed (e.g., from an older version of TESLA) you must rebuild the handlers as well, or the teslamaster binary may fail to operate correctly.

This will install the following components:

$BINDIR/tesla A wrapper script that can be used to invoke TESLA. It adds libtesla.so to the LD_PRELOAD environment variable and passes configuration parameters to the handlers (run "tesla -h") for an example.

$LIBDIR/tesla/libtesla.so The shared library which traps applications' network I/O calls.


40

$LIBDIR/tesla/teslamaster The program that libtesla.so spawns, responsible for running any enabled handlers. (This is entirely internal to TESLA; you'll never have to run it.)

$LIBDIR/tesla/handlers/*.o Code implementing The various available handlers. You can add a handler to TESLA by compiling it, placing the resulting object file here, and rerunning tesla-rebuild (below).

$INCLUDEDIR/tesla/*.{h|hh} #include files for building handlers.

$BINDIR/tesla-rebuild A script which relinks the $LIBDIR/teslamaster.a file, and any handlers in $LIBDIR/tesla/handlers/*.o, to regenerate the teslamaster binary. Run this script after installing/deinstalling handlers.

$DOCDIR/tesla/* Documentation (including this file).

BINDIR, LIBDIR, INCLUDEDIR, and DOCDIR are configurable using the usual arguments to configure. In addition, if you are preparing a binary distribution of TESLA (e.g., for iPAQ), you may use the --with-rootdir=DIR argument to specify a root directory for the distribution.

The iPAQ versions of INS, migrate and TESLA were also obtained and the system was configured for allowing access from an iPAQ terminal. This was done by setting up a gateway on one of the Linux machine and configuring the iPAQ to connect to the gateway machine.


41

CHAPTER 7 ANALYSIS, DESIGN, IMPLEMENTATION


42

7.1 Introduction One of the most important aspects of Pervasive Computing is integration of different technologies with each other as decentralized autonomous devices combine together to provide ubiquitous services. Such autonomous devices would need to be discovered before users could benefit from their services. There are many resource discovery protocols proposed, some specifically for the Pervasive environment and some more general e.g. INS. The Context Aware Network Sockets project started off as a research project to propose improvements over INS but the solution proposed was so radically different from INS that it not only addresses the resource discovery problem but also has the potential to integrate various pervasive technologies together, and much more. 7.2 CANS Architecture

Operating System

Socket Structure

Main Module

Discovery Protocols

Resource Discovery Module

Connection Migration Module

Application Constraint Language

Evaluator Module


43

7.2.1 Main Module (nano-kernel)

The main module (much like a nano-kernel), lies at the heart of the CANS system and drives the different modules of the architecture; it parses the constraints specified by an application, discovers matching resources by invoking the resource discovery module, invokes the evaluator module to evaluate the suitability of any matching resources, and finally, in the case when a new resource becomes a better choice for the application, notifies the application and requests the connection migration module to migrate the connection to the new resource. Before understanding the other modules it is important to understand the new features that CAN proposes to add in the socket interface.

a) Context: Context is the physical location of the located services. Defining a context is important to limit the search according to physical constraints.

b) Agility: Agility is the interval between successive probes. It specifies how fast the system would react to changes in the environment. We cannot let the system react to changes too fast and become instable.

c) Hysteresis: Hysteresis is the number of probes for which the resource properties remain consistent before rebinding to another resource.

d) Application Callback: This could be used to notify the application of any changes in the environment or of any other important enough events. In a way this the window through which application can see the environment and then enforce its own policies accordingly.

7.2.2 Evaluator Module A mobile device moves around in a wireless network of servers that it polls or communicates with. While it moves around in this environment the device needs a certain level of service that is provided by these servers, e.g. if the mobile device is displaying a video file it needs to receive the video stream at a constant rate to avoid jitters. In this case, the mobile device would have to inform the server of the minimum rate at which the video should be streamed. These are the constraints of the mobile device. The constraints are those parameters that the mobile device declares to its server which the server has to fulfill in order to allow the mobile device smooth supply of its service. The constraints, here, need to achieve two objectives

• To provide the most optimum level of service available


44

• If such a service is not available, it should at least provide a minimum level of service as declared or are the required by the server

When the first condition is met, there are no qualms. However, if a minimum level of service as required by the device is not achieved, then the device should either switch over to a better server (migrate) and continue its service from there, or if even that is not possible it should display an error message. We, therefore, develop a Constraints Language for the constraints that are first provided to the server before any service is begun. Our aim is to create a standard constraint language that is exhausting in the options that are provided to the server and at the same time is flexible enough to allow incorporation of any type of service. The first thing to establish in any language is its grammar. This is as follows:

Combined → Complex | Simple Complex → (Logical Simple) Complex Simple → (Relation Attribute Value) Simple Logical → AND | OR Relation → < | > | = Value → String | Numeric

An example of constraint specification that follows the above grammar: (AND (< display_size 25 ) ( = color yes ) ( = sound yes ) ) (OR ( > display_size 25 ) ( = color no ) ( = sound no ) )

The above example of constraints specifies that in order for color and sound to be shown the display size sent to the mobile device has to be less than 25. Otherwise no color and no sound can be offered (that is, the bandwidth cannot support large screen size as well as color and sound). There are two parts to the compiler:

• The Lexical analyzer – This picks up each token and detects whether that token is a valid lexeme or not.


45

• The parser – This detects whether the syntax of the code in the language is correct

or not. That is, it matches whether the given code matches the grammar of the language or not

Once these constraints are arranged in the form of a constraint tree then the evaluator module can compare them by assigning a score of 0-1 to each constraint and hence, the evaluator can select the best available choice. By having multiple constraints, the application developer can assign priorities to different constraints and hence in a way the resources would not be selected just on the basis of their distance or some other property but a measured and balanced combination of all its important characteristics in comparison to all the similar available resources.

7.2.3 Resource Discovery Module The resource discovery module is where the system invokes different resource discovery protocols to discover resources. As already mentioned, there are a number of resource discovery protocols some of them are INS, SLP, SSDP, and SSDS. Different devices comply to different resource discovery protocols and in a way the discovery module can convert the original query into the format of each such discovery protocol and receive results from all available protocols. This would result in the discovery of all possible devices and services along with the benefit that the system would not get limited by the abilities of a specific resource discovery protocol. Also, it is very easy to add other resource discovery protocols if and when they become available.

After constructing a constraint tree, the CANS main module invokes the discovery module with the list of attributes at the leaves of the constraint tree. The discovery module invokes the discovery protocols registered with it and returns the matching resource descriptions to the interpreter. The interpreter then passes this list to the evaluator module, which assigns each resource a score by comparing the values of its attributes against the constraints stored in the constraint tree. The evaluator invalidates the resource descriptions with attribute values outside the range specified by the application, as well as the resources that fail to meet an equality constraint.

After the initial setup, this procedure is repeated every time the probe period specified by the application expires. An application can also force a probe/evaluate cycle, for instance on the command of a user. After receiving the score for each resource, the interpreter removes all the resource descriptions that were rejected and forms the “n-best-list” for the probe. If the application forced the probe (by invoking connect on an already connected socket), then the resource with the highest score is chosen from the n-best-list and the socket is migrated to its network address (just like the initial setup). However, if the probe was a normal periodic probe, the system enters the hystersis phase. In the


46

hysteresis phase the n-best-list from one probe/evaluate cycle is compared to the n-best-list stored from the previous cycle and the resources present in both new and old probes have their hysteresis value increased by one. Resource(s) with a hysteresis value greater than the hysteresis value specified by the application are separated and the connection is migrated to the network address of the resource with the highest score. In the case where an application has registered a call-back, CANS invokes the callback method, with the description of the chosen resource, before performing the migration, and migrates only if the application-callback returns a true value (indicating application’s approval of the connection migration). Upon migration of the network connection, the n-best-list is reset and the process is started anew.

7.2.4 CANS Resource Discovery Framework Our target network environment often comprises of resources conforming to different resource discovery protocols, e.g. IETF SLP, INS and SSDP, due to both commercial and technical reasons. Therefore, a service discovery framework based on just a single discovery protocol is not sufficient to discover the various resources found in a pervasive mobile system.

CANS handles this heterogeneity by defining an extensible resource discovery framework, capable of employing different discovery protocols to discover resources in the system. A discovery protocol is added to CANS by registering a pointer to its look-up method, while CANS performs resource discovery by invoking the look-up methods of all the discovery protocol registered with it.

However, various discovery protocols found in our target environment offer different degrees of expressiveness for looking-up resources in the system. Protocols like INS and SSDP simply take a list of attributes and match them with the attributes of the resources being looked-up, whereas more sophisticated protocols like SLP and SSDS can perform complex queries containing conjunctions and disjunctions on nested lists of attributes, as well as range comparisons for attributes with numerical values. In order to interoperate with such diverse protocols, CANS translates a service specification to a very basic query format common to all discovery protocols.

CANS resource discovery framework invokes a constituent discovery protocol with a simple list of ASCII-encoded attribute names, constructed by taking the attribute names from the leaves of the constraint tree created by the CANS parser. Upon invocation, a discovery protocol finds the resources containing the specified attributes, and returns their descriptions in a list of feature-sets: sets of attribute-value pairs. The matching resource descriptions, encoded as feature-sets, are passed on to the evaluator module to evaluate their suitability against the constraints specified by an application.

It is worth noting that, in order to achieve compatibility with simpler protocols, this scheme does not require any filtering involving value comparisons to be performed by a


47

discovery protocol. Rather, discovery protocols look-up resources by simply performing a pattern match on the specified attributes, and the suitability of a resource, based on the values of the looked-up attributes, is computed in the CANS evaluator module.

Passing a query as a simple ASCII-encoded list of required attributes also has the virtue that it can be easily converted to a more ornate format, by a simple wrapper around the lookup interface, if required by a more sophisticated discovery protocol.

7.2.4.A Context of Discovery Along with a pointer to a look-up method, a discovery protocol can also register a pointer to a method for setting the scope of the network queries generated by the discovery protocol. This method is invoked by CANS when an application specifies a context of interest as an option to a service-oriented network socket. For example, SLP and SSDS register a pointer to a method that sets the value of SCOPE of the discovery agent to configure the context of the network queries. Though some simpler protocols, e.g. SSDP, lack support for scoped queries, and hence, do not register this method, we believe that such support is the key to the scalability of a pervasive discovery protocol and will soon find its way in mainstream discovery protocols.

7.2.4.B Probing vs. Advertising A mobile device wishing to discover resources in its environment can either passively listen to advertisements by other resource in the system or can actively probe the network with periodic discovery messages.

CANS uses active probing as it makes it simpler to support application-level semantics for session-rebinding. Applications configure the session rebinding semantics by setting 1) the frequency of probing, to adjust the agility with which resources are discovered, 2) the scope of a probe message, to adjust the discovery context and 3) the number of probes for which the properties of a resource must be consistent, to set the hysteresis of the system.

We favor probing over advertisements because in an advertisement based system the scope and frequency of the messages generated by a resource to advertise itself to the system cannot be adjusted to suit the requirements of any single application. Furthermore, with resource advertisements arriving asynchronously at different frequencies from various resources, there is no clean way to specify the hysteresis of the system.

From a design point of view, in an advertisement-based system, where resources are required to continuously advertise themselves to the system in the hope that some application might be interested, introduces a continuous overhead of network messages


48

and processing of advertisement messages even when there is no application listening to the advertisements.

Finally, probing is supported by all the resource discovery protocols found in our target environment (though some protocols can also be configured to operate in an advertisement-based mode).

7.2.4.C Directory-based versus Peer-to-peer Discovery

Resources can either respond to queries directly, in a peer-to-peer setup, or could register their descriptions with a directory service which could be searched to locate resources.

CANS’ extensible design does not impose a restriction on which of the two methods is employed by a constituent discovery protocol to discover resources in the system. However, we believe that a peer-to-peer model is more suitable for supporting application-specific session rebinding.

Though a directory-based setup avoids query broadcasts, and, hence, presents a more scalable design, it suffers from the following limitations in a dynamically changing system. 1) A directory-based architecture depends on the availability of host(s) in the system that is capable and willing to answer queries on behalf of other resources. 2) A directory-based scheme introduces the overhead of keeping the directory state consistent with the (oft-changing) properties of resources in the system. 3) The directory service can itself cause a bottleneck in the system. A peer-to-peer model, on the other hand, does not depend on the availability and consistency of an external service to access resources in the system, and is, hence, better suited to the high degree of dynamism in a mobile system. Furthermore, since in a peer-to-peer setup resources themselves report their, up-to-date, properties, the rate of probing provides an accurate mapping for the rate of adaptation expected by the application; this can only be guaranteed in a directory based system when the directory service is always consistent with the changes in resource properties.

7.2.5 Connection Migration Module

As, the users are mobile they might move closer to a better resource and want to use that resource instead. Also in a dynamically changing environment resources can come and go too. CANS supports connection-oriented communication and there is an important issue of migrating connections based on any of the conditions mentioned above. There has been a lot of work already done in connection migration and designing a good migration technique is not the focus of our work. In fact our system cleanly fits into the Migrate protocol and can very easily benefit from its migration capabilities. It is needless to say here that the extensibility and flexibility of our architecture enables us to use any other protocol/method of migrating connections as well.


49

Once a better resource has been selected, the CANS main module requests the connection migration module to migrate the network connection to the new resource. The semantics of migrating the network connection from one resource to another depend on both the stateful-ness of the service being accessed and the reliability guarantees offered by the underlying message transport protocol. Migration of an unreliable network connection to a stateless service is accomplished by simply closing the old network connection and opening a fresh connection to the new resource. However, additional support is required for migrating reliable connections and for managing stateful services. Migration of a reliable connection requires support for preserving the sequence of messages across migration, while a connection to a stateful service can be, transparently, migrated across resources only when the state accessed at the old resource is also available at the new resource in the form that the access to the service can be resumed at the new host from where it left-off at the old resource.

The former requires a reliable transport protocol with support for migrating an active connection, while the later also requires a system for distributing and maintaining consistent state across replicated instances of a stateful service.

Our work focuses on enabling a client to utilize the best provider of a service in its changing context; the subject of replicating and synchronizing stateful services has been extensively researched by others.

CANS uses the Migrate system for migrating network connections between resources. We chose the migrate system as it provides support for securely migrating both reliable and unreliable network connections, as well as a lightweight, soft-state based consistency management system to support connection migration across stateful servers. Unlike other connection migration systems, like SCTP, that require the network addresses of all the potential servers to be known at connection setup time, Migrate allows a connection to be migrated to a newly available server using the TCP migrate options. Having said this, the modular design of CANS allows other connection-migration systems to be used as well, though we have not integrated other such systems with CANS as yet.

7.3 Implementation of CANS

One implementation strategy would have been to go into the kernel-space and modify the current implementation of sockets in the code of sockets itself. There were some issues involved with it, some of them are as follows:

• Added coding complexity as legacy code would need to be understood and changed.

• Would need to re-code the Migrate protocol at the kernel level as it is currently implemented in the user space.


50

• Need of a user-space daemon that monitors and evaluates for all connections. One implication of that is that application time could not be accounted to them as the kernel time is shared plus the user space daemon time would also be shared.

Figure 5: CANS Inserted At Session Layer Using TESLA The approach that we followed is the same as that of Migrate. Migrate was implemented using a Tesla. Tesla enables us to add multiple layers at the session layer of the Network protocol stack. It basically captures the Network I/O call of the application and eventually passes it to the underlying traditional sockets.

CANS have been implemented by overriding calls to:

• Socket() • Connect() • Setsockopt() • Getsockopt() • Close()

CANS

Migration

Application

C Library

Downstream

Upstream


51

In short, all the added functionality is handled at CANS and it uses the underlying functionality of traditional sockets, by passing down the calls, just as any layer in the network stack uses its lower layer. Further, as Migrate is also implemented using Tesla, it is very easy to, even dynamically, attach and detach the Migrate layer from below the CANS layer. Hence, applications needing the services of Migrate would choose to register for it and other would not. Currently, the resource discovery is done by using OpenSLP alone.

As, a compromise to the Cricket Location Support System, which is not available because it is not openly distributed, we can send dummy header packets to different resources and see who replies faster. This would in some way determine the closest resource, however keep in mind that incorporating Cricket Location System in CANS later on, when it becomes available, would be very easy again because of its extensible architecture.

We needed to add a new address family to sockets called AF_CANS. Now instead of including <socket.h> header file if the programmer would include <CANS.h> file it would provide him with all the functionality of sockets plus a lot more. All traditional socket applications are supported by CANS and incase some application does not want to use any of the new features it is allowed to do so. The development environment is RedHat Linux with kernel 2.24. For wireless communication we are using 802.11b cards from Linksys.


52

Figure 6: CANS code of SETSOCKOPT()


53

Figure 7: CANS API


54

7.4 LAGS: Design and Implementation 7.4.1 LAGS Hardware The Location Aware and Guidance System (LAGS) is a re-engineered version of the Cricket Location System developed by Massachusetts Institute of Technology (MIT). Due to design constraints and other short comings that were required in our project, we had to re-engineer the whole hardware setup. Our hardware has the following main modules: 7.4.1.A LAPE Beacon Unit (LBU) Initially, we tried to follow the Cricket Location Systems design of the Cricket Beacons. But due to the unavailability of the Atmel Micro-controller and we chose to use Microchip PIC microcontroller (PIC16F877) for the Beacon Unit as it provides the basic functionality of our project. Also this chip proved to be faster than its predecessor in terms of execution time and effectiveness.

7.4.1.B The Microprocessor It’s powerful (200 nanosecond instruction execution) CMOS FLASH-based 8-bit microcontroller made it a perfect solution to our hardware requirements. It features 256 bytes of EEPROM data memory, in-system-programming capability, an ICD, 2 additional timers, 2 capture/compare/PWM functions, and a synchronous serial port which we configured as 3-wire Serial Peripheral Interface (SPI™) bus. This unit uses a coupling of RF and Ultrasound to interact with the nearby LHU and LAGS Handhelds. We used an RF and US module for this.

7.4.1.C RF Module

The RF module comprises of a PT2272 controller along with an RF transmitter/receiver. The PT2272 is a remote control decoder that we paired with PT2262. The PT2262 is a remote control encoder that utilizes CMOS Technology. It encodes data and address pins into a serial coded waveform suitable for RF modulation. We choose these two chips because they have a maximum of 12 bits of tri-state address pins providing up to 531,441 (or 312) address codes; thereby, drastically reducing any code collision and unauthorized code scanning possibilities. Both are low power consuming chips that have very high noise immunity.

7.4.1.D Display Module (for beacon only)

We used an inexpensive LCD Character display for the LAPE Beacon Status Display. This also helped us during the debugging and testing phase as we had programmed it in


55

such a way to indicate errors [picture]. We can integrated the display unit in such a way that it can be replaced at any time owing to requirements.

7.4.1.E Communication Module

We used this module to convert the TTL signals to RS232 so that our unit could be interfaced with a serial port to communicate with a computer (we used this option for in-system-programming for the microcontroller and for debugging). We have chosen Maxim IC MAX 232 due to its reliable communication. Its converter has 11.06 MHz crystal quartz which allows transmitting data at the highest speed of our UART (115kbps).

7.4.2 LAGS Optimization and Tradeoffs

• We have optimized our system both from the software and hardware point of views. Initially we were planning to design our own touch screen handhelds. But this did not prove to be efficient as existing PDAs have a lot of added functionalities that suffice our project needs. We took advantage of Compaq’s iPaq because of its light weight, mobility, Linux support and Wireless LAN capabilities. We decided to use Linux on our handhelds as it provided speed and stability to our system. Apart from this, it catered for security concerns for transactions between the handheld and the main system. • Our approach to implementing this project was based on careful planning, risk analysis and constant feedback from the concerned people. This allowed us to implement the project in a fast and effective manner, changing parts of the code to achieve optimization. • We replaced the MIT Cricket Location System’s implementation of the hardware beacons and listeners. They used Atmel Microcontroller (Atmega103L) in their design. We replaced it by a readily available and faster microcontroller i.e. Microchips PIC Microcontroller. Apart from that, we were short of a lot of hardware equipment as they are not available in our country. This encouraged us to do a lot of re-engineering and restructuring of their implementation, thus coming up with a different and new design of the system. The underlying concept however remains the same. • The features of the microcontroller allowed us to use minimum external components thus reducing the size and dimensions of the handheld and beacon units. • We wrote a tightly compact code in assembly for the PIC microcontroller so that it utilized minimum space and optimized speed of the microprocessor.


56

• In order to develop the assembly code for the microcontroller we used the help of Microchip’s Mplab. Mplab is an Integrated Development Kit for PIC microcontrollers. It has a student evaluation kit that is available online for download. It provided us with a simulator, debugger and an embedded development environment for developing our code for the microcontroller. • We devised a floor plan while deploying these beacons for testing. And found out that by following an efficient floor plan, we could optimize the range and detection of different handheld units in the area. • The Wireless LAN cards provided us the option of sending messages from point to point or point to multipoint as these features are built in functionalities on the card drivers. • We didn’t have a programmer board for the microcontroller so we designed and built a programmer board with an in-system-programming functionality to save us the time of having the chips burned on a burner. We could burn it on the programmer and debug it on it as well.

We developed the hardware in modules. We divided the whole hardware setup for the handhelds and the beacons into three parts. The RF module, the ultrasound module, the communications module, the LCD display module (only for beacons). First we tested the RF transmitter receiver pair on our system. The range of transmission for the RF waves turned out to be a little below a hundred feet (in un-obscured areas). In highly populated areas (like the computer lab) the range got reduced to 78 feet. We then moved on to the ultrasound module and wrote the assembly for it as well. Coupled with the ultrasound and the RF, the signal generation was further reduced to 57 feet (in areas like the computer lab). One of the main problems that we faced during the testing and debugging was generating the RF and ultrasound signals simultaneously. We were able to have them generated as independent signals but not as a single phase. We covered this problem in section – of this paper. After completion of signal generation and reception, we moved to the interface. We used the communication module for this purpose.


57

Figure 8: LAG Beacon Unit

Figure 9: LAG Handheld Unit


58

Figure 10: LAG Beacon (Re-engineered version of Cricket Beacon)


59

CHAPTER 8 RESULTS


60

First of all we need to elaborate on how the CANS sockets are actually run; for this one needs to understand how to run TESLA. To use TESLA, use the "tesla" wrapper script to invoke applications. To enable a particular handler, use a plus sign followed by the handler name, followed by flags for that handler (if any). Following this, provide the command and arguments you wish to run. For example, to run telnet with the SOCKS and "log" handlers:

tesla +socks -host=192.168.0.15 -port=1080 \ +log -all telnet beacon

Each handler flag is either Boolean, with no argument (e.g., -all) or is followed by an equal sign and a value (e.g., -host=192.168.0.15).

Note that handler order is important: in the above example, the log handler will record bytes actually written to/from the network (i.e., including SOCKS protocol stuff) whereas if +log were before +socks, it would record bytes written to/from the application (i.e., not including SOCKS protocol stuff).

You can obtain usage information for handlers by not providing any command to run:

tesla +socks +log

The -d argument (before any handlers) turns some debugging messages on (you can specify a number after -d, up to -d4, to increase the debugging level further). The -f argument (-ffile) allows you to specify the file to direct these messages to (if unspecified stderr is used). Debugging messages are probably not of much use unless you are a TESLA developer!

Unlike content-based routing systems, the session-oriented approach of CANS moves the cost of resolving service descriptions from the critical path of a network message delivery to the stage of establishing and, subsequently, rebinding a network session. Therefore, we evaluate the performance of CANS by measuring:

o how quickly it can setup a service-oriented network session.

o how quickly it can rebind the network session when a better alternative becomes available.

All tests were performed on a Pentium III with 256MB of RAM running Linux Red Hat 7.3. We vary the number of attributes in a straight-line set of simple constraint specifications and also vary the height of the tree of composite constraint specifications.

The CANS system adds latency in two places, at a socket() call where we fork a daemon and initialize all the discovery protocols installed in the system, and on a connect() call where we must decide which device is the best device available.


61

In all of our tests, the socket call took between 2ms and 5ms. This is fairly high, but represents the cost of forking a process and all inter-process communication between the daemon and the CANS TESLA handler. The cost of the connect call increases only linearly as the number of constraints, both nested and non-nested, are increased. The connect latencies in our system hover around 1ms, which, though higher than expected, is acceptable when amortized over the life of the connection.

Another form of latency shows itself as the time between the discovery of a resource and signaling the application that the CANS system has found a new best resource. Ideally, this should be zero, but we must evaluate the services returned, which has a non-zero cost. This latency again increases only linearly with the number of constraints (both for nested and non-nested constraints), and more importantly, hovers only around 200µs of latency. Where our system achieves acceptable performance, we found that the following implementation choices incurred unwanted overhead:

• Per-socket interpreter daemon processes, • Use of standard IPC between the socket wrapper and the per process interpreter

deamon , and • fixed-point arithmetic. Our implementation would be faster if we were able to communicate with the daemon without copying through interprocess communication channels. This could be accomplished by using a thread library at the cost of making our code less portable. Secondly, we maintain a separate daemon process for each socket to allow for fine-grained accounting. However, this is inefficient compared to an implementation in which a single deamon process handles the discover/evaluate cycles for all the sockets, since such an implementation would save the cost of spawning a daemon every time a socket is created, and might allow for optimizations by batching queries by different applications.

Finally, our system is slowed down by the use of the fixed-point math system we wrote for computing resource scores. This is because the iPAQs we include in our target platforms do not have floating point units and incur an order of magnitude performance hit on floating point performance. Since scoring and weighting is an inherently floating-point process, we were forced to write our own, non-optimized, implementation of fixed-point arithmetic. More efficient implementation in the light of these observations would be considered in future work. Our testing was somewhat hampered by the fact that the underlying TESLA stub gave errors when any of the new socket functions were accessed. In other words our prototype implantation was not stable enough to carry out extensive testing of the system. A more


62

stable implementation of CANS, either by changing the implementation or by changing the TESLA code, would be done in future.

Figure 11: SSH application successfully running with CANS


63

CHAPTER 9 CONCLUSION & FUTUREWORK


64

The Location and Guidance System (LAG) developed to aid CANS, is a local re-engineered parallel to the cricket location system of MIT. The accuracy of LAG, however, remains lower than that of cricket in general but is sufficient to satisfy the needs of CANS. CANS presents an application with an extended socket interface to open a service-oriented network connection by providing a high-level service-specification. When asked to establish a connection, CANS discovers the available resources and connects the application to the resource that best provides that service in its context. Once connected, CANS continuously monitors, compares, and evaluates available alternatives, and reconnects the application to a better alternative if one becomes available.

As opposed to content-routing systems, CANS moves the cost of discovering and evaluating resources against application requirements at the connection set-up time, and allows the application to exercise control at the level of a network session. Since the cost of discovery and selection in CANS is amortized over the life of the network session, it allows CANS to be significantly more sophisticated in terms of expressiveness, evaluation and selection of available resources, as compared to systems that perform message-level service-selection-and-routing.

As CANS integrates support for context-awareness with a traditional operating system communication interface, we have found it much simpler to use than other systems that require the use of additional, and often several different, APIs to build a context-aware application. The design of CANS pays special attention to extensibility in order to take advantage of the wide range of emerging technologies for resource discovery, location detection and network connection migration.

Though we believe that CANS has the potential to become an integral part of future operating systems in a pervasive computing environment, it relies on the wide-spread deployment of network devices embedded with service advertisement protocols, as well as the availability of location detecting mechanisms to estimate the distance of a user with the devices embedded in her context.

The current design of CANS does not include a security framework. Security in such a system is required at several levels: to protect resources against illegitimate access, to protect the CANS system against malicious extensions, and to protect the connection migration system against connection hijacking. Though some discovery protocols, like SSDS and SLP, and connection migration schemes, like Migrate, define their own security models, we are currently investigating an extensible security framework that would allow security policies to be defined independently of the constituent modules.


65

CANS makes it simpler to develop context-aware applications. Our experience with CANS has shown us that unlike message-based routing systems that are better suited to command-based applications e.g. “sending a document to the nearest printer”, CANS is equally useful for connection-oriented applications as well, e.g. follow-me-video/audio. We are currently developing more applications to demonstrate the utility of CANS in pervasive mobile environments. It should be kept in mind that CANS operate at the session layer and not the application layer. They simply provide the application with an extended socket interface suitable for pervasive environments and many different applications can be written using this extended interface. An example of this flexibility could be that a print application could either be stateful or stateless depending on the choice that the application developer made. If the developer keeps a count of papers printed and then migrates the connection to the new (nearer) printer, the printing could potentially continue where it left off on the last printer. However, the same application could also be developed in a stateless style with one complete document getting printed on a printer (the nearest at the time of job start). In future, we not only plan to develop a more stable version of CANS based on TESLA, either by editing CANS or TESLA, but also we intend to develop CANS without TESLA. That would be a difficult and big project to undertake as it would involve re-implementing Migrate without TESLA too. This implementation should be more efficient as the latency introduced by TESLA would be done away with. Further, direct implementation at the kernel level should prove to be more compatible and easily deployable.


66

CHAPTER 10 REFERENCES


67

[1] Weiser, M, “The Computer for the 21st Century”, Scientific American, September, 1991. [2] M. Satyanarayanan, “Pervasive Computing: Vision and Challenges”, School of

Computer Science Carnegie Mellon University. [3] Robert Grimm et all, “Systems Directions for Pervasive Computing”, University

of Washington. [4] Guruduth Banavar, James Becky, Eugene Gluzbergy, Jonathan Munson, Jeremy

Sussman, and Deborra Zukowski, “Challenges: An Application Model for Pervasive Computing”, IBM, T. J. Watson Research Center.

[5] Jon Salz, Alex C. Snoeren, Hari Balakrishnan, “TESLA: A Transparent, Extensible Session-Layer Architecture for End-to-end Network Services”, MIT Laboratory for Computer Science.

[6] Christopher K. Hess, Manuel Román, and Roy H. Campbell, Building

Applications for Ubiquitous Computing Environments, International Conference on Pervasive Computing (Pervasive 2002), pp. 16-29, Zurich, Switzerland, August 26-28, 2002.

[7] Esler, M., Hightower, J., Anderson, T., and Borriello, G. Next Century

Challenges: Data-Centric Networking for Invisible Computing: The Portolano Project at the University of Washington Mobicom 99

[8] S. Czerwinski, B. Y. Zhao, T. Hodes, A.D. Joseph, and R. Katz. An architecture

for a secure service discovery service. In Proc. of MobiCom-99, pages 24-35, N.Y., August 1999

[9] William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley, The

design and implementation of an intentional naming system, Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.

[10] Alex C. Snoeren and Hari Balakrishnan, An End-to-End Approach to Host

Mobility, Proc. 6th ACM MobiCom, August 2000 [11] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor,

I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol. RFC 2960, IETF, Oct. 2000.

[12] Nissanka B. Priyantha, Allen K. L. Miu, Hari Balakrishnan, Seth Teller, The

Cricket Compass for Context-Aware Mobile Applications Proc. ACM MOBICOM Conf., Rome, Italy, July 2001.


68

[13] Jon Salz, SM thesis, MIT. 2002, The Transparent Extensible Session-Layer

Architecture for End-to-End Network Services. [14] A. Birrell, R. Levin, R. Needham, and M. Schroeder. Grapevine: An exercise in

distributed computing. Comm. Of the ACM, 25(4):260–274, April 1982. [15] CCITT. The Directory—Overview of Concepts, Models and Services, December

1988. X.500 series recommendations, Geneva, Switzerland. [16] B. Oki, M. Pfluegl, A. Siegel, and D. Skeen. The Information Bus (R) – An

Architecture for Extensible Distributed Systems. In Proc. ACM SOSP, pages 58–78, 1993.

[17] Krzysztof Gajos. Rascal - a Resource Manager for Multi Agent Systems in Smart

spaces. In Proceedings of CEEMAS 2001. [18] Alex C. Snoeren, David G. Andersen, and Hari Balakrishnan, Fine-Grained

Failover Using Connection Migration, Proc. 3rd USENIX USITS, March 2001. [19] R. Golding. A Weak-Consistency Architecture for Distributed Information

Services. Computing Systems, 5(4):379--405, 1992. [20] David Garlan, Dan Siewiorek, Asim Smailagic, and Peter Steenkiste, Project

Aura: Towards Distraction-Free Pervasive Computing IEEE Pervasive Computing, special issue on "Integrated Pervasive Computing Environments", Volume 1, Number 2, April-June 2002, pages 22-31.

[21] C. Perkins and P. Bhagwat, A Mobile Networking System Based on Internet

Protocol, IEEE Personal Communications, Vol. 1, No. 1, pp. 32-41, March 1994. [22] Harter, A., Hopper, A., Steggles, P., Ward, A., Webster, P.: The anatomy of a

context-aware application., Mobile Computing and Networking. (1999) 59-68 [23] S. Bhattacharjee, M. H. Ammar, E. W. Zegura, N. Shah, and Z. Fei. Application

Layer Anycasting. In Proc. IEEE INFOCOM'97, 1997 [24] Erik Guttman. Service Location Protocol: Automatic Discovery of IP Network

Services. IEEE Internet Computing Journal, 3(4), 1999. [25] J. Jaffar and M. J. Maher. Constraint logic programming: A survey. The Journal

of Logic Programming, 19/20:503--582, May/July 1994. [26] Universal Plug and Play, http://www.upnp.org

Session 1999-2003 Project Advisor Dr. Mansoor Sarwar ... · Dr. Mansoor Sarwar Submitted By Muneeb...

Documents

Transcript of Session 1999-2003 Project Advisor Dr. Mansoor Sarwar ... · Dr. Mansoor Sarwar Submitted By Muneeb...