moby a mobile peer to peer service and data network
Download
Skip this Video
Download Presentation
MOBY – A Mobile Peer-to-Peer Service and Data Network *

Loading in 2 Seconds...

play fullscreen
1 / 30

MOBY A Mobile Peer-to-Peer Service and Data Network - PowerPoint PPT Presentation


  • 174 Views
  • Uploaded on

MOBY – A Mobile Peer-to-Peer Service and Data Network *. Tzevetan Horozov 1 , Ananth Grama 1 , Sean Landis 2 & Venu Vasudevan 2 1 Dept . of Computer Sc i ences , Purdue University, W.Lafayette, IN 47907 {horozov, ayg}@cs.purdue.edu

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'MOBY A Mobile Peer-to-Peer Service and Data Network' - nhi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
moby a mobile peer to peer service and data network

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
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
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
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
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
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 technologies7
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

Underlying Technologies
challenges for moby
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
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 moby
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 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
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 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
Terminal Application
  • CommandSender interface
    • Based on javax.microedition.lcdui
    • CommandSender object on surrogate
    • Invoking methods on CommandSendermodifies 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 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
Services in MOBY
  • General Jini Services
  • System Jini Services
  • Peer Services
general jini 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
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
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
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
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 moby22
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
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
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
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
performance terminal application
Performance: Terminal Application
  • Benchmark application: basic objects like forms, text boxes, lists
  • Both devices run J2ME with 64K application memory
performance surrogate host
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

Performance : Mnode
conclusions future work
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
ad