1. 1 Secure Peer-to-Peer File Sharing Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, Hari Balakrishnan http://www.pdos.lcs.mit.edu/chord MIT Laboratory for Computer Science

2. 2 SFS: a secure global file system One name space for all files Global deployment Security over untrusted networks Server Oxygen client Client MIT H21 /global/mit/kaashoek/sfs

3. 3 SFS results Research: how to do server authentication? –Self-certifying pathnames –flexible key management Complete system available –www.fs.netwww.fs.net –80,000 lines of C++ code? –Toolkit for file system research System used inside and outside MIT Ported to iPAQ

4. 4 New direction: peer-to-peer file sharing How to build distributed systems without centrally-managed servers? Many Oxygen technologies are peer-to-peer –INS, SFS/Chord, Grid Chord is a new elegant primitive for building peer- to-peer applications

5. 5 Peer-to-peer sharing example Internet users share music files –Share disk storage and network bandwidth –Nodes are less reliable than centrally-managed ones Internet

6. 6 Goal: Better Peer-to-Peer Storage Lookup is the key problem Lookup is not easy: –GNUtella scales badly –Freenet is imprecise Chord lookup provides: –Good naming semantics and efficiency –Elegant base for layered features

7. 7 Lookup problem N3 N5 N6 N4 N2 N1 Author Insert(name, document) Consumer ? Fetch(name) –Current systems don’t scale: GNUtella, FreeNet

8. 8 Chord Architecture Interface: –lookup(DocumentID)  NodeID, IP-Address Chord consists of –Consistent Hashing –Small routing tables: log(n) –Fast join/leave protocol

9. 9 Consistent Hashing N32 N90 N105 D80 D20 D120 Example: Node 90 is the “successor” of document 80. (0) Circular 7-bit ID space

10. 10 Chord Uses log(N) “Fingers” (0) N80 knows of only seven other nodes. N80 ½ ¼ 1/8 1/16 1/32 1/64 1/128 Circular 7-bit ID space

11. 11 Chord Finger Table (0) N32 N60 N79 N70 N113 N102 N40 N52 33..33N40 34..35N40 36..39N40 40..47N40 48..63N52 64..95N70 96..31N102 Node n’s i-th entry: first node  n + 2 i-1 N32’s Finger Table N80 N85

12. 12 Chord Lookup 33..33N40 34..35N40 36..39N40 40..47N40 48..63N52 64..95N70 96..31N102 N32’s Finger Table Node 32, lookup(82): 32  70  80  85. 71..71N79 72..73N79 74..77N79 78..85N80 86..101N102 102..5N102 6..69N32 N70’s Finger Table (0) N32 N60 N79 N70 N113 N102 N40 N52 N80 N85 81..81N85 82..83N85 84..87N85 88..95N102 96..111N102 112..15N113 16..79N32 N80’s Finger Table

13. 13 New Node Join Procedure (0) N32 N60 N80 N70 N113 N102 N40 N52 21..21 22..23 24..27 28..35 36..51 52..83 84..19 N20’s Finger Table N20

14. 14 New Node Join Procedure (2) (0) N32 N60 N80 N70 N113 N102 N40 N52 21..21N32 22..23N32 24..27N32 28..35N32 36..51N40 52..83N52 84..19N102 N20’s Finger Table N20 Node 20 asks any node for successor to 21, 22, …, 52, 84.

15. 15 New Node Join Procedure (3) (0) N32 N60 N80 N70 N113 N102 N40 N52 21..21N32 22..23N32 24..27N32 28..35N32 36..51N40 52..83N52 84..19N102 N20’s Finger Table N20 Node 20 moves documents from node 32. D114..20

16. 16 Chord Properties Log(n) lookup messages and table space. –Log(1,000,000)  20 Well-defined location for each ID –No search required Natural load balance Minimal join/leave disruption Does not store documents…

17. 17 File sharing with Chord Chord Key/Value Client App (e.g. Browser) Client Server lookup(id) get(key) put(k, v) Fault tolerance: store values at r successors Hot documents: cache values along Chord lookup path Authentication: self-certifying names

18. 18 Chord Status Working Chord implementation SFSRO file system layered on top Prototype deployed at 12 sites around world Understand design tradeoffs

19. 19 Open Issues Network proximity Malicious data insertion Malicious Chord table information Anonymity Keyword search and indexing

20. 20 Chord Summary Chord provides distributed lookup –Efficient, low-impact join and leave Flat key space allows flexible extensions Good foundation for peer-to-peer systems http://www.pdos.lcs.mit.edu/chord