140 likes | 149 Views
This paper discusses the design choices and considerations in peer-to-peer (P2P) infrastructure for collaborative computing in higher education. It explores topics such as locations vs names, network vs app-level routing, RPC vs asynchronous messaging, lookup problem, specialization, incentives, and common ground. The paper also examines the challenges and potential solutions in these areas.
E N D
Design Choices inP2P Infrastructure Wes Felter IBM Austin Research Lab wmf@austin.ibm.com Collaborative Computing in Higher Education
P2P Infrastructure • Choices common to many P2P systems • Locations vs. Names • Network vs. App-Level Routing • RPC vs. Asynchronous Messaging • Lookup • Specialization • Incentives • Common Ground? Collaborative Computing in Higher Education
Locations vs. Names • Applies to peers, data, services • Locations = URLs, Names = URNs • Locations are simpler, faster, but inhibit replication • Used by Napster, Gnutella • Names require directory service and namespace management • Used by Freenet, Mojo Nation, OceanStore Collaborative Computing in Higher Education
Network vs. App-level routing • Network routing is “free”, minimizes latency • Used by Napster, Mojo Nation • App-level routing can optimize for different metrics (e.g. privacy), provide multicast and replication • Used by Freenet, OceanStore • Hybrids can work • Gnutella routes queries, but sends data direct Collaborative Computing in Higher Education
Network Routing Collaborative Computing in Higher Education
Application-Level Routing Collaborative Computing in Higher Education
Application-Level Routing 2 Collaborative Computing in Higher Education
RPC vs. Async Messaging • RPC has easy programming model, but: • Usually requires threads • Can encourage ignoring failures • Asynchronous messaging • A different programming model (maybe) • Use event loops instead of threads • Design protocols as state machines Collaborative Computing in Higher Education
The Lookup Problem • Map keys to values • Minimize memory/storage use • Minimize network round trips • Be reliable (despite unreliable peers) • Have an infinite “horizon” • Resist attacks Collaborative Computing in Higher Education
Specialization • All peers can perform exactly the same services • Freenet • Or peers can specialize • Simple case: Sharing or not • More sophisticated: Gnutella Reflector, Mojo Nation index “trackers” • Some systems automatically elect “super-peers” based on their resources Collaborative Computing in Higher Education
An Unsolved Problem: Incentives • Many P2P systems ask users to provide resources • Why should they? • Freeloading Tragedy of the commons • Don’t prohibit what you can’t prevent • Reputations? • Money? Real or Play? Collaborative Computing in Higher Education
Is there a common ground? • Naming • SHA-1 is already popular • Messaging • HTTP and XML protocols (XML-RPC, SOAP) • Sun’s JXTA is trying, with little adoption • Directories Collaborative Computing in Higher Education
Moving Up a Level • We know the primitives • Are architectural models useful? • Data-oriented • Event-oriented • ? Collaborative Computing in Higher Education
The End Wes Felter wmf@austin.ibm.com Collaborative Computing in Higher Education