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

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 • 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. 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 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 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

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

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

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