Dr. Ian Wang Cardiff University, U.K.

Ian Wang, Cardiff University Peer-to-Peer and Grids What does the Peer-to-Peer paradigm offer Grids? Scalable Decentralized e.g. Kazaa, Gnutella scale to millions of peers Fault Tolerant No central point of failure Dynamic Dynamic resource discovery Lightweight Utilize low power resources (e.g. PCs) e.g. achieved a ‘grid’ of millions of home PCs Easy Installation What are the disadvantages? Security and Trust

Ian Wang, Cardiff University What is P2PS? Peer-to-Peer Simplified Lightweight Peer-to-Peer Infrastructure Dynamic, Decentralized Service Discovery Pipe-based Communication XML Advertisements and Queries Domain Independent Develop Peer-to-Peer Applications in multiple domains e.g. File Sharing, Distributed Computation, Instant Messaging Java Reference Implementation Simple, clean Java API

Ian Wang, Cardiff University P2PS Goals Simplicity Simplify the development of Peer-to-Peer Applications Scalability Ad-Hoc Networks containing millions of nodes Decentralized Discovery and Communication Extensibility Additional Transport Protocols Different Discovery Algorithms and Rendezvous Policies

Ian Wang, Cardiff University P2PS v JXTA Generic Peer-to-Peer Application Infrastructures Same Motivation Service Discovery and Pipe-Based Communication Differences in Realization… e.g. JXTA: Separate protocols for advertisement and discovery P2PS: Queries are specialized advertisements JXTA: Query for predefined advertisement types P2PS: Query for arbitrary advertisement types JXTA: Routing expressed implicitly in XML message envelope P2PS: Routing is endpoint resolution issue JXTA: Dynamically import module implementations P2PS: Not implemented (complexity doesn’t match benefit) Performance Expect P2PS to out perform JXTA (but no figures to back this up… yet)

Ian Wang, Cardiff University Discovery Example HelloWorld Client/Server Server Client ServerPipe ServerPipe Network Pipe “HELLO WORLD”

Ian Wang, Cardiff University Java Example (HelloWorld Server) public class HelloWorldServer implements MessageListener { public HelloWorldServer() throws IOException { Peer peer = new PeerImp(); peer.init(); adverts = peer.getAdvertisementFactory(); discovery = peer.getDiscoveryService(); pipes = peer.getPipeService(); // initialise server pipe advertisement pipead = (PipeAdvertisement) adverts.newAdvertisement (PipeAdvertisement.PIPE_ADVERTISEMENT_TYPE); pipead.setPipeName("serverPipe"); // create server pipe and attach listener InputPipe inpipe = pipes.createInputPipe(pipead); inpipe.addPipeListener(this); // publish server pipe advertisement discovery.publish(pipead); } public void messageReceived(MessageReceivedEvent event) { // display received messages } }

Ian Wang, Cardiff University XML Advertisements Standard Advertisements PipeAdvertisement ServiceAdvertisement EndpointAdvertisement EndpointResolverAdvertisement RendezvousAdvertisement GroupAdvertisement Extendible to New Advertisement Types Custom Content

Ian Wang, Cardiff University PipeAdvertisement Example advert id originating peer id pipe id pipe name pipe type (e.g. Standard, Bidirectional, Discovery)

Ian Wang, Cardiff University XML Queries Queries are Specialized Advertisements Queries are published exactly as for Advertisements Standard Queries PipeQuery ServiceQuery EndpointQuery etc. Extendible to New Query Types Custom Query Parameters

Ian Wang, Cardiff University PipeQuery Example advert id PipeAdvertisement optional peer id to match optional pipe name to match optional pipe type to match endpoint address Query Matching tag denotes XML as a Query matches in Advertisement matches in Advertisement, etc. Matching Adverts sent to replyEndpointAddress Alternatively replyPipeAdvertisement can be used

Ian Wang, Cardiff University Discovery Subnet/Pipes Discovery Pipe Standard P2PS Pipe Type Bidirectional Pipe Broadcasts Advertisements/Queries to all Peers in Subnet Receives Advertisements/Queries from all Peers in Subnet Implementation delegated to Endpoint Resolvers Typical implementation would be UDP Multicast Other implementations (e.g. bluetooth) equally valid Discovery Subnet Subnet covered by Discovery Pipe Scope of Subnet determined by Implementation e.g. UDP Multicast range, Bluetooth range

Ian Wang, Cardiff University Rendezvous Peers Link Discovery Subnets Cache Advertisements/Queries Forward Queries to other Rendezvous Peers Server Client Discovery Subnet Discovery Subnet Rendezvous ServerPipe ServerPipe ServerPipe ServerPipe Pipe “HELLO WORLD”

Ian Wang, Cardiff University Rendezvous Open Issues Which Peers become Rendezvous Peers? Sometimes obvious (e.g. head-nodes on clusters, a PC in a network of low-power edge peers) Sometimes not (e.g. a network of homogeneous machines) How do Rendezvous Peers initially locate existing Rendezvous Peers? Centralized Lookup Service? How is connectivity maintained in dynamic networks? Multiple policies available e.g. attempt to maintain connection with three other rendezvous Where is each Advertisements/Queries cached? Multiple policies available e.g. cache local adverts + all queries, distributed hash-table

Ian Wang, Cardiff University Pipes Virtual Communication Channels Transport Protocol and Endpoint Independent Only bound to specific Endpoints at connection time Bound using Endpoint Resolution Protocol Pipe Types Standard Assumed to be unreliable, unidirectional and not secure Actual properties depend on implementation protocol Bidirectional Same as Standard but Bidirectional Discovery Broadcast/Receive Messages within a Discovery Subnet Custom Types e.g. Secure, Reliable

Ian Wang, Cardiff University Endpoint Resolvers Responsible for binding virtual Pipes to actual Endpoints Resolvers discovered using Endpoint Resolver Advertisements Published/Discovered using standard Discovery mechanism Advertisements include: Peer IDs of Peers handled by the Resolver Transport Protocol and Pipe Types handled by the Resolver Endpoint(s) for querying the Resolver Peer sends Endpoint Query to Endpoint Resolver Contains ID of Pipe being resolved Endpoint Resolver returns actual Endpoint Address for the Pipe (if known)

Ian Wang, Cardiff University Endpoint Resolution abc ServerPipe Server Client TCP Resolver UDP Resolver TCP UDP “HELLO WORLD” Pipe abc xyz abc xyz abc … via Discovery Service

Ian Wang, Cardiff University Endpoint Resolver Benefits Late-Binding of Pipes to Endpoints Endpoint Address not specified in Pipe Advertisement Dynamic Endpoints Endpoints can be dynamically created, moved, destroyed Pipes can be relayed over multiple Protocols Gateways between networks (e.g. Bluetooth to TCP) Disadvantages: Speed Complexity Alternative: Use Endpoint Advertisements Directly Avoids Endpoint Resolver Protocols

Ian Wang, Cardiff University Peer Groups and Security Currently being developed with P2PS Dynamic Sub-Network of Cooperating Peers Reduce load on Rendezvous Peers Essential for Security Group Discovery Group Advertisements/Queries to discover existing Groups Group Resolvers to bind Groups to actual Endpoints Group Organization Group Rendezvous Peers Cache/forward Advertisements within Group Enforce Security by only forwarding to Authorized Peers No Discovery Subnet – Peers connect direct to Rendezvous Peers

Ian Wang, Cardiff University Java Reference Architecture Pluggable Services Discovery Service Rendezvous Service Pipe Service Endpoint Resolvers All Communication via Endpoint Resolvers Custom Network Protocols Custom Discovery Pipes TCP Resolver??? Resolver Discovery Service Rendezvous Service P2PS Peer Pipe Service UDP Resolver Network UDPTCP???

Ian Wang, Cardiff University Triana – P2PS Pipe (Input) P2PS Pipe (Output) P2PS Service Local Machine Remote Machine P2PS Pipe (Control) Network

Ian Wang, Cardiff University WSPeer Application deploypublishlocateinvoke deploy publish discover send P2PS WSPeer - WS Pipes

Ian Wang, Cardiff University Sensor Nets - srss.pf.itd.nrl.navy.mil Scalable Robust Self-organizing Sensor (SRSS) NRL (Navy Research Laboratory) Distributed, Self-Organizing Sensor Devices Wireless Networks including Wireless Multicast Simulation using NS2 P2PS in SRSS Sensors are Peers Dynamic Sensor Discovery in Hostile Environments Rendezvous Caching and Automatic Election SRSS/P2PS Infrastructure Agent-J Real world Java Applications within NS2 P2PSx P2PS within NS2

Ian Wang, Cardiff University Future Direction Develop Peer Groups and Security Secure Pipes (e.g. SSL) Group Authorization (e.g. X509 Credentials) Develop Pluggable Generic Pipe Properties e.g. reliability, encryption, http, error correction Layer over any pipe implementation Performance Evaluation Comparison with JXTA NS/2 Focus on Application Environments Triana, Sensor Nets, WSPeer

Ian Wang, Cardiff University P2PS Summary Peer-to-Peer Simplified Lightweight Peer-to-Peer Infastructure Dynamic, Decentralized Service Discovery Pipe-Based Communication XML Advertisement and Query Domain Independent Simple, Clean Java Reference Implementation For More Information: