Transcript MOBY – A Mobile Peer-to-Peer Service and

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ürk
Dept. 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.
Motivation
Peer-to-Peer networks are gaining
popularity




Decentralized management
Distributed resources
Anonymity
Examples: Napster, Gnutella, Freenet,
Gnunet
Goal: Building a similar network on the
wireless internet capable of sharing
both data and services
Applications
 Daily
 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
server
 Thin clients as both data sources and data
sinks
 PDA : Appointment books/calendar
 Sensors are sources of sensed data
Stationary vs. Wireless
High 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 Considerations
End-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 integration
Performance
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 nature
 Must interact with devices that have different capabilities
 Most mobile devices don’t have sufficient
resources to support Jini
Underlying Technologies
 Surrogate 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 enduser 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 objectoriented 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. MOBY
Majority 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
Mnode
 Exports methods to allow devices to search
MOBY
 Provides secure broadcast and forwarding of
queries
 Central server
 Tunneled communication
 Responds to queries
 Stores a snapshot of the Jini domain
 Launches/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 Application
CommandSender interface
 Based on javax.microedition.lcdui
 CommandSender object on surrogate
 Invoking methods on CommandSender
modifies terminal application on device by
creating objects on device
Objects 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 Services
System Jini Services
Peer 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 Services
 Why System Jini Services?
 Interests for service change in long-run.
 Interests change in the short-run.
 Stock quote, traffic during day
 Restaurant / 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 peers
Downloaded in a jar file and launched
on the surrogate
Example: Talk daemon
 Surrogate downloads, user can connect
and chats with other devices
Client/Service Interaction
Service 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 MOBY
 General 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 MOBY
 Each service has an XML descriptor
 Jini services
 General service description
 URL for protocol adapters
 Peer services
 Information 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 Services
Two methods for launching a service
 Deterministic launch
Current Mnode tries to launch service locally
If cannot launch, picks the closest node that
has sufficient hardware resources to launch
Guarantees instantiation
 Probabilistic launch
There is a predetermined maximum distance at
which a service could be launched
Failure 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 ID
 Mnodes secure-tunnel their communication
 RSA used for session key exchange
 Boroadcast messages are secure-tunneled
between Mnodes with the obtained session key
 Secure queries are broadcast to secure
Mnodes
 The 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 promising
 Assumptions
 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/m
 120 hosts can maintain lossless broadcasting
Conclusions & Future Work
 MOBY: 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