MOBY – A Mobile Peer-to-Peer Service and Data Network
Tzvetan Horozov
Motorola Labs.
IL02-2240, 1301, E. Algonquin Road
Schaumburg, IL 60196
[email protected]
Ananth Grama
Department of Computer Sciences
Purdue University
W. Lafayette, IN 47907
[email protected]
Venu Vasudevan
Motorola Labs.
IL02-2240, 1301, E. Algonquin Road
Schaumburg, IL 60196
Venu [email protected]
Sean Landis
Motorola Labs.
IL02-2240, 1301, E. Algonquin Road
Schaumburg, IL 60196
Sean [email protected]
Abstract
This paper describes the design and implementation of MOBY, a network for mobile peer-to-peer exchange of ser-vices and data. Constraints on computing power of mo-bile devices, limited hardware, networking, and software resources, and ad-hoc nature of mobile clients pose con-siderable challenges from the points of view of supporting performance goals, ease of service integration, and adapta-tion. These challenges are addressed in MOBY by dynamic service location and client mapping, surrogates for mobile clients, and standardized interfaces built upon off-the-shelf software components.
1. Introduction.
The emergence of peer-to-peer (P2P) networks for ac-cessing vast amounts of data and diverse services cou-pled with the heterogeneity of access devices is rapidly re-shaping existing network infrastructure. P2P networks facilitate seamless information flow in a scalable manner without relying on a centralized broker. P2P networks for handheld wireless devices are different from those in wired hosts in two important aspects. The limited resources avail-able to the device have implications for the design of suit-able services infrastructure. While it is reasonsuit-able to expect a wired host to provide certain underlying software support
This work is supported in part by National Science Foundation grants EIA-9806741, ACI-9875899, ACI-9872101, and Motorola Labs. Com-puting equipment used for this work was supported by National Science Foundation, Intel Corp. and Motorola Labs
for facilitating a peer-to-peer network, this might not be a valid assumption for handheld devices. Consequently, we must either rewrite our services or develop suitable middle-ware to bridge the gap between the service and the access device. The second major difference is the ad-hoc nature of handheld devices, which requires protocols for seamless in-tegration into the network. While this poses some technical challenges, it also presents opportunities for exposing data and services specific to device location. In order for a wire-less peer-to-peer network to utilize this potential, scoped service search mechanisms (based on location predicates in addition to service descriptors) must be developed. Service Networks such as MOBY have tremendous application po-tential. A driver stuck in traffic can compute alternate routes based on dynamic congestion information using a vehicle routing service. A passenger can download precise weather information and regional maps upon arrival by locating cor-responding services. All of this can be done without relying on a central server (such as weather.com or mapquest.com) from a thin client. In the scientific domain, MOBY enables access to services (applications) on large computing plat-forms at supercomputing centers as well as data repositories around the world. By suitably structuring these services, it is possible to use thin clients both as data sources (instru-ments, sensors) and as data sinks (output devices). In this framework, each mobile device potentially brings value to the network by providing useful data and services.
The motivating design considerations for MOBY are fourfold: (i) end-user transparency (providing the end user with a seamless view of the network); (ii) ubiquity (facili-tating a wide range of wired and wireless components into the network); (iii) ease of application integration (provid-ing API for developers); and (iv) performance. To facilitate
these design goals, MOBY leverages on two key existing technologies – Jini [3] and the Jini Technology Surrogate Architecture Specification [21]. The key advantage of Jini is that it provides a service broker architecture to clients that do not have a-priori knowledge about the services and ways in which they interact. This technology is ideal for the ad-hoc nature of wireless networks, where peers come and go and where self-healing services must interact with de-vices that have different capabilities. Unfortunately, most of these devices do not have sufficient resources to sup-port Jini. The Surrogate Architecture Specification provides a solution to the resource limitations of hand-held devices such as cell-phones and palm devices. It provides a speci-fication that allows the device to run a surrogate on a wired host. Jini and Jini Surrogates provide a strong founda-tion for creating a peer-to-peer network such as MOBY but they are not sufficient. There are several major challenges that must be resolved. The first challenge is the lack of class loading functionality in J2ME [2] - Micro Edition of Java 2 for small devices. This is a serious limitation if we want to instantiate different protocol adapters in order to com-municate with various services. The second issue relates to service discovery over the internet. While Jini services can be successfully discovered over a LAN, other services may be deployed on hosts that are not multicast reachable. For such services, we must provide mechanisms to extend Jini discovery over the Internet. Yet another issue relates to reliability and security in service discovery. Finally, with respect to performance, service location and client mapping have a critical impact on resource utilization and end-user performance. MOBY provides innovative new schemes for resource allocation, service location, and client mapping. This technique allows increased resources to be allocated to services that are more frequently accessed and positions such services “closer” to the clients that need them.
2. Related Research.
A wide range of projects have focused on various as-pects of the MOBY infrastructure. The popularity of peer-to-peer data networks such as Gnutella [1],and Freenet [12], has resulted in their widespread deployment. While the fo-cus of these networks is on information sharing (rather than service sharing), they provide some of the underlying tech-nologies for service location and mapping. Enabling infras-tructure for sharing services in distributed object oriented frameworks has been the subject of extensive research and development. Technologies such as RMI [6], CORBA [5], DCOM [11], DOT-NET [18] etc. provide foundational technologies for remote method calls. Several protocols for service location and discovery, such as Jini [3], Salu-tation [7], eSpeak [9], Service Discovery Service (SDS), Service Location Protocol (SLP) [22], and Wide Area
ex-tension to SLP (WASRV) [19], have also been developed. Application servers such as BEA WebLogic [8] and IBM WebSphere [10] have also been developed.
The Rover [16] software toolkit supports the construc-tion of mobile-transparent and mobile-aware applicaconstruc-tions. The key objective of this toolkit is to develop develop prox-ies for services that make the mobile characteristics trans-parent to applications. The Ninja project [14] targets ro-bust, scalable, distributed internet services for highly het-erogeneous devices. Ninja consists of the following com-ponents: Bases, which are powerful workstation cluster en-vironments; Units, which are service access devices; Ac-tive Proxies, for unit or service based adaptation, and Paths, which tie together units, services, and active proxies. It has been shown that the Ninja architecture provides the needed flexibility, facilitates application integration, and rapid ser-vice evolution.
JXTA [13] is a related P2P technology developed at Sun Microsystems with the objective of providing interoperabil-ity in data sharing, platform independence (language/OS) in service sharing, and ubiquity across the range of devices covered. JXTA consists of the core, which provides se-curity, monitoring, and group services among peers. The JXTA services layer provides a range of functionality such as indexing, searching, and sharing. The JXTA applications layer allows users to build P2P applications in the JXTA framework. Services and information are ‘advertised’ in XML descriptors. These descriptors are searched using a peer discovery protocol. Access to these services is pro-vided by the JXTA services layer.
3. MOBY System Architecture.
The general architecture of MOBY, as shown on Fig-ure 1, pieces together a number of Jini domains. Every Jini domain consists of a local area network that allows multi-cast and contains the following components:
1. Wireless access point through which wireless devices such as cell phones or PDAs connect to the network. 2. Surrogate Host (SH) which is compliant with the
Sur-rogate Architecture Specification. The SH provides
run-time environment to the surrogates of different wireless devices.
3. Jini Lookup Service. One or more (JLUS) which is used for service look-up and registration
4. Jini Services Host (JSH) is a machine that can launch different Jini services by instantiating a downloadable jar-file.
5. A central gateway, called Mnode, which has three main functions: establishing secure connection with other
Jini domains, keeping registration information about the local Jini domain, and controlling the launch of Jini services on the (JSH).
6. Jini services, each of which are registered with JLUS. 7. Wireless devices such as PDAs or cell phones, which
connect to the network through the wireless access point and launch their own surrogate on the SH. A device enters the network via a wireless access point closest to it. Upon connection, the device obtains an IP ad-dress as well as some initialization data. This requires some modifications to the existing connection protocol but such modifications are beyond the scope of this paper. Initializa-tion data contains informaInitializa-tion about the Surrogate Host IP address, its registration ports as well as the URL location of the surrogate that needs to be downloaded for the par-ticular device. After obtaining this information, the device runs a start-up application that is downloaded and installed in advance. This application initiates communication with the SH, which results in launching of a surrogate on the SH downloaded from the web. The device then opens a data connection with the surrogate and becomes a peer in MOBY.
As the surrogate runs Java 2 Platform Standard Edition (J2SE), it supports multicast and registers with JLUS in the local domain. After this the surrogate can discover all Jini services that are running locally. One such service is the
Mnode. An Mnode exports important methods that allow
the surrogates to participate in MOBY by sending queries in the network or by retrieving information about the local domain. Each Mnode serves as a gateway for its LAN and is responsible for connecting to other LANs. This allows the surrogates to browse the entire MOBY network for services. The secure establishment of connection between Mnodes as well as their communication is discussed in detail in Sec-tion 3.2.
3.1. Services in MOBY.
There are three classes of services in MOBY. The first class comprises of General Jini Services. These are services that maintain their registration according to the Jini specifi-cation. The second class of services is Peer Services. These are services that are downloaded in a jar file and instanti-ated on the surrogate. For example the device/surrogate can download a talk daemon, which allows the user to connect and chat with other devices. The third class of services is called System Jini Services. These are Jini services, which are managed by the network. They could be launched on de-mand at any particular Jini domain, or terminated if they are not popular among the peers of MOBY. They differ from
To other Mnodes Surrogates Mnode JLUS Mnode JLUS Mnode Jini Domain Jini Services Host
JLUS Mnode Jini Domain Jini Domain JLUS Jini Services Surrogate Host
Figure 1. High-level overview of the MOBY ar-chitecture.
the General Jini Services in that their instantiation or termi-nation is automatically controlled by the network according to a load balancing technique described in Section 7.4.
3.2. Security in MOBY.
MOBY provides extensive safeguards for services and service access. References to malicious services (e.g., a malicious map server advertised on a network) can lead to invalid data (false maps) and wastage of resources (network and processor resources at the wireless client). With the eventual goal of large-scale deployment, MOBY supports secure and reliable service discovery, i.e., if a client gets a reference to a service, the client must be able to identify the owner of that service.
Current versions of Jini do not provide secure service registration; any service can register with any description from anywhere within the domain. Other systems address this drawback using a variety of authentication mechanisms. These mechanisms are beyond the scope of this paper. MOBY simply uses these mechanisms to build upon a
lo-cal area network in which services registered with JLUS are secured. Each Jini domain has an associated Mnode, which connects it to the rest of MOBY. When users request a ser-vice, they get the description of the service along with the ID of the LAN where that service is registered. Thus, prior to using the service, a user can authenticate the ID of the service provider. In addition to the security provided by a given node about the origin of its services, the signed ID of nodes allow them to stay connected in a trusted network that identifies all malicious intrusions. Thus, when an Mnode sends a query on the network the result is from a trusted source.
In order to maintain such ID description, each Mnode must talk to an authority , which maintains a database for MOBY and is secure. The associated protocol uses public key cryptography, 512 bits, RSA and is as follows:
1. Mnode : (Ip, Port,
, ), where is
the public key of , Ip and Port are the IP address and port of the Mnode,
is a time stamp, and is
the public key of the Mnode.
2. looks in its database and verifies that the Port and IP address are of a registered service provider, such as
Mapquest, for example.
3. Mnode: ( (Port, Ip, ID,
, D)), where
is the public signature key of , D is the period
for which the signature is valid, ID is the identity of the Mnode that was obtained from the database in the previous step. This consists of an XML description of the node.
The tuple (Port, Ip, ID,
, D) is referred as node ID. After obtaining its signed ID each Mnode gets the IDs of some other Mnodes (from T, for example) and establishes communication with them. Each pair of nodes confirm each others’ IDs after which they select a session key and secure-tunnel all communication between them with that key. In this way queries sent on the network are not subject to sniff-ing.
3.3. Searching for Services in MOBY.
An XML descriptor is attached to each service. For Jini services this descriptor provides two important pieces of in-formation. The first one is a general service description that is used to match queries sent by peers. The second one supplies the URL from where a protocol adapter for differ-ent clidiffer-ent devices can be downloaded. For Peer Services the XML descriptor provides information that is valuable to other peers that need to contact that service.
Each Mnode maintains a database containing informa-tion about all running services (of any type) in the local
domain and their XML descriptors. Thus searching for a particular service requires propagation of the query to every
Mnode.
Secure MOBY Search. Search in MOBY is done via broadcast with a fixed TTL of the packet. For example the first search for a service will be with a lower TTL. If no result is returned then the client may decide to repeat the search with a higher TTL, which expands the search diame-ter. As described earlier each Mnode knows of a fixed num-ber of other Mnodes with which it communicates via secure tunnels and forwards all queries. The network protocol used is UDP. The reason for this is that UDP does not require expensive connection setup and maintenance which allows a host to send hundreds of queries per second to different hosts [15]. The drawbacks are that UDP packets can get lost or damaged [17]. However if a query that is sent to 20 hosts reaches only 15 of them, the objective of a multicast search is achieved; not to mention that the initiating client can repeat the query. MOBY does not guarantee that there is unique service description for each service but it guar-antees that there is a unique Mnode description. As there could be services offered by different sources that have the same description, the user of the device may choose the ser-vice that he/she needs by the description of the Mnode that is returned as a result.
Client/Service Interaction. The user of the device can communicate with services in the following way. Each ser-vice has a serser-vice proxy which is downloaded from the JLUS where the service is registered. The service proxy is usually in the form of RMI stubs that have a reference to the methods of the service. Each Jini service contains URL references to downloadable protocol adapters for dif-ferent devices. As suggested in the Service UI project [23], the service proxy should provide only the communication mechanism between the user and the service (RMI, TCP, etc.). Following this principle, the protocol adapter pro-vides the entire logic of the interaction between the user and the service. It is instantiated with a reference to the service proxy and adapts the communication between the service and the user, as it is device specific. This requires service providers to supply downloadable protocol adapters for different devices communicating with their service.
The three types of services in MOBY require three dif-ferent service search and client instantiation techniques:
General Jini Services. The surrogate searches for a Jini service in the local domain first. If the service is not found, a secure MOBY search is performed as described earlier. The search returns a reference to the JLUS where the Jini service and its proxy are registered, as well as a URL lo-cation from where an appropriate protocol adapter for that
service can be downloaded. This is sufficient information for the surrogate to launch the client, initializing it with the service proxy, which can communicate with the service.
System Jini Services. Search for System Jini Services is similar to the search described above, except that when the service is not found, it must be instantiated. This mecha-nism is described in detail in section 7.4.
Peer Services. Since these are services that are available as downloadable jar-files the only thing that a device needs as a result of a service search is the URL from where to download the jar-file. Since these services are maintained by MOBY administrators, a centralized server keeps track of the URL storage for each service. Thus the search for a
Peer Service is performed by contacting a central authority
that supplies the required information in order to instanti-ate the service on the device. Instantiation of services hap-pens only when a service is terminated and restarted at an alternate location, or when a service is replicated. Since this does not happen, the centralized server does not pose a significant bottleneck. In situations where the centralized server becomes a bottleneck, generalizations of this scheme to a distributed server can be developed.
4. Resource Management in MOBY.
The deployment model for MOBY is for phone com-panies and ISPs to provide access for their wireless sub-scribers. This would require certain hardware resources at the ISP. A crucial problem in this scenario relates to the ser-vice distribution in different Jini domains and the amount of hardware resources that should be allocated to a service.
General Jini Services do not present significant problems
for the administrators of the network. If a company de-cides to make some of its services available to subscribers, it reaches an agreement with MOBY administrators. Sub-sequently, it is assigned an Mnode which connects their ser-vices to the rest of the network. In the case of a Peer
Ser-vices MOBY administrators only need to provide
verifica-tion and storage for the byte-code of the services, which is instantiated on each device/surrogate. The System Jini
Ser-vices however require special handling for launching them
at the locations where they are most requested.
System Jini services perform several important functions in MOBY. Introducing services into the network, allocating resources to these services, and deallocating resources when they are no longer accessed requires constant network mon-itoring and resource management. Access patterns to ser-vices may be periodic, (for example, traffic and stock quote servers are likely to be accessed during certain times of the day) or a-periodic. System Jini services attempt to optimize
client latency by moving services closer, replicating them, and terminating them, while satisfying a variety of server resource constraints.
5. Classes of System Jini Services.
It is reasonable, at this point, to identify services that are mobile. In contrast to services that are tied to large databases and associated servers (such as search engines), there are other services that can easily take advantage of the dynamic deployment of System Jini Services. Content
adapters are services that provide computational
capabil-ities for thin clients. An example of such a service is a picture editor. Photographs, typically stored in compressed formats such as JPG might not be easily handled by thin clients. For example, the Handspring Platinum under J2ME supports only PNG formatted files. Thus the client requires a service to convert pictures to PNG format. Deploying this service in a specific Jini domain only requires download-ing and launchdownload-ing the service. Database facade is a sec-ond class of System Jini Services which includes those that require a small persistent store (database) to perform their function. A good example here is a yellow pages directory service for a particular city. The database could easily be downloaded into a particular Jini domain and the service could be deployed there. A third class of services, called
location-specific cache, includes those that take advantage
of coherence in user interests. For example, when using a Mapquest service, the likelihood of a peer requesting a map of the local area is high. This allows the service to cache and serve information to peers without having to contact the database on every query.
Other classes of services include real-time applications. For example a service could maintain a real-time connection to its central database and provide real-time stock quotes to different users at the same time. All these examples show that System Jini Services provide a powerful mechanism for fast and easy access to services.
6. The Need for System Jini Services.
Selecting services to be hosted on networks in the face of changing peer interests and demand is an important prob-lem. Allocating hardware resources to these services can be a problem not only in the long-run but in the short-run as well. For example, the demand for different services could vary with the time of day (for example, stock quote servers during the day and entertainment information servers dur-ing evendur-ing hours). It is highly desirable to allocate larger amounts of resources to more frequently accessed services. A second issue pertains to the movement of services closer to where they are frequently accessed. In the case
Figure 2. Screen shots of a MOBY client on a Palm emulator.
of RMI, for example, the latency of a method call made by the protocol adapter to the service determines the speed of application execution. Therefore it is desirable that the adapter (or the surrogate on which it is installed) be close to the service. This is especially the case for applications that make frequent calls to the service. Moving services closer to frequently accessed regions has the additional advantages of reducing load on the Mnodes (fewer queries) and network traffic. System Jini services allow such resource adaptation and service migration to occur transparently.
7. Prototype MOBY Implementation.
We now discuss specific details of our prototype MOBY implementation. We must note that this implementation has proven extremely stable over long periods of operation in a laboratory environment.
7.1. Terminal Application.
Our prototype implementation is based on Handspring Platinum hand-held devices. However the application will run on any device that has installed J2ME [2] with an MIDP [4] API implementation. The device must be ca-pable of downloading and instantiating a protocol adapter application for each service. However, the current version of MOBY does not support dynamic class loading. There are two reasons for this: security issues and hardware capa-bility.
In order to connect the hand-held device to MOBY we have developed a terminal application that is installed via
the HotSync cradle. Terminal applications are not new and provide the most natural solution for controlling applica-tions that are not running on the local machine. In our case, we have an application that runs on the surrogate (a jar file is being downloaded and instantiated) and we would like to get the resulting user interface for that application on the device’s screen.
MIDP contains a package javax.microedition.lcdui which allows us to create UI on the device. We take the commands from the classes in that package and create user interface called CommandSender with matching com-mands. The surrogate then instantiates an object that imple-ments this interface. Thus programmers can use the refer-ence to the CommandSender interface and issue commands at the surrogate which resemble those in the
javax.microedi-tion.lcdui package. Their invocation results in modification
of the terminal application on the device. The mechanics of the communication is hidden from the user by a sepa-rate data stream that is opened between the device and the
CommandSender object on the surrogate.
7.2. Surrogate Architecture.
The surrogate allows the device to communicate with the rest of the network. When the device starts its registration with the SH, it provides a reference to a jar-file where the surrogate’s byte code is stored. The SH downloads the jar-file and instantiates the surrogate.
Upon instantiation the surrogate opens two TCP sockets and waits for the device to connect. One of the connec-tions is used to keep the surrogate running and the other is used for sending/receiving data. The surrogate uses the Jini Technology IP Interconnect Specification [20], which allows it to get a reference to the JLUS from the SH.
Surrogate Mnode
Query stubs Service registration stubs
JLUS
Service registration stubs
Client registration stubs Service 2
Service 3 Service 1
Figure 3. Method calls by various MOBY com-ponents.
below:
Class Loading. As described earlier, when a surrogate discovers a service, it must also instantiate an appropriate protocol adapter to serve as a bridge between the service proxy and device client. When the surrogate downloads the adapter, it instantiates it with a reference to the
Command-Sender. Subsequently the protocol adapter can invoke the
methods provided by the interface and install the logic re-quired for its application on the device. At this point, the user can start communicating with the service. Thus the adapter classes will be downloaded and instantiated on the surrogate.
Query Initiation. The main communication between the surrogate and the rest of the network is in the form of RMI calls. Figure 3 shows the RMI usage by various components of MOBY. When the surrogate is instantiated on the SH, it uses RMI to register with JLUS and monitor all Jini services running locally. One such service is the Mnode. When the surrogate gets a reference to the Mnode, it uses the RMI methods that it exports in order to register the device. When the user initiates a query for a service, the surrogate first contacts JLUS to check if the service is present locally. If not the surrogate invokes the appropriate RMI methods of the Mnode, which initiate the search over the entire MOBY network.
Query Response. If the surrogate launches a peer service then that service must be advertised to the participants of the network. In this case, the surrogate uses the appropriate RMI methods of the Mnode to register the peer service with its initialization parameters.
7.3.
Mnode.
The Mnode is the router that connects the local Jini do-main to the rest of the network. As mentioned earlier, when a service provider decides to make some services available to the mobile devices in MOBY, it is assigned an Mnode together with some initialization parameters such as IP ad-dress and Port.
Upon start-up, each Mnode chooses a 512 bit RSA pub-lic/private session key pair. After it gets its identity signed by the central server , the node stores all information that can uniquely identify it in a file that is made available to the public. This file could be published on the internet or, in our case, it is supplied back to to be stored in its database.
When an Mnode has established its identity, the node re-quests some identity files from . As stores all identity files of the currently running Mnodes it is able to supply the files that identify hosts which are physically close to the re-questing node. This helps in building an evenly distributed
network around a fixed region and suits our needs as we as-sume that the user of the mobile device is interested in ser-vices that are physically proximate. After receiving some identity files the node connects to the corresponding hosts and establishes tunneled communication.
The Mnode serves the clients in the local domain in three ways: it registers with JLUS and monitors all active ser-vices, it registers any non Jini services that are started on the devices, and it allows devices to send queries to the rest of the network. Those functionalities are exposed to clients via RMI stubs as shown in Figure 3. In addition, the node also manages launching of System Jini Services as described in section 7.4.
7.4. Managing System Jini Services.
System Jini Services (SJS) are key components of
MOBY. The architecture on which those service are cur-rently launched is a simple host that downloads the service jar-file and instantiates the service. There are more sophisti-cated systems, which allow launching of a service remotely by passing it through a set of protocols. At this point, we introduce two methods for launching a service.
Deterministic Launch. As SJS are guaranteed to be found at any time in the system, if a requested service is not found, then it must be launched somewhere on the net-work. Deterministic launch guarantees the instantiation of a service and works as follows: the current Mnode tries to launch the service locally. If it succeeds, the result is re-turned to the device, otherwise, it queries the network for hardware resources and eventually gets a reply from several nodes that either have no SJS service running or have SJS services that are idle and can be terminated. The current
Mnode picks the “closest” node and asks it to perform the
launch of the SJS. If by this time that node had become busy then the next node is picked and the service launched there. Eventually the requested service is instantiated.
Probabilistic Launch. In a probabilistic launch a param-eter i is supplied which describes the maximum distance (in terms of number of hops) at which a service should be launched. For example, for i=2 the probabilistic launch re-turns a result if a service could be launched no more than 2 nodes away from the current Mnode. Otherwise, a failure is signaled.
7.5. Service Launch.
The algorithm for launching a service at each Mnode is shown in Figure 4. When a service request comes from the local domain the Mnode first checks if the service is re-quested often (a table is maintained indicating the frequency
if (often_requested) Service request Initiate search Service found Return result Return result deterministic_launch() F F T T F F if ( time elapsed > P ) hops ++ probab_launch (hops) T T F F T T F F if launched() Return result TT F F T T
Figure 4. Initiating a service launch in MOBY.
with which each service is requested). If this is not the case, then a regular search for the service is initiated. The search terminates either by finding the service or instantiating it as close as possible to the local domain.
If the service is considered to be requested often, a check is made to see if the service is already instantiated. If this is the case then a reference to it is returned. If not, the Mnode tries to instantiate it at distance hops. If successful, the re-sult is returned; if not, the number of hops is increased by one and the next instantiation is tried at distance hops +1. The parameter P is used to allow some time for the system to change. If a service cannot be instantiated close to the requesting client, then there is no need to try immediately, rather, it should wait some time and then try again. After a predetermined time interval, if a service continues to be requested, then it is instantiated as close as the current re-sources allow.
8. Concluding Remarks and Current Work.
In this paper, we have described a fully functional wire-less peer-to-peer network, MOBY. While only a small num-ber of applications have been integrated into the network at this stage, efforts are under way to standardize a service in-terface, which would allow a much larger class of services to be made available. Work on the MOBY network is pro-gressing along many avenues of research and development. Quantification of performance is one of the most difficult parts of the development process. While individual com-ponents, such as resource discovery across Mnodes, remote service invocation overhead, service migration, etc., can be independently quantified, it is difficult to quantify end-to-end performance without a large-scale deployment. With respect to development efforts, ongoing work focuses on making the infrastructure more robust and to extend it to other services and devices
References
[1] Gnutella home page. http://gnutella.wego.com.
[2] Sun Microsystems. 2 Micro Edition.
http://java.sun.com/products/j2mewtoolkit/.
[3] Sun Microsystems. Jini technology specification white pa-per. http://www.sun.com/jini/specs.
[4] Sun Microsystems. Mobile Information Device Profile ( ). http://java.sun.com/products/j2mewtoolkit/.
[5] Object Management Group. The common object request broker: Architecture and specification, 1995. Tech. Rep. Version 2.0, Object Management Group.
[6] Sun Microsystems. Java Remote Method Invocation, 1997. [7] Salutation Consortium. Salutation home page, 2000. http://
www.salutation.org/.
[8] BEA Systems. BEA WebLogic Application Servers, 2001. http://www.bea.com/products/weblogic/.
[9] Hewlett-Packard Inc. eSpeak: The Universal Language of E-Services, 2001. http://www.espeak. net/.
[10] IBM Corporation. IBM WebSphere Application Server, 2001. http:// www-4.ibm.com/software/webservers/. [11] N. Brown and C. Kindell. Distributed ComponentObject
ModelProtocol- DCOM/1.0, 1996. http://ds.internic.net/ internet-drafts/draft-brown-dcom-v1-spec-00.txt.
[12] I. Clarke, O. Sandberg, B. Wiley, and T. Hong. Freenet: A distributed anonymous information storage and retrieval system. In Proc. of the ICSI Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, 2000, Inter-national Computer Science Institute, 2000.
[13] L. Gong. Project jxta: A technology overview, 2001. http:// www.jxta.org/project/www/docs/TechOverview.pdf. [14] S. D. Gribble, M. Welsh, R. von Behren, E. A. Brewer, D. E.
Culler, N. Borisov, S. E. Czerwinski, R. Gummadi, J. R. Hill, A. D. Joseph, R. H. Katz, Z. M. Mao, S. Ross, and B. Y. Zhao. The ninja architecture for robust internet-scale systems and services. Computer Networks, 35(4):473–497, 2001.
[15] C. Grothoff, T. Horozov, C. Bennett, I. Patrascu, and T. Stef. Gnet – a truly anonymous networking infrastructure, 2001. Technical Report, Purdue University.
[16] A. D. Joseph, J. A. Tauber, and M. F. Kaashoek. Mobile computing with the rover toolkit. IEEE Transactions on Computers, 46(3):337–352, 1997.
[17] J. Kurose and K. Ross. Computer Networking: A Top-Down Approach Featuring the Internet. Addison-Wesley, 2000. [18] B. Meyer and S. of. The significance of dot-net. Software
Development, 8(14):51–60, 2000.
[19] J. Rosenberg, H. Schulzrinne, and B. Suter. Wide area net-work service location, 1997. IETF Internet Draft, 1997. [20] K. Thompson. technology ip interconnect
spec-ification, 2001. http://developer.jini.org/exchange/projects/ surrogate/specs.html.
[21] K. Thompson. technology surrogate
archi-tecture specification, 2001. http://developer.jini.org/ex-change/projects/surrogate/specs.html.
[22] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service location protocol, 1997. RFC 2165.
[23] B. Venners. The serviceui project, 2000. http://swww.sar-tima.scom/sjini/serviceui/index.html.
