MOBY – A Mobile Peer-to-Peer Service and Data Network*

Tzevetan Horozov1, Ananth Grama1,

Sean Landis2 & Venu Vasudevan2

1 Dept. of Computer Sciences, Purdue University, W.Lafayette, IN 47907{horozov, ayg}@cs.purdue.edu

2 Motorola Labs. IL02-2240, 1301, E. Algonquin Road, Schaumburg, IL 60196

{Sean_Landis-CSL044, Venu_Vasudevan-CVV012}@email.mot.com

Presented by Mehmet KoyutürkDept. of Computer Sciences, Purdue University

* This work is supported in part by National Science Foundation grants EIA-9806741, ACI-9875899, ACI-9872101, and Motorola Labs. Computing equipment used for this work was supported by National Science Foundation, Intel Corp. and Motorola Labs.

MotivationPeer-to-Peer networks are gaining

popularity Decentralized management Distributed resources Anonymity Examples: Napster, Gnutella, Freenet,

GnunetGoal: Building a similar network on the

wireless internet capable of sharing both data and services

ApplicationsDaily

Alternate routes in traffic Weather information, regional maps

Scientific domain Access to services on large computing platforms Access to services on data repositories

Can be done without relying on a central serverThin clients as both data sources and data sinks

PDA : Appointment books/calendar Sensors are sources of sensed data

Stationary vs. WirelessHigh mobility

devices come and go device/service mapping is highly dynamic the user adds value to the network

location specific information

Hardware/software limitations device/service interaction is limited

Low network bandwidth device network I/O must be minimized

Design ConsiderationsEnd-user transparency

Providing the end user a seamless view of the network

Ubiquity Facilitating a wide range of wired and

wireless components into the network

Ease of application integrationPerformance

Underlying Technologies

Jini A service broker architecture JAVA and RMI technology Clients/Services have no a-priori knowledge of

each other Ideal for wireless networks

Ad-hoc natureMust interact with devices that have different capabilities

Most mobile devices don’t have sufficient resources to support Jini

Underlying TechnologiesSurrogate Architecture

Specification Architecture to overcome

hardware/software limitations of the device

Allows device to run a surrogate on a wired host

Surrogate host: Java framework launched on the host-capable machine

Surrogate: Java program available on an HTTP server

Challenges for MOBY J2ME does not support class loading for

security and performance reasons Serious limitation if we want to instantiate

different protocol adapters in order to communicate with various services

Secure and reliable Jini services discovery over the internet

Performance Service locations and client mapping have

critical impact on resource utilization and end-user performance

Related Research P2P data networks: wide-spread deployment

Gnutella, Freenet, Limewire Focus on information sharing, but provide some underlying technologies

Enabling infrastructure for sharing services in distributed object-oriented frameworks

RMI, CORBA, DCOM, DOT-NET Foundational technologies for remote-method calls

Rover software toolkit Develop proxies for services to make mobile characteristics transparent

to applications The Ninja project

Targets robust, scalable distributed internet services for highly heterogeneous devices

JXTA Interoperability in data sharing, platform independence in service sharing

and ubiquity across devices

Past Research vs. MOBYMajority of frameworks assume:

Static service sites Deterministic mapping of clients to services

invariant on system state

MOBY’s objective Integrating transparent service migration

and dynamic client mapping for seamless scalable performance

MOBY System Architecture MOBY pieces together a number of

Jini domains consisting of a LAN that allows multicast with following components: Wireless access point Surrogate host Jini Lookup Service (JLUS) Jini Services Host (JSI) A central gateway called Mnode Jini services Wireless devices

MnodeExports methods to allow devices to search

MOBYProvides secure broadcast and forwarding of

queries Central server Tunneled communication

Responds to queriesStores a snapshot of the Jini domainLaunches/terminates System Jini Services

Device Connection

Device contacts MOBY and launches its surrogate

The surrogate gets a reference from SH to JLUS

The surrogate opens two TCP ports To keep surrogate alive Sending/receiving data

The device connects and brings up UI allowing the user to search the network

Terminal ApplicationCommandSender interface

Based on javax.microedition.lcdui CommandSender object on surrogate Invoking methods on CommandSender

modifies terminal application on device by creating objects on deviceObjects on device referenced with their hash

codes Interpretation of user response

Commands are created as objects in J2ME

Surrogate Architecture

Surrogate has three main functions Class loading: downloads protocol adapter, and

instantiates it with a reference to CommandSender Query initiation: first contacts JLUS, if can’t find

service invokes appropriate RMI methods of Mnode to search over entire MOBY network

Query response: uses appropriate RMI methods to register peer service

Services in MOBY

General Jini ServicesSystem Jini ServicesPeer Services

General Jini Services

Jini services provided by service provider companies

Statically registered with a JLUS in a given Jini domain

Manually launched by system administrators

System Jini ServicesWhy System Jini Services?

Interests for service change in long-run. Interests change in the short-run.

Stock quote, traffic during dayRestaurant / club finder during night

Improved client-service interaction Easy to locate

Which services could be SJS? Computation intensive: Photo-editor Small database: Yellow pages for a city Coherence of interest: Mapquest Real-time: Stock quotes

Peer Services

Services provided by peersDownloaded in a jar file and launched

on the surrogateExample: Talk daemon

Surrogate downloads, user can connect and chats with other devices

Client/Service InteractionService proxy

Downloaded from JLUS Usually in the form of RMI stubs that have

reference to service methods Provides only communication

Protocol adapter provides interaction between user and service Service provider supplies downloadable

device specific protocol adapters

Searching for Services in MOBYGeneral Jini Services

Surrogate searches for Jini service in local domain If not found, a secure MOBY search is performed Search returns reference to appropriate JLUS

System Jini Service If service not found, it must be launched

Peer Services Centralized server keeps track of URL storage Search performed by contacting a central authority Centralized server is not a bottleneck since

instantiation happens only when a service is restarted at an alternate location or replicated

Searching for Services in MOBYEach service has an XML descriptor

Jini servicesGeneral service descriptionURL for protocol adapters

Peer servicesInformation valuable to other peers that need to

contact the service

Query must be propagated to as many Mnodes as possible Broadcast with adjustable TTL Search can be repeated with a higher TTL UDP is used for communication between Mnodes

Resource Management in MOBY Deployment model: Phone companies and ISPs to

provide access to wireless subscribers Problems

Service distribution among Jini domains Hardware resource allocation

General Jini Services Each service provider company assigned an Mnode

Peer Services Administrators need to provide verification and storage

System Jini Services Require special handling Should be launched at locations where most requested Client latency optimized by moving services closer, replicating

services and terminating them

Managing System Jini ServicesTwo methods for launching a service

Deterministic launchCurrent Mnode tries to launch service locally If cannot launch, picks the closest node that

has sufficient hardware resources to launchGuarantees instantiation

Probabilistic launch There is a predetermined maximum distance at

which a service could be launchedFailure signalled if no Mnode with sufficient

resources in this neighborhood could be found

Security in MOBY

Each Mnode has a tuple (Port, IP, ID descr, Ti, D, PubKey) referred as Node ID

Central server signs Node IDMnodes secure-tunnel their communication

RSA used for session key exchange Boroadcast messages are secure-tunneled between

Mnodes with the obtained session keySecure queries are broadcast to secure MnodesThe result is associated with the replying Node

ID

Screenshots

Performance: Terminal Application

Benchmark application: basic objects like forms, text boxes, lists

Both devices run J2ME with 64K application memory

Test Palm OS Emulator

Handspring Platinum

Max # of components 201 201

Total time (sec.) 49 66

Average command per sec. 4 3

MOBY application start (sec.) 8 12

Performance : Surrogate Host

Performance depends on Hardware characteristics of the host machine Complexity of surrogate

Observations on an SH on Pentium III, 600 MHz, 256 RAM 100 surrogates arriving at the same time take 10 sec to

register over TCP Can support 50-100 concurrent surrogates at acceptable

latency

Performance : Mnode

Results on single domain are promisingAssumptions

Average phone cell hosts 50 users at a time 2 queries per user p/m, total 100 queries p/m

Mnode can process 12000 queries p/m120 hosts can maintain lossless broadcasting

Conclusions & Future WorkMOBY: A fully functional wireless P2P

network Infrastructure leverages on various existing

technologies to achieve design goals of end-user transparency, ubiquity, ease of application integration and performance

Difficult to quantify without a large-scale deployment

Future work Standardizing a service interface Quantification of performance