Peer-to-Peer is Not Always Decentralized

1
Peer-to-Peer is Not Always Decentralizedwhen
Centralization is Good

• Nelson Minar
• ltnelson_at_monkey.orggt
• 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 Ive 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
Centralized

• Client/server
• Web servers
• Databases
• Napster search
• Instant Messaging
• Popular Power

7
Ring

• Fail-over clusters
• Simple load balancing
• Assumption
• Single owner

8
Hierarchical

• DNS
• NTP
• Usenet (sort of)

9
Decentralized

• Gnutella
• Freenet
• Hive
• Internet routing

10
(No Transcript)
11
Centralized Centralized

• N-tier apps
• Database heavy systems
• Web services gateways
• Grand Central

12
Centralized Ring

• Serious web applications
• High availability servers

13
Centralized Decentralized

• Clip2 Gnutella Reflector
• FastTrack / KaZaA
• Morpheus
• Email

14
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?

15
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

16
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?

17
Centralized

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

18
Ring

• 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

19
Hierarchical

• 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

20
Decentralized

• 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

21
Centralized Ring

• 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

Common architecture for web applications
22
Centralized Decentralized

• 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

Best architecture for P2P networks?
23
Centralized vs. Decentralized

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

24
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

25
Peer-to-Peer is Not Always Decentralizedwhen
Centralization is Good

• Nelson Minar
• ltnelson_at_monkey.orggt
• http//www.media.mit.edu/nelson/

Thanks to Marc Hedlund, Raffi Krikorian, Tony
White
26
(No Transcript)