1 / 10

The Design of a Robust Peer-to-Peer System

Explore the design considerations for a robust peer-to-peer system storing application states such as mail services. The paper discusses architecture, configuration services, admission control, node monitoring, and configuration information dissemination for fault tolerance. It emphasizes correctness, reconfiguration, and state transfer.

robertasmith
Download Presentation

The Design of a Robust Peer-to-Peer System

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. The Design of a RobustPeer-to-Peer System Reference: SIGOPS European Workshop 25/09/2002 Rodrigo Rodrigues(MIT) Gisik Kwon Dept. of Computer Science and Engineering Arizona State University

  2. Motivation • What if we wanted to store the state of the application in a P2P system? • E.g., mail service, archiving • Need a robust P2P storage system • Current algorithms do not provide reliable service: • No admission control • Trust configuration information • Vulnerable to malicious routing • Tolerance to Byzantine faults

  3. Configuration Service P2P Nodes Architecture • Configuration Services(CS) • Selected statically(a subset of P2P nodes) or dynamically • P2P nodes • set of servers, not clients • Common to equip with • Co-processor, read-only disk, watch-dog timer, Cryptographic co-processor

  4. Configuration Service • Four main functions: • Admission control • Node monitoring • Deciding on a new configuration • Propagating configuration information • CS nodes carry BFT protocol [CL99]

  5. Admission Control • Prevents single user controlling large fraction of the ID space • Maintains the list of node • <ID, IP, public key> • Hard to do in volunteer-based system • We assume servers • Nodes have public / private keys

  6. Node Monitoring • Detection fault node • Fail-stop failure: ping protocol • Byzantine failure: hard! • proactively recovered frequently -> restart from the correct code in read-only disk -> copy state from other nodes • All CS do its own monitoring for all P2P nodes

  7. Configuration Information • What to propagate? • Incomplete config is a limitation of p2p • Disseminate entire config • Transmit using diffs • When to propagate? • Server machines: not very often (e.g., every hour) • Configs include start and expiration times • Periodically deciding the new config • Using non-deterministic choices validation • Send eviction request to other CS -> validation

  8. Application Storage Storage Storage Lookup Lookup Lookup Client Server Server Architecture – P2P Nodes • Lookup layer • Periodically receive the latest config from CS • Notify to storage layer • Storage layer • Uses Byzantine quorums to store data • Data placement algorithm assigns 3 f + 1 replicas to each data item

  9. Correctness Condition • “At any moment, any group of 3 f +1 replicas of a data item contains no more than f faulty replicas” • Reconfiguration must be frequent enough to preserve this invariant

  10. State Transfer • During reconfiguration, set of replicas may change • Replica finds out of new configuration: • Know old configuration • Pulls data items from old replicas (as seen before)

More Related