Citation
KONARK - AN AD-HOC SERVICE DISCOVERY PROTOCOL

Material Information

Title:
KONARK - AN AD-HOC SERVICE DISCOVERY PROTOCOL
Copyright Date:
2008

Subjects

Subjects / Keywords:
Application programming interfaces ( jstor )
Broadcasting industry ( jstor )
Computer technology ( jstor )
Greetings ( jstor )
Java ( jstor )
Keywords ( jstor )
Leases ( jstor )
Mobile devices ( jstor )
Registry ( jstor )
Search services ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
8/8/2012
Resource Identifier:
81464926 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

KONARK AN AD-HOC SERVICE DISCOVERY PROTOCOL By NITIN DESAI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Nitin Desai

PAGE 3

To my Parents.

PAGE 4

ACKNOWLEDGMENTS I would like to thank my advisor Dr. Abdelsalam (Sumi) Helal for his constant motivation and support. I would also like to thank Dr. Anand Rangarajan and Dr. Michael Frank for serving on my thesis committee and for reviewing my work. I would like to thank my family for their continuous support and motivation to achieve my goals. Special thanks go to all my friends who helped me to achieve this. I would like to thank Varun for working along with me for Konark Project, Madhav and Ameya for their great company in the lab, Prakash and Suchindra for helping me to come up with a name for this project, and Sricharan, Shashank and Pushkar for helping me to review my thesis report. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION............................................................................................................1 1.1 Motivation.................................................................................................................1 1.2 Goals and Vision.......................................................................................................2 1.3 Outline of the Thesis.................................................................................................2 2 BACKGROUND AND RELATED WORK....................................................................4 2.1 Pervasive Computing................................................................................................4 2.2 Handheld Devices.....................................................................................................5 2.3 Ad-hoc Networks......................................................................................................5 2.4 Services.....................................................................................................................5 2.5 Service Discovery Protocols.....................................................................................6 2.5.1 Need for the Service Discovery Protocols......................................................6 2.5.2 Service Discovery Protocol Models................................................................7 2.5.2.1 Distributed Push.....................................................................................7 2.5.2.2 Distributed Pull......................................................................................7 2.5.2.3 Centralized Pull......................................................................................8 2.6 Existing Service Discovery Protocols.......................................................................8 2.6.1 Jini – Java Intelligent Network Infrastructure.................................................8 2.6.1.1 Services..................................................................................................8 2.6.1.2 Lookup Service......................................................................................9 2.6.1.3 Leasing...................................................................................................9 2.6.1.4 Discovery and Lookup Protocols...........................................................9 2.6.2 UPnP – Universal Plug And Play.................................................................11 2.6.2.1 UPnP Architecture...............................................................................12 2.6.2.2 Addressing...........................................................................................12 2.6.2.3 Discovery.............................................................................................12 2.6.3 Salutation......................................................................................................13 2.6.4 IBM – DEAPspace........................................................................................15 2.6.5 RONIN Agent Framework............................................................................16 v

PAGE 6

2.6.6 The Anhinga Project.....................................................................................17 2.6.7 Advantages and Disadvantages of the Service Discovery Protocols............17 3 KONARK SERVICE DISCOVERY PROTOCOL ARCHITECTURE........................19 3.1 Ad-hoc Environment and User Level Services.......................................................19 3.2 Factors affecting the Ad-hoc Discovery and Advertisement..................................20 3.3 Addressing and Networking Assumptions..............................................................23 3.4 Service Registry......................................................................................................24 3.5 Service Discovery and Advertisement....................................................................27 3.5.1 Service Discovery.........................................................................................28 3.5.2 Advertisement...............................................................................................30 3.6 Service Description and Delivery...........................................................................31 3.6.1 Service Description.......................................................................................31 3.6.2 Service Delivery............................................................................................32 4 IMPLEMENTATION.....................................................................................................33 4.1 General Architecture...............................................................................................33 4.2 Registry and Services..............................................................................................34 4.3 Service Manager.....................................................................................................35 4.3.1 Service Management APIs............................................................................35 4.3.2 Service Discovery.........................................................................................36 4.3.3 Service Advertisement..................................................................................36 4.3.4 Handling Client Discovery Requests............................................................37 4.3.5 Handling Server Advertisement Messages...................................................37 4.4 Lower Level Messaging Layer...............................................................................37 4.4.1 Client Messaging Layer................................................................................38 4.4.2 Server Messaging Layer................................................................................38 4.5 Leasing and other Utility Classes...........................................................................39 4.6 Service Description and Delivery...........................................................................39 4.6.1 Service Description.......................................................................................39 4.6.2 Service Delivery............................................................................................40 4.7 Implementation Platforms.......................................................................................40 4.7.1 Personal Java Implementation.......................................................................40 4.7.2 J2ME CLDC/MIDP Implementation............................................................41 5 PERFORMANCE EVALUATION................................................................................42 5.1 System Properties Assumptions..............................................................................42 5.2 Quantitative Approach............................................................................................42 5.2.1 Latency Time................................................................................................43 5.2.2 Service Access Time from the Registry........................................................44 5.2.3 Network Load...............................................................................................45 5.3 Qualitative Approach..............................................................................................46 vi

PAGE 7

6 APPLICATIONS AND USER INTERFACE................................................................48 6.1 Application Programmer Interface.........................................................................48 6.1.1 Server Side Operations..................................................................................48 6.1.2 Client Side Operations..................................................................................49 6.2 Konark User Interface.............................................................................................49 7 CONCLUSION AND FUTURE WORK.......................................................................53 APPENDIX APPLICATION PROGRAMMER INTERFACE......................................55 Client Side APIs............................................................................................................55 Server Side APIs...........................................................................................................57 LIST OF REFERENCES...................................................................................................60 BIOGRAPHICAL SKETCH.............................................................................................63 vii

PAGE 8

LIST OF FIGURES Figure page 2-1 Discovery Mechanism in Jini [SUN99].........................................................................9 2-2 Join Mechanism in Jini [SUN99]................................................................................10 2-3 Lookup Operation in Jini [SUN99].............................................................................10 2-4 Service Use in Jini [SUN99].......................................................................................11 2-5 UPnP Stack [UPN00]..................................................................................................13 2-6 Salutation Architecture [SAL97].................................................................................14 3-1 Example Service Tree..................................................................................................26 3-2 Discovery Message......................................................................................................28 3-3 Discovery Message by Path.........................................................................................28 3-4 Discovery Message by Keyword.................................................................................28 3-5 Client Discovery Request............................................................................................29 3-6 Service Advertisement Message..................................................................................29 3-7 Service Advertisement Message for “chess” Service..................................................29 3-8 Server Unicast Reply...................................................................................................30 3-9 Service Advertisement.................................................................................................30 4-1 Konark SDP Manager..................................................................................................34 5-1 Latency Time Graph....................................................................................................44 5-2 Access Time Graph.....................................................................................................45 5-3 Utilization for Push of All the Services.......................................................................46 6-1 Starting Konark............................................................................................................50 viii

PAGE 9

6-2 Services Options..........................................................................................................50 6-3 Service Tree.................................................................................................................51 6-4 Tree Options................................................................................................................52 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science KONARK – AN AD-HOC SERVICE DISCOVERY PROTOCOL By Nitin Desai August 2002 Chair: Dr. Abdelsalam (Sumi) Helal Department: Computer and Information Science and Engineering The emergence of mobile devices and wireless networks is defining a new computing paradigm, which is characterized by spontaneous and ad-hoc interactions between devices and services they offer. Service discovery protocols play an important role in enabling the devices to announce their services and discover others over a network without any administration. Traditional service discovery protocols, which address the issues of easy network configuration and discovery of services over the network, fail to address the same in ad-hoc networks of mobile devices. This thesis is part of the Konark project undertaken in the Harris Mobile Computing Lab at the University of Florida. Konark is a service discovery and delivery protocol designed specifically for ad-hoc, peer-to-peer networks, and targeted towards m-commerce oriented software services. This thesis focuses on the design and implementation of the service discovery protocol part of Konark. Our protocol provides x

PAGE 11

the framework for connecting the isolated services of the proximal pervasive devices over a wireless medium. We present an architecture for the registration and advertisement of services on a mobile device, and the discovery of services on other devices in the environment based on a tree-based structure. We have implemented the protocol for the Personal Java and J2ME CLDC/MIDP platforms. The implementation also provides the APIs necessary to build Konark applications. We have built a simple Graphical User Interface to demonstrate the functionalities of the Konark discovery and delivery protocol. Performance evaluation is done with newly defined metrics. We were able to implement and demonstrate the protocol for mobile devices that enables them to share and avail the mobile services over ad-hoc networks. xi

PAGE 12

CHAPTER 1 INTRODUCTION The important waves of technological change are those that fundamentally alter the place of technology in our lives. What matters is not technology itself, but its relationship to us [WEI96]. As the computers shrink in size with increase in their processing power and widespread use of wireless technologies for networking these devices become ubiquitous, we enter into a new computing era characterized by the small handheld devices with the wireless connectivity. This kind of new computing environment poses many interesting problems. One among them is discovery and advertisement of the interested devices and services on the spontaneously formed networks. There have been a lot of efforts in industry and academia to bring individual, self-contained computing devices together into dynamic, transparent, and simply connected networks to offer more services and more resources to the end-user [SUN99]. However they fail to address the device independent services over ad-hoc networks. 1.1 Motivation Mobile computing devices like personal digital assistants, cell-phones, pocket PCs, tablet computers, laptops and even full scale servers are all potential platforms for the formation of ad-hoc networks anytime, anywhere. All these devices may have some kind of isolated, device independent services on them to offer. If these devices can act as both client and server and form an ad-hoc, peer-to-peer network, we can serve these ad-hoc groups. This is moving away from the traditional client-server computing to peer-to-peer computing which is necessary to realize the true potential of these small devices and their 1

PAGE 13

2 wireless connectivity. Also these devices have special-purpose operating systems and many of them are Java-enabled. The low level technologies necessary to form a peer-to-peer, ad-hoc network are available and what is required is to provide a higher level framework and protocol, so that these devices will be able to discover and advertise their services over ad-hoc networks. KONARKour ad-hoc service discovery and delivery protocol provides this necessary framework. Konark has two main components; service registry and discovery, and service description and delivery. This thesis deals with the design and implementation of the discovery protocol part of Konark. Verma [VER02] covers the design and implementation of service delivery protocol. 1.2 Goals and Vision We believe that in the future the user equipped with many mobile computing devices will be moving “anywhere” carrying computing power along with him. These devices equipped with wireless connectivity can form spontaneous, ad-hoc networks with one another. The lower layer ad-hoc networking technologies provide the seamless formation of such networks on fly. The framework in the form of discovery and delivery protocol will connect these pervasive devices and services residing on them on fly, thereby utilizing the isolated services on these devices. This will result in easy plug-n-play of the devices and services forming self-configuring, self-healing system. Using our framework, developers can easily create new services, publish and discover them and enable the usage of the discovered services. 1.3 Outline of the Thesis This thesis explores the related wok done in the fields like pervasive computing, ad-hoc networks, mobile services, and the existing service discovery protocols with their advantages and disadvantages in Chapter 2. Chapters 3 and 4 will present the design and

PAGE 14

3 implementation of the discovery protocol. Chapter 5 will define few metrics to evaluate the performance of our protocol and present the absolute values. Chapter 6 will cover about the application programmer interface to build Konark applications and the simple graphical user interface to demonstrate the functionalities of Konark. Chapter 7 will conclude the thesis and will provide links to the future work.

PAGE 15

CHAPTER 2 BACKGROUND AND RELATED WORK This chapter covers the background and related work done in the various areas addressed by ad-hoc service discovery and delivery protocol for the device independent services. This includes pervasive computing, emerging handheld devices, mobile services, ad-hoc networks and the existing service discovery protocols. 2.1 Pervasive Computing Mark Weiser – father of ubiquitous computing, talked about his vision about the next generation computer in the paper The Computer for the 21st Century in Scientific American [WEI91]. The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it. Silicon-based information technology, in contrast, is far from having become part of the environment. Such a disappearance is a fundamental consequence not of technology, but of human psychology [WEI91]. Simply put pervasive computing is the next natural computing revolution, which will enable “access to your information anytime, anywhere on any device.” As the computing systems shrink in size with increase in computing power, they will enter into every aspect of our life from automobiles to kitchen appliances and will revolutionize the way we live life. Pervasive computing is about creating a smart and adaptive environment with smaller, faster and smarter pervasive devices that will gradually become invisible in the environment [WEI96]. To make all this work, an important middleware called Service 4

PAGE 16

5 Discovery is necessary. Service discovery is an integral part of building ad-hoc, self-configuring networks for pervasive information access. 2.2 Handheld Devices As the desire for pervasive computing increases, one has to design a new kind of computing devices apart from the PCs that should be small in size and should be equipped with better computing power to serve one’s purpose. Handheld devices promise much better ubiquitous computing as we move away from the PC-era and as the internet becomes more pervasive. In the future each individual will be equipped with many such handheld devices that he will carry along with him. The examples include the Motorola’s iDEN phones, Compaq’s iPAQ, Palm Handheld etc. 2.3 Ad-hoc Networks Ad-hoc networks are the wireless, self-configuring networks that are formed when two or more nodes come together. These zero configuration networks can form anywhere in areas ranging from airports, automobiles to relief stations. If all the devices are in each other’s radio range they form a pico-network. A few nodes can be member of more than one pico-network resulting in a wider network. Routing and security form the major issues related to ad-hoc networks. The collaborative applications and service discovery over these ad-hoc networks form an important area and it needs adaptable middleware to perform these tasks. 2.4 Services People will need different kind of services as they do their day-to-day activities. These could include from booking an air ticket, ordering pizza, getting traffic information on road or even playing some game while waiting for a flight at airport. Most of the utilities like music, games and latest software installations will be offered as services. The

PAGE 17

6 existing discovery protocols used to discover services perform easy configuration and network management. Their main focus is the services offered by the devices, which are their capabilities, but don’t really target device independent services. Our focus is on discovering device independent services over ad-hoc networks to utilize isolated services. 2.5 Service Discovery Protocols This section deals with the necessity of the service discovery protocol and its models. We will also discuss the existing service discovery protocols. 2.5.1 Need for the Service Discovery Protocols The widespread deployment of inexpensive communications technology, computational resources in the networking infrastructure (wired or wireless), and network-enabled end devices poses an interesting problem for end users: how to locate a particular network service or device out of hundreds of thousands of accessible services and devices. These recent trends in mobile and ubiquitous computing have created new requirements for automatic configuration and reconfiguration of network devices. Furthermore, the exploding deployment of networked digital devices in diverse "real world" environments has increased the need to simplify network administration for all networks. In response to these requirements, a variety of new protocols have been proposed that attempt to provide automatic discovery and configuration of network devices and services. The service discovery protocols provide the following things: Ability to announce their presence to the network, Automatic discovery of services in the neighborhood and even those located remotely, Ability to describe their capabilities as well as query/understand the capabilities of other services, Self-configuration without administrative intervention,

PAGE 18

7 Seamless inter-operability with other services wherever meaningful. There are number of service discovery protocols mainly from industry like Jini, Salutation, UpnP, SLP and others. They have their own pros and cons. We will discuss the service registry, and advertisement and discovery mechanism for the following service discovery protocols in the later sections. 2.5.2 Service Discovery Protocol Models The service discovery can be either by push model where the service providers push the service information in to the network or can be the pull model where the clients can pull the service information from the network. The Push method can be distributed while pull method can be either centralized or distributed. 2.5.2.1 Distributed Push In this approach, the service providers will broadcast the service information into the network. The clients will keep the updated information of the available services and use them whenever they need. The new device when joins the network has to wait till the next service broadcast to get the service view. This is a passive method of service discovery. The main problems with this mechanism are implementing effective leasing mechanism and deciding on the proper broadcast time interval. 2.5.2.2 Distributed Pull This is an active method of service discovery where the client broadcasts a discovery message to the network for particular service. The servers responds back to the client if they have this service. This method reduces the number of messages sent on the network for service discovery but is little slow. Also the clients don’t have to keep the world-view of services.

PAGE 19

8 2.5.2.3 Centralized Pull In this method, instead of client broadcasting a discovery message on to the network, it will search for the central repository where the services will be stored. The service providers will register their services with the central repository. The clients will query the central repository, download the desired service and use it. The drawbacks with this method are single point of failure and effective leasing mechanism. 2.6 Existing Service Discovery Protocols We will discuss the service registry and discovery/advertisement techniques in the existing service discovery protocols like Jini, UPnP, Salutation, IBM-DEAPspace along with brief mention about RONIN developed in UMBC and the Anhinga project at RIT. 2.6.1 Jini – Java Intelligent Network Infrastructure Jini is a distributed system developed by Sun and is based on the idea of federating groups of users and the resources by forming dynamic, transparent and simply connected networks to offer services and resources to the end users [SUN99]. Jini extends Java, by taking JVM from single machine to network of machines and uses its distributed programming model of moving code and objects between machines. Jini has the following components used for registry and advertisement/discovery of the services. 2.6.1.1 Services A service can be anything from software components to hardware devices and will be used by a person, a device or any other service. Jini provides a mechanism for service construction, lookup and use. Jini provides service protocols that are Java interfaces and open ended, to help services communicate with each other.

PAGE 20

9 2.6.1.2 Lookup Service This is the central bootstrapping mechanism for the Jini system and acts like a repository of the services. It maps the functionality interfaces of the services to their actual implementation. Service description entities associated with each service help the user to choose the proper service. A service is added to the lookup service by using “discovery’ (locating the lookup service) and “join” protocol (joining the lookup service). 2.6.1.3 Leasing Access to the Services is based on a lease mechanism by which it gives the access to a particular service for the specified period of time. This helps in self-healing of the distributed systems in case of failures. 2.6.1.4 Discovery and Lookup Protocols Lookup, join and discovery form the heart of Jini protocol. Discovery/Join protocol pair is used by the device to join the Jini System. It uses “discovery” to locate the lookup service and “join” to join the lookup service. “Lookup” is used when the user wants to locate and use the service. Figure 2-1 Discovery Mechanism in Jini [SUN99] A service provider who wants to provide a particular service will first find the lookup service by sending out the multicast request on the local network for the lookup service as shown below in the figure 2-1.

PAGE 21

10 The service provider then loads the service interface that includes service description attributes and methods to be invoked for the service use, into the lookup service by using join protocol that is shown below. Figure 2-2 Join Mechanism in Jini [SUN99] If any device wants to use a service, it will find the service in the lookup by using the service type described by the java interface or the service description attributes. The client will then download a Service object. Figure 2-3 Lookup Operation in Jini [SUN99]

PAGE 22

11 The client will then use the service by invoking various methods of the interface. The service providers can implement their own protocol between the interface and the actual implementation. Figure 2-4 Service Use in Jini [SUN99] 2.6.2 UPnP – Universal Plug And Play UPnP is the extension of Plug N Play to support zero-configuration, "invisible" networking, and automatic discovery for the devices by Microsoft. It’s a distributed, open networking architecture that leverages TCP/IP and the web technologies to enable seamless proximity networking of the devices. UPnP leverages most of the Internet components like IP, TCP, UDP, HTTP, XML and SOAP. UPnP can be implemented using any programming language on any OS and is media independent. UPnP Networking has generally six steps: 0. Addressing The device or the control point (client devices) obtains an IP address, 1. Discovery – The device advertises their capabilities or the control point discovers the devices, 2. Description – The control point retrieves the device description from the URL provided during step-1, to learn more about the device capability and interaction with the device. The device description includes the list of state variables which model the state of the service at run time and has the list of actions the service will respond to along with parameters,

PAGE 23

12 3. Control – The control point starts using the service, by invoking the actions that sends a suitable control message to a device’s service usually in the form of SOAP requests, 4. Eventing – The service description include the list of variables which model the service state at run time. The service publishes the updates when these variables change and the control point can subscribe to receive this information. These messages are also in XML and formatted using General Event Notification Architecture (GENA), 5. Presentation – The device can have a URL for the presentation, which control point, can download from the URL. The client can then control the device or view its status using this presentation. 2.6.2.1 UPnP Architecture The UPnP stack is as shown below in the figure 2-5. We will discuss the addressing and discovery mechanism in brief, which is relevant to this thesis. 2.6.2.2 Addressing UPnP networking is based on IP addressing. Each device when connected to the network searches for a DHCP server and obtains an IP address. If the network is unmanaged, the device must use automatic IP addressing called Auto-IP [HAT01] to obtain an IP address intelligently from a set of link-local IP addresses. Generally the Auto-IP addresses are in the range 169.254/16. It then checks, if any device has same address in the network. 2.6.2.3 Discovery The Discovery, which includes advertisement and search, is based on Simple Service Discovery Protocol (SSDP). When a device is added, the device advertises its capability and services to control points by multicasting the discovery message. Control points, which listen on the specific port, will detect the new capabilities on the network. The message will include the information about its enclosing devices if any and the time-to-live.

PAGE 24

13 Figure 2-5 UPnP Stack [UPN00] When a control point is added to the network, it will search for the devices of interest on the network. It multicasts a search message with a pattern, which will help to find the device. The matching devices will respond back with the messages similar to the advertisement messages by unicast. 2.6.3 Salutation The Salutation Architecture [SAL97] was created to provide a standard method for applications, services and devices to describe and to advertise their capabilities to other applications, devices and services, and to discover their capabilities. The architecture is processor, operating system and communication protocol independent. This is proposed by The Salutation Consortium [SAL97]. It has a footprint for the small, portable devices but doesn’t support service delivery. The architecture is shown below in figure.

PAGE 25

14 Figure 2-6 Salutation Architecture [SAL97] The Salutation Architecture has a Salutation Manager (SM) that acts like a service broker for applications, services and devices called as Networked Entity. It allows these networked entities to discover each other and utilize them. This networked entity can be a service provider called service, a client or both. The service registers itself with Salutation Manager and is kept in the registry while clients can discover these services through a salutation manager. The Salutation Manager provides transport-independent interface, called Salutation Manager Application Program Interface (SLM-API) to services and clients. The Salutation Managers communicate with each other using Salutation Manager Protocol to perform its role as a service broker. Each Salutation Manager is addressed by a universally unique identifier, SLM-ID. This SLM-ID is 16-octet-long string that uniquely identifies Salutation Manager in a transport independent way.

PAGE 26

15 The Salutation Managers have been made transport independent by introducing Transport Managers that together with Salutation Manager perform the role of service broker. The Salutation Manager contains a Service repository called Registry. It stores the local services and optionally, can even store the services of the connected Salutation Managers. It can also act as network directory by providing information about all the Salutation devices within the range of this salutation manager. The Salutation Manager can discover other Salutation Manager and find the services registered there. Service Discovery is done by comparing the service types and can be done for “all”, “specific” or “particular” service. When a client wants to use a service provided by a Salutation device, a virtual data pipe will be established between a client and a service called as Service Session. Then Personality Protocols will be used to exchange messages on these data pipes. 2.6.4 IBM – DEAPspace IBM DEAPspace provides a framework for connecting proximal pervasive devices over the wireless medium. This is one of the earliest frameworks for the ad-hoc networking for pervasive devices developed by IBM Zurich Research Labs. The framework consists of the discovery algorithm and the service description model. The service discovery algorithm design mainly considers factors like the distributed approach, single hop ad-hoc network, timeliness of the service, power consumption of the devices, worldview of the services and the device capabilities as services. The discovery algorithm is decentralized and uses proactive single hop broadcast mechanism to share the worldview of the services. It uses a push-based mechanism for the discovery and advertisement with a little variation. Each device will send beacons at fixed interval

PAGE 27

16 during their pre-defined advertisement slots. Each broadcast will contain the entire worldview of the services. Other devices will use this information to check the current services list and correct their list if necessary. These broadcast messages that contain the worldview of services are called service-advertisement messages (SAM). Each device schedules a broadcast for future time and waits until that time to broadcast. While waiting if it receives SAM from other device, it changes its broadcast timer to new time. This results in less network messages and less power consumption of the devices. When a new device enters the network, it has to receive only one SAM to get the entire worldview of the services. The push mechanism helps the devices to use the service immediately (timeliness of the services) that is an important factor in the case of the transient ad-hoc networking of the pervasive devices. The services targeted are the device capabilities. DEAPspace has been implemented using Java as well as C (for non JVM devices) over TCP/IP and Ethernet interfaces of 802.11. 2.6.5 RONIN Agent Framework The existing service discovery protocol lacks rich service representation that is necessary for mobile commerce applications. The need of Agent based service discovery approach along with the necessity to provide rich service representation and matching, lead to the Ronin Agent Framework at UMCB. RONIN is a Jini-based distributed agent development framework that offers a simple but powerful agent description facility that allows agents to find each other and an infrastructure that encourages the reuse of the existing non-Java Artificial Intelligence applications. [CHE01] The Ronin description can enhance the Jini service discovery infrastructure for MCommerce by following ways:

PAGE 28

17 Ronin agents share a set of Common-Agent attributes that help them to discover other services solely based on the domain independent functionalities of the services, Once a service has discovered another service using the Ronin description facility, it is possible for these two services to form basic communication negotiation based on the semantic meanings of the Common-Agent attributes. The Ronin framework also provides Jini Prolog Engine Service (JPES)[CHE00] that provides a distributed logical programming tool to Jini-enabled services and also Intelligent Lookup Service to reason out about the capabilities of services. 2.6.6 The Anhinga Project This project provides a distributed computing infrastructure designed to support many-to-many distributed applications running on ad-hoc networks of small handheld devices at ITL RIT [ANH01]. The Anhinga Infrastructure runs entirely on the wireless mobile devices and so does not require any central server support. The Anhinga Infrastructure provides a message broadcast ad-hoc networking protocol and a distributed computing platform based on lightweight versions of Java, Jini Network Technology, and tuple spaces. 2.6.7 Advantages and Disadvantages of the Service Discovery Protocols All these service discovery protocols have been developed for almost the same purpose with different architectures. Jini is a simple distributed system model that is operating system neutral and supports eventing, transactions and leasing. But it is heavily dependent on Java and has centralized control in the form of lookup service. On the other hand, UPnP provides directory-less operation but doesn’t have a support for leasing and transactions. It is zero-configuration network but the service invocation is not very clearly defined and has poor security mechanism. It supports limited service querying and is mainly the devices. Salutation is operating system, network and language independent

PAGE 29

18 with either centralized or distributed registry. It has scalability and reliability problems and has no support for leasing, eventing and transactions. It supports only device capabilities. This doesn’t address the issue of self-configuration and has little complex addressing. A good comparison of all the above three is well explained in [REK99]. IBM DEAPspace considers only the device capabilities and design mainly targets the timeliness of service and power consumption. Also the service delivery is not well explained. Thus all of them have their own advantages and disadvantages. All of the above service discovery protocols fail to fit into the ad-hoc environment for device independent services, in their original form. Its necessary to build a new service discovery and delivery protocol. Konark – our service discovery and delivery protocol meets this challenge.

PAGE 30

CHAPTER 3 KONARK SERVICE DISCOVERY PROTOCOL ARCHITECTURE The computing environment defined by the small handheld mobile devices will be totally different from the traditional PC environment. Unlike the wired network connections and complex network configurations, this emerging computing environment will have mobile devices coming close to one another forming spontaneous, ad-hoc networks. With the availability of inexpensive low level networking technologies like 802.11 and Bluetooth, zero configuration ad-hoc networks can form anywhere. Service discovery protocol running on ad-hoc networks will enable the users to search and publish the device independent services. This chapter deals with the design of Konarkour service discovery and delivery protocol. The chapter initially looks into the computing environment we are targeting, along with the kind of services available in such an environment. Then it deals with the addressing of the devices, structure of the service registry, and discovery and advertisement of the services. 3.1 Ad-hoc Environment and User Level Services Whenever the handheld devices equipped with the wireless technologies like 802.11(ad-hoc mode) or Bluetooth, come close to one another, they form a spontaneous network. These networks can be totally ad-hoc like the one formed in airplanes/airports, emergency relief stations, conferences, automobile networks or even the military networks on the battlefield where all the nodes are totally ad-hoc. Sometimes these spontaneous networks can have few infrastructure nodes with few ad-hoc nodes to form a 19

PAGE 31

20 partial ad-hoc network. Common examples can be the one formed in the shopping malls, office environments, where a user walks around with the devices to form an ad-hoc network with the infrastructure nodes. Both of these kinds of networks are spontaneous, zero-configuration and ad-hoc. We divide the services broadly into two categories device capabilities as services and device independent services. Device capabilities as services include the systems at home and office, like scanners, fax machines, printers, speakers, display systems etc. The device independent services are independent of the devices. These include the ones like providing the information services like weather service that delivers the weather forecast, downloading the software components, games, music on fly or even providing location-based information like nearby restaurants, book shops. These kinds of services will be residing either on the client devices or on dedicated servers. Our protocol will address the discovery and advertisement of device independent services in the ad-hoc environment. 3.2 Factors affecting the Ad-hoc Discovery and Advertisement In general service discovery and advertisement depend on various factors of the device, environment and services. These factors include the following: Environment – This can be either infrastructure based or ad-hoc based. Ad-hoc environment can be single-hop network or more widespread network, Service Types This can be either device capabilities or device independent services, Network Messages – This is about the network load. This deals with the number of messages sent to achieve discovery or advertisement. The length of the message is also an important issue, Service Registry – This can be either centralized or distributed, Memory of The Device – This is for the storage for the services,

PAGE 32

21 Processing Power – This is to provide the computing power to the end user, Power Consumption – This is mainly by network connections and computations, Timeliness of the Service Response – This deals with how fast the client gets the service, User Intervention – This can be at the network-configuration level or services usage level, Service View – This can be partial, local or entire world-view of services, Availability of Services – This is the average lifetime of the service which depends on the mobility behavior of the devices, Management of Services – This is managing the services at the client side. The Service discovery and advertisement protocol, which we have developed to target the device independent services, has to address the above factors and come up with the appropriate solutions. It has to mainly consider the ad-hoc nature of the network and the device independent services. We consider the highly dynamic environment of spontaneous ad-hoc networks formed between the resource-constrained devices that may contain few infrastructure nodes that are usually the dedicated service providers. These devices have limited processing power and memory. We assume IP level networking among these devices. Each device gets an IP address by zero-configuration protocols such as AutoIP technique [HAT01]. We consider the device independent lightweight services that present some useful information to the end user with a simple presentation. The protocol can’t judge whether a particular kind of service can be supported on a particular kind of device. This depends on the type of service and the capabilities of the device that is using the service. The service registry is defined as the place to keep the services so that they can be advertised. It usually resides on some central server or with the service providers. Our

PAGE 33

22 protocol takes this registry concept one step ahead. We use a distributed approach to store the services where each device has its local registry. Along with the traditional service providers, each device can act as both a client and a server enabling peer-to-peer networking among these devices to discover and share their services. We use a tree storage structure to store the services enabling a simple service management at the client side, and the effective advertisement and discovery. A device will have a base tree with its registered services to offer and the services that are available in the proximity environment. We use both an active advertisement and active discovery mechanism. The device can discover the services on demand and can advertise its registered services whenever it wants. Therefore, it is not necessary to advertise and maintain the entire worldview of services. This helps in reducing the size of the message and also the number of messages which otherwise would be needed for the periodic broadcast to keep the updated worldview of services. Using tree based paths and keywords while advertisement and discovery, and user intervention during service delivery solves the issue of service matching. Konark protocol has the following components: Networking and Addressing – This include forming a peer-to-peer network among the devices and obtaining an IP address, Service Registry – The way the services are stored and managed, Service Discovery and Advertising – The way new services are discovered and the registered services are advertised, Service Description – The way the services are described, Service Delivery – The way the services are delivered.

PAGE 34

23 This thesis covers the first three components of the Konark Protocol while Verma [VER02] covers the last two components in the thesis on Service Delivery Protocol. 3.3 Addressing and Networking Assumptions Addressing is the first step after the formation of an ad-hoc network. We assume that the lower link layers of the device help to form an ad-hoc network when the devices come in close proximity. Once the network is formed, each device should be uniquely identified. Salutation uses the transport independent naming scheme that is quite complicated. We assume IP-level connectivity of the devices to be setup automatically. This is becoming feasible with the advent of the emerging zero-configuration protocols such as Auto-IP mechanism. Auto-IP helps to obtain an IP address in the absence of any administrative network services like DHCP or manual configuration of static IP. RFCs Zeroconf IP Host Requirements [HAT01] and Dynamic Configuration of IPv4 Link-Local Addresses [CHE02], explain the procedure of obtaining the IP-address in the zero-configuration network. The ad-hoc network can be just a pico-network where each device will be in each other’s radio range enabling simple peer-to-peer communication among them. We also assume that each device will have the routing capability so that the wider network can be formed and the broadcast medium is available so that the data sent by any node reaches all the other nodes in the network. These devices will join a fixed multicast group for peer-to-peer networking. In our protocol, all the devices will join the local scope multicast address of 239.255.255.251 [HAT01, CAT02].

PAGE 35

24 3.4 Service Registry Service Registry is a place where the servers register the services and the clients query them so that they can use these services. Jini uses the centralized approach in the form of lookup service while Salutation and UPnP uses the distributed approach. In case of an ad-hoc network, the frequent mobility of nodes and lack of infrastructure makes the distributed approach a good option. Also with the existing service discovery protocols, the service registry is either on the central lookup service or with the service provider. The clients don’t have any kind of basic registry to store the available services of the environment and effectively manage them. Due to the resource constraints, the client devices should not acquire the unnecessary services and should be able to delete the unwanted services. The services that are expired should be deleted from the client machine automatically. We use a tree-based structure to store the services both at the client and server side that help them to manage and perform their operations effectively. We also associate the discovery and advertisement mechanism with the service tree stored in the registry. The services are stored in the form of a tree called Christmas Tree. The tree has a number of levels, which represent the service classification levels. The services become more specific as we move from root towards the leaves. The path from the root to the leaf uniquely identifies a particular service. Servers will use the tree for the following operations: To register its services to be offered, under a particular path, based on the type of the service, To advertise the registered services using the tree-path, To respond to the client discovery requests that are based on either path or keyword.

PAGE 36

25 Client devices will have the similar tree, which will be used for the following operations: To discover the services – “all”, “generic” and “specific”based on path. Discovery of “all” services is to get all the services in the network or of some server by path of the root node. Discovery of “generic” services is to get the services under any path of generic service type. While discovery for “specific” service is based on the keyword that gets only one service. To manage the available services of the environment that are in the tree, To add the advertised services, by the servers in the tree and use the inclusive and exclusive based filtering at tree levels to check service entry into the tree. If the device is both a client and a server, it will use the same tree for both the client and the server functionalities. The figure 3-1 shows the example service tree. Example service tree has a root node as the root service and two children, the device capabilities as services and the device independent services. These device independent services may have many children, example shows three nodes under generic services, “information services”, “shopping services” and “entertainment”. The generic service sub-types can be added under the broader generic service types. Specific services can be added under any generic node starting from level-3 based on its type, like chess under games. Each service has a unique path from the tree like, RootService: Services:Entertainment:Games:Chess, for the game chess. The generic services are shown in the oval shape while the actual specific services are shown in rectangles. The first three or four levels of generic services of the tree are fixed. We believe that using a highly generic service types at level two, one can easily accommodate most of the services needed for a mobile user. The tree structure gives an opportunity to advertise and discover the services at any tree level that can be “all” by root-node, “generic” by any

PAGE 37

26 other node and “specific” services by keyword. The “generic” service can be “all games” Figure 3-1 Example Service Tree by path “RootService:Services:Entertainment:Games”. The “specific” service can be “game chess” by keyword “chess”. One can add and remove the specific services at any level. The clients can set the exclusive filters at the generic services and decide not to receive the advertisements under this path. The client can set inclusive filters at the generic service of the tree and can get instant notification for the services, advertised under this category. Thus the tree structure helps both the clients and the servers to manage their services easily and discover/advertise the services effectively. Each service is associated with a lease time, the time the service will be available in the network. At the client side, the lease thread checks for the expired available services

PAGE 38

27 for every minute and removes the service from the tree if it is expired. This helps in building the self-healing system even if some service becomes suddenly unavailable. This time-to-live of the services is expressed in minutes. The server has to update the time-to-live of its registered services once its expired if the server wants to keep this service registered in the registry to offer it to others in the network. We gave the name Christmas tree, as when the user enters an environment where a numbers of services are offered, the device will show these services as lighted spots in the tree indicating the available services in the environment. After the timeout period of the service or whenever the network is changed, these services will be switched off and will no longer be available. These will be then removed from the tree. 3.5 Service Discovery and Advertisement The clients use the discovery process to discover the interested services in the network while the advertisement is used by the servers to publish their registered services. In an environment, if the clients discover their interested services then it is an active pull mechanism while if the servers publish their services periodically then it is a passive push mechanism. We use both advertisement by the servers and active discovery by the clients because of the following reasons: The timeliness of service in not a very important issue – active discovery is slow and fixing the proper periodic broadcast time for servers in ad hoc network is difficult, The flexibility to both the clients and the servers is necessary to discover and advertise the services whenever they want, Clients don’t have to keep the world-view of services reducing the memory storage at the client side and network message size of the advertised services.

PAGE 39

28 3.5.1 Service Discovery Discovery process has two steps. In the first step, the client sends out the discovery message on a fixed multicast group and in the second step, all the servers that have this specified service would respond. In first step, the client creates a discovery message that contains either the path for the “all” or “generic” services or the keyword for the “specific” service discovery. The message has the port number where the client listens for the server replies by unicast. The figures 3-2, 3-3, 3-4 show the discovery message, discovery message for “all” the games by path and for the “printer” service by keyword respectively. Figure 3-2 Discovery Message. Figure 3-3 Discovery Message by Path. . RootService:Service:Entertainment:Games PORT Path or Keyword PORT Printer PORT Figure 3-4 Discovery Message by Keyword The client sends out this message on a fixed multicast group address so that each node receives this request.

PAGE 40

29 Device acting As Server Device acting As Client Discovery Message Device acting AS SERVER Device acting AS CLIENT Figure 3-5 Client Discovery Request. On receiving a discovery message from the client, the server performs the service matching. If it is a path-based discovery, the server matches the path with its registry tree and gets all the registered specific services under that node or its children nodes. If the discovery is based on a keyword, the server matches this keyword with the keywords of its own registered services and gets the matched services. The server then creates a service advertisement message for each of the above services. This message contains the actual service name, the path of the service, the type of the service, the URL where the service description will be available and the time-to-live of the service in minutes. Figure 3.6 and 3.7 shows the service advertisement messages. Service Name Path Type URL TTL Figure 3-6 Service Advertisement Message Chess RootService:Service:Entertainment:Games:Chess games URL 10 Figure 3-7 Service Advertisement Message for “chess” Service

PAGE 41

30 Figure 3-8 Server Unicast Reply 3.5.2 Advertisement The server can decide when it wants to advertise the services. The advertisement can be again “all”, “generic” or “specific” services. The server can advertise “all” the registered services by a root node or the “generic” services by any generic service node or a “specific” service by a specific service leaf node. The server takes the tree node as the input for the path of the service. Then the server gets all the registered services under that node or its children nodes and creates an advertisement service message for each of the registered service. This message is same as the one used to reply back to the client discovery message as shown in the figure 3-6. The server then sends out this message on the fixed multicast group address. Device acting As Client Device acting AS SERVER Device acting AS SERVER Service Advertisement Message Device acting As Server Device acting As Client Service Advertisement Message Device acting AS CLIENT Figure 3-9 Service Advertisement

PAGE 42

31 On receiving the service advertisement messages, the clients pick up the path and match it with their registry tree. While doing so if they find that there is an exclusive filter on any of the node of the path, the message is discarded. If not, the service is added under the specified path. This service will be associated with a lease thread that will delete this service once it is expired. If the path has inclusive filter set, it notifies the user about this service. 3.6 Service Description and Delivery This forms the last stage in Konark protocol. Verma [VER02] has implemented this portion of the protocol. Once the service is discovered and if the client is interested in the service, it can perform the following operations: Invoke the URL specified along with the service to get more description of service that include its attributes and service-specific actions allowed on it. Invoke the proper action with parameters, if necessary and start using the service. 3.6.1 Service Description Service description is about describing a service, i.e. the attributes and the actions it allows a user to invoke on it. This also include presenting this information to the user in a human-understandable form. We use the XML file to represent the service attributes and actions called as service description and delivery file. The service provider writes the XML file in a proper format defined by our Service Description Language and implements our interface for handling the SOAP requests of the service actions. The server registers this service with the server registry. When the client invokes the service URL, the service description and delivery XML file will be sent to the client. The client parses this file and presents it to the end-user. We have a implemented a small microHTTP server for service delivery that runs at the server side.

PAGE 43

32 3.6.2 Service Delivery Once the user is presented with the service properties and actions, the end user can decide on invoking the actions with proper parameters. This will be bundled as a SOAP request and will be sent to the server device that is running the microHTTP server. The server extracts the SOAP message from the HTTP request and invokes the proper method for this action of the registered service and sends the reply back to the client.

PAGE 44

CHAPTER 4 IMPLEMENTATION This chapter deals with the implementation of the service registry, and advertisement and discovery of services using the service tree. The chapter begins with the general architecture and then moves onto the detailed implementation details of each component. The functionalities and the packages that implement them have been described for each component. The chapter also looks into the two implementation platforms of Java namely, personal Java 1.2 and J2ME CLDC/MIDP that have been used for the implementation of our protocol. 4.1 General Architecture Konark service discovery protocol stack consists of a Konark SDP Manager that is independent of the lower wireless network layers like 802.11, Bluetooth or RF. This Konark SDP Manager consists of four parts as shown in figure 4.1: Service Manager: This is the heart of the Konark SDP Manager that provides the Application level APIs to build the Konark applications. It interacts with the registry and the lower level-messaging layer, Registry: This is the data structure that holds the services in a tree structure. Service Manager interacts with this registry to manage the services. Each node in the tree represents a service, Services: Services can be “anything” that is useful to “somebody”. Each node in the registry will represent a service. Both the client and the server share a basic generic service tree. In addition to this, the client can have the services available in that environment. In case of the server, it will have its registered services to be offered. Messaging Layer: This is the lowest layer of Ad-hoc SDP manager that takes care of sending and receiving unicast and broadcast messages. 33

PAGE 45

34 W i reless Medi um (802.11, Bluetooth, RF) Discovery by Client Service Management Advertising by Server User APIs SERVICE MANAGER REGISTRY SERVICES Handling Client Requests Service Advertisement Broadcasts Lower Level Messaging Layer KONARK Applications Figure 4-1 Konark SDP Manager 4.2 Registry and Services Both the server and the client have a basic service tree where each node in this tree is a generic service. In case of the client, the tree can have the proximal available services activated while the server can have its own registered services to be advertised. We use a XML file to store the basic tree structure that will be parsed and a service tree is formed. The package edu.ufl.asdp.services defines the classes to represent the various types of services like generic services, the client side available services and the server side own registered services. The package edu.ufl.asdp.registry contains the classes that hold the registry tree that provides the methods to the service manager to perform various operations on the registry tree. When the service discovery system starts, the registry boots up by parsing the XML file for basic service tree and forms a basic tree

PAGE 46

35 structure. Later the services will be added by registering the own services at the server side and by discovering the available services in the environment at the client side. For the registered services at the server side, each one will have a service description and delivery file which will be used during the service delivery phase of Konark. 4.3 Service Manager Service Manager is the central manager that provides the APIs to the application builders to develop the Konark applications. It performs the following tasks: Provide Application level APIs to manage the services in the registry, Provides Application level APIs for discovering the services to the Client, Provides Application level APIs for advertising the services to the Server, Provides the APIs to the lower level-messaging layer to handle the advertised server services in the client and to handle the client discovery requests in the server, Delegates the task of sending and receiving the messages to the messaging layer. 4.3.1 Service Management APIs Service Manager provides the application level APIs to the client and servers to manage their services. In case of a client, these services are the available services in the environment while for the server, these are its own services to be advertised. The APIs are used to perform the following functions. For a client, these APIs can be used to perform the following tasks: Delete the available specific services, Set and reset exclusive filters for the generic services of the basic tree, Set and reset inclusive filters for the generic services of the basic tree, Get the view of the entire service tree. For a server, these APIs can be used to perform the following tasks:

PAGE 47

36 Register and unregister its services to be advertised. This process will link service node in the tree with its description and delivery file, Change the service attributes like service name, TTL and others, Get the view of the entire service tree. The package edu.ufl.asdp.clientservicemanager provides a class called ClientServiceManager that implements the above client operations while the ServerServiceManager class in edu.ufl.asdp.serverservicemanager package implements the above server operations. 4.3.2 Service Discovery Service Manager provides the Application Level APIs to the client to discover the desired services. Clients can discover the services either using the path of the generic services or by the keyword for very specific services. ClientDiscovery class in the edu.ufl.asdp.clientservicemanager package provides the method performDiscovery(string serviceDescription) takes either the path or the keyword. The discovered services will be added to the Christmas tree of the client by checking proper exclusive filters. performDiscovery(string serviceDescription) method abstracts the lower level details of the interaction of the service manager with the lower level-messaging layer. 4.3.3 Service Advertisement The servers can advertise their services whenever they want to or can do it as a periodic broadcast. The services must be registered before it’s advertised. The ServiceAdvertisement class in edu.ufl.asdp.serverservicemanager provides the application level API AdvertiseService(String servicePath) takes the path of the service as the input and performs the advertising for it. If this servicePath is for the generic service, it advertises all the registered service under that node. The service manager will

PAGE 48

37 interact with the lower level-messaging layer of the server to advertise these services using the service advertisement messages. The messaging layer multicast this on to the fixed group address. 4.3.4 Handling Client Discovery Requests Whenever the Lower level-messaging layer of the server receives the client discovery request, it hands it over to the client request handler defined in the class ClientRequestHandler of the edu.ufl.asdp.serverservicemanager. This request handler checks for the service availability. It responds back to the client by unicast if the service is available. If the discovery is by path, it gets all the registered services under that path otherwise it searches for its registered services list for keyword search. It responds back to the client using service advertisement message for each service using lower level messaging layer. 4.3.5 Handling Server Advertisement Messages Whenever the client’s low level-messaging layer receives the service advertisement message from the server, it hands it over to the Service Handler defined in the class AdvertisedServiceHandler of edu.ufl.asdp.clientservicemanager. This handler will first check for the exclusive filters before adding and activating this service in the registry tree. It checks if this service is a special interest to the user, and notifies the user about this service if so, may be by popping up a window. 4.4 Lower Level Messaging Layer This is the lowest layer of Konark SDP manager that provides the APIs to the Service Manager to send and receive unicast and multicast messages. There is a messaging layer for both the client and the server.

PAGE 49

38 4.4.1 Client Messaging Layer Client messaging layer handles two functions. The necessary classes are defined in edu.ufl.asdp.clientmessaginglayer. The functions include the discovery by the client and handling the service advertisement messages from the server. When the client wants to discover a service, service manager interacts with the messaging layer to perform the task of Service Discovery by providing it with the client discovery message. The client-messaging layer performs the following tasks, 1. It starts a listener thread that listens for the replies of the servers if they have the requested services. This thread will listen for some particular time out period, 2. It broadcasts the client discovery message that will be received by all the servers. The servers respond back with the service advertisement message to the thread running in 1. When the client service discovery system boots up, it starts a multicast listener thread on our fixed multicast group to listen to the advertised service messages of the server. Whenever it receives any message, it hands it over to the client request handler of the service manager. This listener thread can be started or stopped by APIs of ClientServiceManager. 4.4.2 Server Messaging Layer This layer performs two important tasks for the Service Manager of the server. The necessary classes have been defines in the package edu.ufl.asdp.servermessaginglayer. The tasks include the following things: Advertisement by the server: Service Manager gives the service advertisement message to the messaging layer when it wants to broadcast. The messaging layer opens a multicast socket and sends the message on a fixed multicast group, Responding to the client discovery requests: Whenever the service discovery system of the server boots up, it starts the discovery listener thread that listens to the client discovery messages. Whenever it receives a client discovery message, it

PAGE 50

39 hands it over to the client request handler. It also replies back to the client by unicast for its discovery message. 4.5 Leasing and other Utility Classes Leasing is provided by associating specific services with the time-to-live in minutes. Whenever the service is registered in the server, the time-to-live is provided that can be changed or increased anytime using Service Manager APIs. In the case of a client, whenever the advertised services gets added to the tree, they will be associated with the time-to-live. The package edu.ufl.asdp.leasing provides the lease thread that can be explicitly started and stopped using the Service Manager APIs. This thread, for every fixed interval of time checks for the expired services in the tree and removes them from the tree if they are expired. The package edu.ufl.asdp.util defines the few classes for the advertisement messages and discovery messages. It also defines few other miscellaneous classes for handling constants and other details. 4.6 Service Description and Delivery Verma [VER02] has covered Service Description and Delivery part of the Konark Protocol. It constitutes the following components: Service Description – The way the services are described, Service Delivery – The way the client will use the service once its discovered. 4.6.1 Service Description We define a simple XML language to define the services with their attributes and the operations they provide in the form of actions. If any service provider wants to write a service and register it, the following things should be done:

PAGE 51

40 Describe the service attributes like service name, type, URL of the description file and other information like keywords using the XML file by the guidelines provided by us, Implement an AppService interface defined in edu.ufl.asdp.services for handling SOAP requests. 4.6.2 Service Delivery Whenever the client wants to use a service, its URL will be invoked that gets the service description file. This file contains the service properties and the actions that can be invoked on it. The package edu.ufl.asdp.descutils defines the classes for service description. The user can invoke any action by providing the proper input parameters to it. The necessary classes for the delivery have been defined in the package edu.ufl.asdp.deliverutils. The server uses the microHTTP server to handle these client requests and all the necessary classes have been defined in the package edu.ufl.asdp.HTTP. 4.7 Implementation Platforms The entire middleware infrastructure for Konark service discovery and delivery can be implemented in any programming language on any operating system. We have implemented the Konark Protocol in two versions of Java. The two versions are as following: For Personal Java version 1.2 which is compliant with JDK1.1.8, For Java 2 Micro Edition (J2ME) CLDC/MIDP implementation [SUN01]. We have used the 802.11 as our wireless network in the ad-hoc mode. 4.7.1 Personal Java Implementation All the packages have been implemented in the Pjava1.2 that is compliant with JDK1.1.8. This infrastructure was then ported to the iPAQs running PocketPC 3.0. We

PAGE 52

41 have used Jeode JVM from Insignia Inc. [INS02] for the iPAQs. Few example services were created and were discovered, advertised and delivered by creating the ad-hoc network of 2 iPAQs and one laptop that had our middleware infrastructure. 4.7.2 J2ME CLDC/MIDP Implementation All the packages have also been implemented for J2ME version for CLDC/MIDP compliant devices. We used the Motorola iDEN phones to test our infrastructure with the above services used for Pjava1.2. The Appendix A describes the detailed summary of the packages and Application Programmer Interface that can used to build the Konark service discovery and delivery applications.

PAGE 53

CHAPTER 5 PERFORMANCE EVALUATION This chapter covers the performance evaluation of our protocol in both quantitative and qualitative terms. We made few basic assumptions and have simulated the ad-hoc environment with actual devices and services to quantify a few metrics, which were defined by us. 5.1 System Properties Assumptions Rate of arrival and departure of the devices and services can vary randomly that is based on their mobility behavior. However, the system was considered at some snap shot with “n” devices and “m” active services. There was more than one service per device. We used the 802.11 wireless medium. The packet loss and network partition issues along with the link layer performance weren’t considered. Currently, there is no technology independent benchmark for services and scenarios. Also there are no proper tools to measure the performance in such environment of devices and services [MAT01]. 5.2 Quantitative Approach To measure the performance quantitatively, we considered several factors. Our quantitative approach primarily dealt with first finding the metrics to evaluate the performance, and then quantifying them with the absolute values. Time and space are the most important factors in any computation. We considered almost forty services in the network with maximum of twenty services per device. Some of the metrics we identified are summarized below. 42

PAGE 54

43 5.2.1 Latency Time This is the average time a client takes to get the service by discovery. We measured the average response time for the discovery request by a client with respect to the number of services in the network. We considered three cases for this: To get “all” the services in the network, To get the specific service by “path”, To get the specific service by “keyword”. The graph in figure 5.1 shows the above three cases. The latency time to get “all” the services from the network increases as the number of services increase that is as expected. In case of search by “path”, the latency time almost remains same as it takes almost the same time to map the path to the tree and get the services for that path. In case of search by keyword, the time increases with the increase in the number of services, as the device has to search among more number of services. This factor is more dependent upon the number of services per device and the time that device takes to search its services for a particular keyword. In our experiments, we kept the number of devices constant and increased the number of services on these devices. So as the number of services on these devices increase, the latency time increases. Initially the services were not evenly distributed among the devices but were concentrated so the increase in time with increase in number of services is quite sharp. As the number of services increase, we evenly distributed these services among the devices so the time rise is not very sharp. We measure this factor again in our next metric. In general, this factor increases as the number of services increases per device that in turn means increase in the number of services in the network. This shows that the service discovery by the path for a service is always better

PAGE 55

44 Latency Time for 'ALL' Services,'Service by Path' and 'Service by keyword'.010020030040050060070080001020304050Active Services in the Network.Latency Time (milliseconds) AllServices Service byPath Service byKeyword. Figure 5-1 Latency Time Graph than other two kinds of discovery, which also explains the scalability factor of services for this protocol. 5.2.2 Service Access Time from the Registry Once the server receives a request from any client, it searches the registry. This search is based on the kind of request, which can be either by path or by keyword. We measured the time taken by the server complete this registry access, and so that the services can be sent back to the client. The access time has been measured for the requests of the following cases: To search and get “all” the services in the network, To search and get the specific service by “path”, To search and get the specific service by “keyword”.

PAGE 56

45 Access time of Services from Registry at the Server.0501001502002503003504000510152025Number of Services in a device.Access Time (milliseconds) AllServices Service byPath Service byKeyword Figure 5-2 Access Time Graph As shown in figure 5-2, the access time increases for searching “all” the services as the number of services increase. The access time for search by “path” remains almost the same. This happens as the registry maps the “path” to the tree and thus the search doesn’t get affected by the total number of services. In case of search by “keyword”, it makes a linear search, searching each service for the keyword thereby increasing the access time as the number of services increase per device. 5.2.3 Network Load To calculate the network load, we may assume that each service in the network is advertised every second. This will enable us to find the average network load with respect to the number of services that will be available in the network. This is the push mechanism by which all the active devices will come to know about all the active services in the network. The average length of the advertised message is 100bytes. As the number of services increase, the average network load will increase equivalently.

PAGE 57

46 Utilization: Push All the Services01000020000300004000050000600000102030405060Number of Services in the NetworkAvg. Network Load (bytes) Figure 5-3 Utilization for Push of All the Services Similarly, if the device polls for “all” the active services in a network by pull mechanism, we can also find the network load with respect to the active services. The graph will be similar to the one above as the network load will be same. This is because to get all the services in the network the client has to send only one message of service by path where the path will be the root-service. 5.3 Qualitative Approach Once few nodes come together and form ad-hoc network to share their services, it results in a peer-to-peer distributed system. Here we will discuss how our protocol measures against the various distributed system issues: Simplicity: “Large Complex Systems start out with a small successful system.” Ours is a simple system of services getting registered in a tree like fashion and being discovered and advertised by the devices. We provide a simple programmatic model to write simple Konark applications, Reliability: Our system is self-healing and self-organizing. It copes up with the network topology changes or even network partitions, by self-organizing behavior of ad-hoc networks. When some service become unavailable, the system self-heals by leasing mechanism,

PAGE 58

47 Scalability: Our system is scalable in terms of both the services and devices. New services can be added very easily into the registry at the server and the device storage is the only limitation. The number of devices can be also easily increased as we are using 802.11 wireless interface with IP-networking so that each device can pick up an IP by AutoIP technique, Robustness: Our system is stable and has predictable behavior.

PAGE 59

CHAPTER 6 APPLICATIONS AND USER INTERFACE We provide a simple application programmer interface (APIs) so that the actual services can be built easily and can be advertised, discovered and delivered. We have built a tool that provides a graphical user interface to demonstrate the capabilities of Konark. 6.1 Application Programmer Interface We provide simple APIs to build the KONARK applications. The edu.ufl.asdp.clientservicemanager package has two classes, ClientServiceManager and ClientDiscovery whose methods are the APIs for the clients side operations. Similarly edu.ufl.asdp.serverservicemanager class has two classes, ServerServiceManager and ServiceAdvertisement that provide the APIs for the server side operations. The Appendix A has the entire list of these APIs. We have created a few simple services like weather service, songs service, and printer service. 6.1.1 Server Side Operations The server has to perform the following steps to create a service and make it available to others over the ad-hoc network: Write the service XML file as described by our description language, Implement the interface AppService of the package edu.ufl.asdp.services for handling the SOAP requests, Start the HTTP Server for service delivery and the client discovery listener to listen to the client’s discovery requests using necessary APIs, 48

PAGE 60

49 Register the service under a particular path on fly by picking the file of 2) from the file system of the device, Advertise this registered service or the client can discover this service, Service delivery to the requested client. 6.1.2 Client Side Operations The client has to discover the services available in the proximity environment, handle the advertised services and use the service. The client can set exclusive and inclusive filters. The APIs provide the following operations: Start the necessary listeners to listen to the service advertisements, Discover the services based on tree-path or by keyword, Use the available service, Set inclusive and exclusive filters on the tree paths. 6.2 Konark User Interface To provide a simple, intuitive user interface and to demonstrate the functionalities of Konark protocol, we have developed a tool for the KONARK. We have developed few example services, which provide game service, weather service, printer service etc. Services will be created using an XML description file and implemented interface that will be packaged and put into the proper directory of the device. When the Konark tool starts, the main menu provides two options, “Server” and “Services”. “Server” has “Start P2P” option to start the necessary listeners and our microHTTP Server so that the device can join a fixed multicast group. The “Stop P2P” option will stop all this listeners.

PAGE 61

50 Figure 6-1 Starting Konark “View Service Tree” option under “Services” will display the tree on which the user can perform various operations using the menu “Tree Options”. Figure 6-2 Services Options

PAGE 62

51 Other operations under “Services” include “Keyword Search” for keyword search, “Available Services” to list all the available services in the tree and “Use Service” that allows the user to use particular service by just entering its name. Figure 6.2 shows these options. Figure 6.3 shows the service tree, which has one own service “Print Your Files” and one available service “Song for you”. Figure 6-3 Service Tree The “Tree Options” has operation “Discovery” to get all the services under a selected path and “Advertise” to advertise the registered services under the selected path of the tree. Figure 6.4 shows various options. The other options include setting and resetting the inclusive and exclusive filters in the form of “Wish List” and “Spam Control” respectively.

PAGE 63

52 Figure 6-4 Tree Options The figure 6-4 shows exclusive filter set on “Information”. The “Publish Services” has options “Register” and “Unregister”. “Register” is used to register a new service by picking up a class file of the implemented AppService interface from a local file system and “Unregister” to remove a registered service from the tree. The user can select the available service and use the option “Use Service” to use that particular service.

PAGE 64

CHAPTER 7 CONCLUSION AND FUTURE WORK This thesis described the design and implementation of discovery protocol part of KONARK in the previous chapters. We were able to design, implement and demonstrate the infrastructure for ad-hoc networks so that the devices in the ad-hoc network can share the services. This forms an important middleware component for pervasive computing. This enables peer-to-peer networking between the mobile devices in ad-hoc network. We provide APIs for the application developers to develop the Konark applications. Konark, as a whole provides the service description language based on XML to describe the services, and discovery, advertisement and delivery APIs to publish and discover services. We have built a simple graphical user interface demonstrating the functionalities of Konark that maps to these APIs. Few sample services have been developed and deployed with this infrastructure. Konark was implemented on Java enabled devices for J2ME CLDC/MIDP and Personal Java Platforms. We have done preliminary work in the performance evaluation of our discovery protocol. Lack of proper technology independent benchmark coupled with no proper tools to measure the performance in such environment of devices and services, motivated us develop few metrics and measure it. Few new things need to be incorporated into the protocol along with extension of the few existing things as a part of future work. They can be summarized below: 53

PAGE 65

54 Security: We haven’t taken into account any security problem at this moment. Security can be implemented at many levels starting from the formation of ad-hoc networks, to authenticating the identity of the devices that offers and uses the services, Better User Interface: We have developed a simple user interface but the capabilities were limited by the supported older version of Java. There is a need to develop user interface in terms of better look and feel for the users, Standardization of the basic service tree: There is a need to standardize the service tree of the generic services to cover any kind of services and also give the flexibility to add new services types.

PAGE 66

APPENDIX A APPLICATION PROGRAMMER INTERFACE This Appendix provides the list of APIs using, which the application builders can build the Konark Applications. Its been broadly divided into Client and Server side to build Konark clients and Konark servers. Client Side APIs These APIs are used to build a Konark Client who will discover and use the service. The client side APIs has methods from the classes of the package edu.ufl.asdp.clientservicemanager. Class: ClientDiscovery All the methods throw ClientException. Method: performDiscovery(String serviceDescription) Takes a service description and performs the discovery for this. The services will be added to the registry and returned. @param serviceDescription Service path or keyword. @return Vector of Service Names. Class: ClientServiceManager All the methods throw ClientException. Method: startAdvertisedListener() Starts the listener to listen to the server advertisement messages. @param none. @return none. 55

PAGE 67

56 Method: stopAdvertisedListener() Stops the listener, which listens to the server advertisement messages. @param none. @return none. Method: startLeaseThread() Starts the lease thread to check for the expired available services. @param none. @return none. Method: stopLeaseThread() Stops the lease thread, which checks for the expired available services. @param none. @return none. Method: setFilter(String servicePath) Sets the exclusive filter for “servicePath”. @param service Path. @return boolean – success or failure. Method: resetFilter(String servicePath) Resets the exclusive filter for “servicePath”. @param service Path. @return boolean – success or failure. Method: setInterest(String servicePath)

PAGE 68

57 Sets the inclusive filter for “servicePath”. @param service Path. @return boolean – success or failure. Method: resetInterest(String servicePath) Resets the inclusive filter for “servicePath”. @param service Path. @return boolean – success or failure. Method: getServiceURL(String serviceName) Gets the URL for this service name. @param service name. @return URL – String Method: getRemainingTime(String serviceName) Gets the remaining time for this service. @param service name. @return Time in mins. Method: deleteService(String servicePath, String serviceName) Deletes this available service. @param service path and service name. @return boolean – success or failure. Server Side APIs These APIs will be used to build the Konark Server. Class ServiceAdvertisment: All the methods throw ServerException. Method: performAdvertising(String serviceDescription)

PAGE 69

58 Performs the advertisement for this service name or service path. @param service path or service name. @return none. Class ServerServiceManager. All the methods throw ServerException. Method: startDiscoveryListener() Starts the discovery listener, which listens for the client discovery requests. @param none. @return none. Method: stopDiscoveryListener() Stops the discovery listener, which listens for the client discovery requests. @param none. @return none. Method: startLeaseThread() Starts the lease thread to check for the expired own services. @param none. @return none. Method: stopLeaseThread() Stops the lease thread, which checks for the expired own services. @param none.

PAGE 70

59 @return none. Method: registerService(AppService service, String filename, String servicePath) Register this “service” which implements the AppService interface at the “path” specified by servicePath and “fileName” is the XML description file. @param service – AppService Implementation, fileName – XML description file and servicePath – Path in the service tree under which it has to register. @return boolean – success or failure. Method: unregisterService(String servicePath, String serviceName) Unregisters this service “serviceName” registered under path “servicePath”. @param service path and service name. @return boolean – success or failure. Method: changeTimeToLive(String serviceName, int newTTL) Sets the TTL of the service “serviceName” to this newTTL. @param service name and new TTL. @return none.

PAGE 71

LIST OF REFERENCES [ADJ99] William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, and Jeremy Lilley, The design and implementation of an Intentional Naming System, Proc. 17th ACM SOSP, Kiawah Island, SC, December 1999. [ANH01] The Anhinga Project, Rochester Institute of Technology, http://www.cs.rit.edu/~anhinga/ , 2001. [CAT02] Octavian Catrina, Dave Thaler, Bernard Aboba and Erik Guttman, Zeroconf Multicast Address Allocation Protocol (ZMAAP), IETF Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-zmaap-02.txt , 2002. [CHE00] Harry Chen, Developing a Dynamic Distributed Intelligent Agent Framework Based on the Jini Architecture, Master's thesis, University of Maryland Baltimore County, January 2000. [CHE01] Harry Chen and Dipanjan Chakraborty, Service Discovery in the Future for Mobile Commerce, University of Maryland at Baltimore County, 2001. [CHE02] Stuart Cheshire and Bernard Ababa, Dynamic Configuration of IPv4 Link-Local Addresses, IETF Internet Draft, http://www.ietf.org/internetdrafts/draft-ietf-zeroconf-ipv4-linklocal-04.txt , 2002 [EDW99] W. Keith Edwars, Core Jini, 2nd Edition, The SUN Microsystems Press, Java Series, Prentice Hall, Upper Saddle River, New Jersey, 1999. [HAS01] Steve Hashman and Steven Knudsen, The Application of Jini technology to Enhance the Delivery of Mobile Services, http://wwws.sun.com/software/jini/whitepapers/PsiNapticMIDs.pdf , December 2001. [HAT01] M. Hattig, Zeroconf IP Host Requirements, IETF Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-09.txt , 2001. [HER01] Reto Hermann, Drik Husemann, Michael Moser, Michael Nidd, Christian Rohner, and Andreas Schade, DEAPspace – Transient Ad-Hoc Networking of Pervasive Devices, Computer Networks, Volume 35, pp. 411-428, 2001. 60

PAGE 72

61 [HP01] Hewlett Packard Company, Cool Town Project, http://www.cooltown.hp.com , 2001. [INS02] Insignia, Jeode PDA Edition, http://www.insignia.com/content/products/pda.shtml , 2002. [JXT01] The JXTA Project, Sun Microsystems, http://www.jxta.org , 2001. [KIA01] Michael Kiarcher and Prashant Jain, Ad HOC Networking Pattern Language, http://www.cs.wustl.edu/~mk1/AdHocNetworking.pdf , 2001. [MAT01] Olivier Mathieu, Doug Montgomery and Scott Rose, Empirical Measurements of Service Discovery Technologies, NIST Information Technology Laboratory, Advanced Networking Technologies Division, Gaithersburg, April 30 to May 4, 2001, PC 2001 Workshop. [MIL00] Brent Miller and Robert Pascoe, Salutation Service Discovery in Pervasive Computing Environments, An IBM Pervasive Computing White Paper, http://www-3.ibm.com/pvc/tech/salutation.shtml , February 2000. [NID00] Michael Nidd, Service Discovery in DEAPspace, Technical Report IBM Zurich Research Labs, Zurich, January 2000. [REK99] John Rekesh. UPnP, Jini and Salutation A Look at Some Popular Coordination Framework for Future Network Devices" Technical Report, California Software Lab, http://www.cswl.com/whiteppr/tech/upnp.html , 1999. [SAL97] The Salutation Consortium, Salutation Architecture Specification, http://www.salutation.org , October 1997. [SUN99] Sun Microsystems, JINI technology: http://www.sun.com/jini , January 1999. [SUN01] Sun Microsystems, Java 2 Micro Edition Technology for Creating Mobile Devices, White Paper, http://java.sun.com/j2me , February 2001. [UPN00] UPnP Forum, www.upnp.org , 2000. [VER02] Varun Verma, Konark – A Service Delivery Protocol, Master’s Thesis, University of Florida, Gainesville, August 2002. [WEI91] Mark Weiser, The Computer for the 21st Century, Scientific American, pp. 94-10, September 1991.

PAGE 73

62 [WEI93] Mark Weiser, Some Computer Science Problems in Ubiquitous Computing, Communications of the ACM, Volume 36, pp. 75-83, July 1993. [WEI96] Mark Weiser and John Seely Brown, Designing Calm Technology, PowerGrid Journal, v 1.01, http://powergrid.electriciti.com/1.01 , July 1996.

PAGE 74

BIOGRAPHICAL SKETCH Nitin Desai was born on May 22nd, 1978, in Belgaum, India. He obtained his undergraduate degree Bachelor of Engineering in computer science and engineering, from Sri Jayachamarajendra College of Engineering, Mysore, India, in September 1998. He joined Wipro Technologies in Bangalore, India, as a software engineer in October 1998. He worked there on several software development projects till August 2000. Then he decided to pursue the Master of Science degree in computer engineering, at the University of Florida. He was a teaching assistant for the class, Computer Organization, during his stay at the University of Florida. His areas of interest include pervasive and mobile systems, and distributed computing. After graduation, he will join Citrix Systems, Ft. Lauderdale, to take up a full time position. 63