1 / 26

Peer-to-Peer is Not Always Decentralized …when Centralization is Good

Peer-to-Peer is Not Always Decentralized …when Centralization is Good. Nelson Minar <nelson@monkey.org> http://www.media.mit.edu/~nelson/. Talk Overview. Where I come from Topologies of distributed systems Strengths and weaknesses Conclusions. Warning: Broad generalizations ahead.

duena
Download Presentation

Peer-to-Peer is Not Always Decentralized …when Centralization is Good

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Peer-to-Peer is Not Always Decentralized…when Centralization is Good Nelson Minar <nelson@monkey.org> http://www.media.mit.edu/~nelson/

  2. Talk Overview • Where I come from • Topologies of distributed systems • Strengths and weaknesses • Conclusions Warning: Broad generalizations ahead

  3. Systems I’ve Designed • MIT Media Lab: Hive • Distributed Agents for Networking Things • Distributed objects • Mobile agents • Fully decentralized (cheating a bit) • Popular Power • Give your computer something to dream about • SOAP-like client/server system • Mobile code • Fully centralized

  4. What is P2P Anyway? • Decentralized Systems: no • Popular Power fails test • Napster fails test • Most Instant Messaging fails test • Confuses topology with function • Edge Resources: yes • Small computers on edges contribute back • All peers are active participants

  5. Distributed Systems Topologies • Get away from fundamentalism • “Pure P2P”, “True P2P”, etc • Focus instead on system architecture • How do the pieces fit together? • Concentrate on connection topology • Which topology for which problem?

  6. Client/server Web servers Databases Napster search Instant Messaging Popular Power Centralized

  7. Fail-over clusters Simple load balancing Assumption Single owner Ring

  8. DNS NTP Usenet (sort of) Hierarchical

  9. Gnutella Freenet Hive Internet routing Decentralized

  10. N-tier apps Database heavy systems Web services gateways Grand Central Centralized + Centralized

  11. Serious web applications High availability servers Centralized + Ring

  12. Clip2 Gnutella Reflector FastTrack / KaZaA Morpheus Email Centralized + Decentralized

  13. What about other topologies? • Centralized + Hierarchical? • Back end tree of information • Caching architectures • Decentralized + Ring? • P2P network of fail-over clusters • Decentralized + Hierarchical? • Decentralized + Centralized?

  14. Strengths and Weaknesses • Plenty of topologies to choose from • What is each kind good for? • Need a set of properties to measure • Caution: What follows is very high level

  15. Things to Measure • Manageability • How hard is it to keep working? • Information coherence • How authoritative is info? (Auditing, non-repudiation) • Extensibility • How easy is it to grow? • Fault tolerance • How well can it handle failures? • Security • How hard is it to subvert? • Resistance to legal or political intervention • How hard is it to shut down? (Can be good or bad) • Scalability • How big can it grow?

  16. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable System is all in one place All information is in one place No one can add on to system Single point of failure Simply secure one host Easy to shut down One machine. But in practice? Centralized

  17. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable Simple rules for relationships Easy logic for state Only ring owner can add Fail-over to next host As long as ring has one owner Shut down owner Just add more hosts Ring

  18. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable Chain of authority Cache consistency Add more leaves, rebalance Root is vulnerable Too easy to spoof links Just shut down the root Hugely scalable – DNS Hierarchical

  19. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable Very difficult, many owners Difficult, unreliable peers Anyone can join in! Redundancy Difficult, open research No one to sue! (…but follow $) Theory – yes : Practice – no Decentralized

  20. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable Just manage the ring As coherent as ring No more than ring Ring is a huge win As secure as ring Still single place to shut down Ring is a huge win Centralized + Ring Common architecture for web applications

  21. Manageable Coherent Extensible Fault Tolerant Secure Lawsuit-proof Scalable Same as decentralized Better than decentralized Anyone can still join! Plenty of redundancy Same as decentralized Still no one to sue Looking very hopeful Centralized + Decentralized Best architecture for P2P networks?

  22. Centralized vs. Decentralized • Centralized is pretty good! • Manageable • Coherent • Security • Decentralized is exciting • Extensible • Massive fault tolerance • Lawsuit-proof • Scalability is the big question

  23. Conclusions • Centralized is easy to deal with • Major architecture for distributed systems • Combines well with rings • Decentralized is good, needs research • Coherence, Manageability, Security • Scalability • Hierarchical is overlooked • Combining architectures is powerful

  24. Peer-to-Peer is Not Always Decentralized…when Centralization is Good Nelson Minar <nelson@monkey.org> http://www.media.mit.edu/~nelson/ Thanks to Marc Hedlund, Raffi Krikorian, Tony White

More Related