1 / 22

Data Consistency in the Structured Peer-to-Peer Network

Data Consistency in the Structured Peer-to-Peer Network. Cheng-Ying Ou, Polly Huang Network and Systems Lab 台灣大學電機資訊學院電機所. Roadmap. Background Related Works Problem Definition Chord Replica Management System Consistency Enhancements Evaluation Conclusion. Structured P2P.

hana
Download Presentation

Data Consistency in the Structured Peer-to-Peer Network

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. Data Consistency in the Structured Peer-to-Peer Network Cheng-Ying Ou, Polly Huang Network and Systems Lab 台灣大學電機資訊學院電機所

  2. Roadmap • Background • Related Works • Problem Definition • Chord • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  3. Structured P2P • Distributed Hash Table (DHT) • A peer or data has a unique ID (key) • Key is generated by a hash function • A peer is responsible for a key space • Store data with keys within this range We want to keep data on P2P network Chord Key space: (8, 14] D9, D11, D14

  4. The Challenge of Replica Consistency • Churn • Peers join, leave, fail randomly • Fault-tolerant • Replicas to restore lost data • Updated frequently • Inconsistency between replicas Data consistency problem

  5. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  6. Replica Consistency Enhancements • B. Temkow, A.-M. Bosneag, X. Li, and M. Brockmeyer, “PaxonDHT: achieving consensus in distributed hash tables,” in Proceedings of the 2005 symposium on Applications and the Internet, 2006 • A. Muthitacharoen, S. Gilbert, and R. Morris, “Etna: a fault-tolerant algorithm for atomic mutable DHT data,” MIT-LCS-TR-933, Jun 2005 • Paxos • Each peer can do consensus • Request all values of replicas from other peers • Pick the latest version • Commit this value back to all replicas • Distributed consensus algorithm • 3-phases message exchanges (atomic updates)

  7. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  8. Problem Definition • How much do these enhancements help to improve the data consistency?

  9. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  10. Chord Protocols • Join • Find the successor by the key ID of the new peer • Stabilize • Check if the predecessor of the successor is itself periodically • If not, change the successor to the new one [2] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications,” in Proceedings of the 2001 ACM SIGCOMM Conference, 2001, pp. 149-160 Before joining Before stabilizing After stabilizing [2]

  11. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  12. Replica Management System • Rely on the underlying DHT • N replicas • Stored on the first N successors • Update • Update the value of data in backup storages • Restore • Ping periodically • If the predecessor doesn’t response • Fetch the backup objects within new key space • Restore them into its storage • Expand its key space • Remove other backups (2, 8] Partial ability of replica consistency (8, 14] (2, 14] (2, 8] (2, 8] (2, 8]

  13. Roadmap • Background • Related Works • Problem Definition • Chord • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  14. Replica Consistency Enhancement • Global Information • No message exchanges • Do consensus before restoring • Between whole backup storages • Compare all replicas • Keep the one with the latest value • Restore the lost ones to the backup storage D3 D3,D5 D3,D5 D3,D5

  15. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  16. Simulation Setups • Rocketfuel topology (AS1755) • 492 peers • Simulation time: 240000s (5 rounds) • 5 replicas[3] • Churn • Session life length • Distribution: Pareto [4][5] • Average: 1, 2, 3, 4, 5 hours [4] [5] • From file sharing (eMule) to Skype superpeer • Inter-session life length • Distribution: Exponential [4][5] • Average: 438.5, 877, 1315.5, 1754, 2192.5 minutes [4] [5] [3] J.Li, J. Stribling, T.gil, R.Morris, and F. Kaashoek, “Comparing the performance of distributed hash tables under churn,” 2004 [4] S.Guha, N.Daswani, and R. Jain, “A experimental study of the skype peer-to-peer VoIP system,” 2006 [5] M. Steiner, E. W. Biersack, and T. Ennajjary, “Actively monitoring peers in KAD,” 2006

  17. Metrics • Ratio of availability • Data are not lost and stored on correct peers • Ratio of inconsistency • Data don’t have latest version of value • Collected at the end of the simulation • Average of 5 results

  18. Availability • Enhancement is useless • Replica management system • It is seldom that losing data in the backup storages

  19. Inconsistency • Packets with acknowledgement & re-sending • If the updating packets cannot be delivered successfully, this peer will be thought as a failure peer.

  20. Roadmap • Background • Related Works • Problem Definition • Chord Protocols • Replica Management System • Consistency Enhancements • Evaluation • Conclusion

  21. Conclusion • Even when the churn rate is high • Replica consistency enhancement doesn’t perform better than the original one • A simple replica management mechanism is enough • Replica consistency enhancement appears to be overkill given its implementation complexity • Hopefully, our findings provide insights to the making of cost-effective design decisions

  22. Q & A

More Related