![Page 1: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/1.jpg)
1
The Design of a RobustPeer-to-Peer System
Gisik Kwon
Dept. of Computer Science and Engineering
Arizona State University
Reference: SIGOPS European Workshop 25/09/2002
Rodrigo Rodrigues(MIT)
![Page 2: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/2.jpg)
Arizona State University2
Scalable Computing Lab.
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
![Page 3: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/3.jpg)
Arizona State University3
Scalable Computing Lab.
Architecture
ConfigurationService P2P Nodes
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
![Page 4: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/4.jpg)
Arizona State University4
Scalable Computing Lab.
Configuration Service
Four main functions:– Admission control– Node monitoring– Deciding on a new configuration– Propagating configuration information
CS nodes carry BFT protocol [CL99]
![Page 5: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/5.jpg)
Arizona State University5
Scalable Computing Lab.
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
![Page 6: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/6.jpg)
Arizona State University6
Scalable Computing Lab.
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
![Page 7: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/7.jpg)
Arizona State University7
Scalable Computing Lab.
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
![Page 8: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/8.jpg)
Arizona State University8
Scalable Computing Lab.
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
Lookup
Storage
Application
Lookup
Storage
Lookup
Storage
Client Server Server
![Page 9: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/9.jpg)
Arizona State University9
Scalable Computing Lab.
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
![Page 10: 1 The Design of a Robust Peer-to-Peer System Gisik Kwon Dept. of Computer Science and Engineering Arizona State University Reference: SIGOPS European Workshop](https://reader036.vdocument.in/reader036/viewer/2022081821/56649e725503460f94b71a06/html5/thumbnails/10.jpg)
Arizona State University10
Scalable Computing Lab.
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)