View
216
Download
1
Category
Tags:
Preview:
Citation preview
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
Recommended