MOBY A Mobile PeertoPeer Service and Data Network

1
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_at_cs.purdue.edu
• 2 Motorola Labs. IL02-2240, 1301, E. Algonquin
  Road, Schaumburg, IL 60196
• Sean_Landis-CSL044, Venu_Vasudevan-CVV012_at_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.
2
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

3
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

4
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

5
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

6
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 dont have sufficient
  resources to support Jini

7
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

8
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

9
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

10
Past Research vs. MOBY

• Majority of frameworks assume
• Static service sites
• Deterministic mapping of clients to services
  invariant on system state
• MOBYs objective
• Integrating transparent service migration and
  dynamic client mapping for seamless scalable
  performance

11
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

12
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

13
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

14
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

15
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 cant
  find service invokes appropriate RMI methods of
  Mnode to search over entire MOBY network
• Query response uses appropriate RMI methods to
  register peer service

16
Services in MOBY

• General Jini Services
• System Jini Services
• Peer Services

17
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

18
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

19
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

20
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

21
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

22
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

23
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

24
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

25
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

26
Screenshots
27
Performance Terminal Application

• Benchmark application basic objects like forms,
  text boxes, lists
• Both devices run J2ME with 64K application memory

28
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

29
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

30
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