Can ppt
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
46
On Slideshare
46
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • As d goes to log(n), total path length is log(n). Same as chord or pastry.

Transcript

  • 1. University College Of Engineering, Kota CONTENT ADDRESSABLE NETWORK Presented by – ALKA 11/638(CP-1) Submitted To – C.P. Gupta (Asso. Prof. & HOD of CP & IT Dept.) Mrs. Iti Sharma
  • 2. Contents 1. Introduction to CAN 2. CAN Routing 3. CAN Construction 4. CAN Problems 5. Node departure 6. Architecture improvements a. Path Latency Improvement b. Hop Latency Improvement c. Mixed approaches 7. CAN Cons 8.CAN Pros 9.CAN summary 10.CAN References
  • 3. What is CAN? The goal was to make a scalable peer-to-peer file distribution system Napster problem: centralized File Index Gnutella problem: File Index completely decentralized • There is a single point of failure: Low data availability • Non scalable : No way to decentralize it except to build a new system • Network flood: Low data availability • Non scalable: No way to group data CAN - Content Addressable Network
  • 4. What is CAN? CAN - Distributed, Internet-Scale, Hash table. CAN provides Insertion, Lookup and Deletion operations under Key, Value pairs (K,V), e.g. file name, file address • CAN is designed completely Distributed (does not require any centralized control) • CAN design is Scalable, every part of the system maintains only a small amount of control state and independent of the no. of parts • CAN is Fault-tolerance (It provides a rooting even some part of the system is crashed) CAN features
  • 5. ABOUT CAN • Usage: P2P file-sharing systems, large scale storage management systems, wide-area name resolution services. • It was one of the original four distributed hash tables introduced concurrently. (Chord, Pastry and Tapestry)
  • 6. Content-Addressable Networks (CAN) • d-dimensional hyperspace with n zones 6 y Peer Keys Zone x
  • 7. CAN Routing • d-dimensional space with n zones • Two zones are neighbors if d-1 dimensions overlap 7 y x [x,y] Peer Keys lookup([x,y])
  • 8. Routing in a CAN A routing message hops from node to node, Getting closer and closer to the Destination. A node only knows about its immediate Neighbors Routing Path Length is (d/4)(n1/d) As d approaches log(n), the total Path length goes to log(n). 8
  • 9. CAN Construction Joining CAN 1.Pick a new ID [x,y] 2.Contact a bootstrap node 3.Route a message to [x,y], discover the current owner 4.Split owners zone in half 5.Contact new neighbors 9 y x New Node [x,y]
  • 10. CAN Construction
  • 11. CAN architecture: Access How to get an access to CAN system 1. CAN has an associated DNS domain 2. CAN domain name is resolved by DNS domain to Bootstrap server’s IP addresses 3. Bootstrap is special CAN Node which holds only a list of several Nodes are currently in the system User scenario 1. A user wants to join the system and sends the request using CAN domain name 4. The user chooses one of them and establishes a connection. 2. DNS domain redirects it to one of Bootstraps 3. A Bootstrap sends a list of Nodes to the user
  • 12. CAN problems Main problems: 1. Routing Latency a. Path Latency - avg. # of hops per path b. Hop Latency - avg. real hop duration 2. Increasing fault tolerance 3. Increasing data availability Basic CAN architecture archives: 1. Scalability, State of distribution 2. Increasing data availability (Napster, Gnutella)
  • 13. CAN construction: Node departure Node is crashed 1. Periodically every node sends a message to all its neighbors 2. If Node does not receive from one of its neighbors a message for period of time t it starts a TAKEOVER mechanism 3. It sends a takeover message to each neighbor of the crashed Node, the neighbor which did not send a periodical message 4. Neighbors receive a message and compare its own Zone with the Zone of the sender. If it has a smaller Zone it sends a new takeover message to all crashed Node neighbors. 5. The crashed Node’s Zone is handled by the Node which does not get an answer on its message for period of time t Data stored on the crashed Node are unavailable until source owner refreshes the CAN state.
  • 14. CAN construction: Node departure Node departure b. Otherwise one of the neighbors handles two different zones a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone
  • 15. CAN construction: Node departure 2. Node departure b. Otherwise one of the neighbors handles two different zones a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone
  • 16. CAN construction: Node departure 1. Node departure b. Otherwise one of the neighbors handles two different zones a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone In both cases (a and b): 1. Data from departing Node is moved to the receiving Node 2. The receiving Node should update its neighbor list 3. All their neighbors are notified about changes and should update their neighbor lists
  • 17. Path latency Improvements 1 Realities: multiple coordinate spaces • Maintain multiple (R) coordinate spaces with each Node • Every Node contains different Zones in different Realities, all zones are chosen randomly • Contents of hash table replicated on every reality • Each coordinate Space is called Reality • All Realities have  The same no. of Zones  The same data  The same hash function
  • 18. Path latency Improvements 2 The extended routing Algorithm for Realities b. The request is forwarded in the best Reality a. Every Node on the path checks in which of its realities a distance to the destination is the closest one 1. The destination Zone are the same for all realities 2. Each Zone can be own by many Nodes 3. For routing is applied a basic algorithm with following extensions:
  • 19. Path latency Improvements 2 The extended routing Algorithm for Realities b. The request is forwarded in the best Reality a. Every Node on the path checks in which of its realities a distance to the destination is the closest one 1. The destination Zone are the same for all realities 2. Each Zone can be own by many Nodes 3. For routing is applied a basic algorithm with following extensions:
  • 20. Path latency Improvements 2 The extended routing Algorithm for Realities b. The request is forwarded in the best Reality a. Every Node on the path checks in which of its realities a distance to the destination is the closest one 1. The destination Zone are the same for all realities 2. Each Zone can be own by many Nodes 3. For routing is applied a basic algorithm with following extensions:
  • 21. Path latency Improvements 3 n = 1000, equal zones d Avg. path length 2 15 3 7.5 5 5 10 4.95 Multi-dimensioned Coordinates Spaces • Average path length is • the no. of dimensions d increases • the average path Length decreases )n*O(d 1/d
  • 22. Hop latency improvement RTT CAN Routing Metrics 2. New Metrics: Cartesian Distance + RTT 1. RTT is Round Trip Time (ping) • Expanded Node is the closest to the destination by Cartesian Distance • RRT between current Node and expanded Node is minimal for all optimal Nodes number of dimensions routing without RTT (ms) per hop routing with RTT (ms) per hop 2 116.8 88.3 3 116.7 76.1 4 115.8 71.2 5 115.4 70.9
  • 23. Mixed Improvement: Overloading Zones 1 Overloading coordinate zones • One Zone – many Nodes • MAXPEERS – max no. of Nodes per Zone • Every Node keeps list of its Peers • The number of neighbors stays the same (O(1) in each direction) •The general routing algorithm is used (from neighbor to neighbor)
  • 24. Mixed Improvement: Overloading Zones 2 Extended construction algorithm New node A joins the system: 1. It discovers a Zone (owner Node B) 2. B checks: how many peers does it have 3. If less than MAXPEERS 1. A is added as a new Peer 2. A gets a list of Peers and Neighbors from B 4. Otherwise 1. Zone is split in half 2. Peer list is split in half too 3. Refresh the peer and neighbor lists
  • 25. Mixed Improvement: Overloading Zones 2 Extended construction algorithm New node A joins the system: 1. It discovers a Zone (owner Node B) 2. B checks: how many peers does it have 3. If less than MAXPEERS 1. A is added as a new Peer 2. A gets a list of Peers and Neighbors from B 4. Otherwise 1. Zone is split in half 2. Peer list is split in half too 3. Refresh the peer and neighbor lists
  • 26. Mixed Improvement: Overloading Zones 2 Extended construction algorithm New node A joins the system: 1. It discovers a Zone (owner Node B) 2. B checks: how many peers does it have 3. If less than MAXPEERS 1. A is added as a new Peer 2. A gets a list of Peers and Neighbors from B 4. Otherwise 1. Zone is split in half 2. Peer list is split in half too 3. Refresh the peer and neighbor lists
  • 27. Mixed Improvement: Overloading Zones 2 Extended construction algorithm New node A joins the system: 1. It discovers a Zone (owner Node B) 2. B checks: how many peers does it have 3. If less than MAXPEERS 1. A is added as a new Peer 2. A gets a list of Peers and Neighbors from B 4. Otherwise 1. Zone is split in half 2. Peer list is split in half too 3. Refresh the peer and neighbor lists
  • 28. Mixed Improvement: Overloading Zones 2 Periodical self updating 1. Periodically, Node gets a peer list of each its neighbors 2. Node estimates a RRT to every node in peer list 3. Node chooses the closest peer Node as a New Neighbor Node in this direction
  • 29. CAN construction improvements Uniform Partitioning 1. The Node to be split compares the volume of its Zone with Zones of its Neighbors 2. The Zone with the largest volume should be split
  • 30. 30 ISSUES - Security (DoS attacks) - Parameter tuning needed to achieve scalability (Cannot vary d as n increases - n not known by any node) - CAN maintenance protocol overhead? (Cost of update operation) - Accommodation of administrative boundaries? (handling of key value pairs?) - Initial knowledge of the deterministic hash function? Ways to be changed dynamically? Implications? (total reconstruction of the CAN?) - Specification of inter-update times, caching TTL values, etc.
  • 31. Discussion - Pros • Using some of the improvement made CAN a very robust routing and storage protocol. • Using geographic location in the overlay creation would create smarter hops between close nodes. 31
  • 32. Discussion - Cons • Not much work on Load-Balancing the Keys • When all of the Extra Features are running at once, CAN becomes quite complicated. • Tough to guarantee uniform distribution of keys with hash functions on a large scale. • Query Correctness 32
  • 33. CAN - Weaknesses • Impossible to perform a fuzzy search • Susceptible to malicious activity • Maintain coherence of all the indexed data (Network overhead, Efficient distribution) • Still relatively higher routing latency • Poor performance w/o improvement
  • 34. Discussion • Addresses two key problems in the design of Content-Addressable Networks: scalable routing and indexing. • Simulation results validate the scalability of our overall design – for a CAN with over 260,000 nodes, we can route with a latency that is less than twice the IP path latency. • Future works – Secure CAN – Key word searching 34
  • 35. CAN: Summary CAN is scalable, distributed Hash Table CAN provides: • Dynamical Zone allocation • Fault Tolerance Access Algorithm • Stable Fault Tolerance Routing Algorithm There are many improve techniques which • Increase Routing Latency • Increase Data availability • Increase Fault Tolerance The scalable, distributed, efficient P2P system was designed and developed
  • 36. REFERENCES • [1] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker. A Scalable Content- Addressable Network. In ICSI Technical Report, Jan. 2001. • [2] Balasubramanian, R.; Injong Rhee; Jaewoo Kang, "A scalable architecture for SIP infrastructure using content addressable networks," Communications, 2005. ICC 2005. 2005 IEEE International Conference on , vol.2, no., pp.1314,1318 Vol. 2, 16-20 May 2005 • [3] Shidong Zhang; Bai Wang; Gengyu Wei; Chao Xin, "Web QoS Management Model Based on CAN," Computational Intelligence and Design (ISCID), 2011 Fourth International Symposium on , vol.1, no., pp.143,146, 28-30 Oct. 2011 • [4] Zhongtao Li; Weis, T., "Using zone code to manage a Content-Addressable Network for Distributed Simulations," Communication Technology (ICCT), 2012 IEEE 14th International Conference on , vol., no., pp.1350,1357, 9-11 Nov. 2012 • [5] Al-Omari, D.K.; Gurbani, V.K.; Anjali, T., "A novel architecture for a computer network defense (CND) system using Content Addressable Networks (CAN)," Globecom Workshops (GC Wkshps), 2012 IEEE , vol., no., pp.758,762, 3-7 Dec. 2012
  • 37. THANK YOU