Overview on P2P Principles Kalman Graffi DFG Research Group QuaP2P Technische Universität Darmstadt
Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks  </li></ul><ul><li...
Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks  </li></ul><ul><li...
Motivation <ul><li>A huge number of nodes participating in the network </li></ul><ul><ul><li>Having resources to share </l...
Peer-to-Peer  Properties <ul><li>Heterogeneous peers </li></ul><ul><li>Reliable? Permanent? Connectivity of individual pee...
Overlay Networks Picture adapted from Traversat, et.al  Project JXTA virtual network <ul><li>Overlay network </li></ul><ul...
Overlay Networks: Properties <ul><li>Advantages: </li></ul><ul><li>New layer fastens search/lookup of requested informatio...
Structured and Unstructured P2P Systems <ul><li>Unstructured P2P Networks </li></ul><ul><ul><li>objects have no special id...
1st Generation 2nd Generation 3rd Generation Unstructured P2P : Centralized from R.Schollmeier and J.Eberspächer, TU Münch...
<ul><li>Principle </li></ul><ul><ul><li>Central server stores information about locations </li></ul></ul>Unstructured Cent...
Unstructured Centralized P2P Systems <ul><li>Advantages </li></ul><ul><ul><li>Search complexity of O(1) –  “just ask the s...
1st Generation 2nd Generation 3rd Generation Unstructured P2P : Pure / Distributed from R.Schollmeier and J.Eberspächer, T...
Unstructured Distributed P2P Systems <ul><li>Fully Distributed Approach </li></ul><ul><ul><li>Central systems  </li></ul><...
Unstructured Distributed P2P Systems <ul><li>Characteristics </li></ul><ul><ul><li>All peers are equal (in their roles) </...
<ul><li>Principle </li></ul><ul><ul><li>No information about the objects is spread </li></ul></ul>Unstructured Distributed...
Properties of Distributed P2P Systems <ul><li>Benefits:  </li></ul><ul><ul><li>Robustness: Every peer is dispensable </li>...
1st Generation 2nd Generation 3rd Generation Unstructured Hybrid P2P Systems from R.Schollmeier and J.Eberspächer, TU Münc...
Unstructured Hybrid P2P Systems <ul><li>Combine best of both worlds: </li></ul><ul><ul><li>Robustness by distributed index...
Unstructured Hybrid P2P Systems Example: Gnutella 0.6 from R.Schollmeier and J.Eberspächer, TU München
1st Generation 2nd Generation 3rd Generation Structured DHT-based P2P Systems from R.Schollmeier and J.Eberspächer, TU Mün...
Distributed Hash Table: Steps of Operation <ul><li>Beginning:  </li></ul><ul><ul><li>Mapping nodes and data onto same addr...
<ul><ul><li>Principle: Location of the objects is found via routing </li></ul></ul><ul><ul><ul><li>   Node A (provider) a...
Chord: Network Topology <ul><li>Uses SHA-1 to map IP address/object name to 160 Bit ID </li></ul><ul><li>Basic ring topolo...
Chord: Addressing Content <ul><li>Query </li></ul><ul><ul><li>Contains the hash value of the queried content </li></ul></u...
Chord: Join Procedure <ul><li>Request to join the Chord ring </li></ul><ul><ul><ul><li>New node (e.g. 1289) contacts a mem...
Summary <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks  </li></ul><ul><li>...
Questions? <ul><li>Thank you for your attention. </li></ul><ul><li>Any questions? </li></ul>?
Content Addressable Network (CAN) <ul><li>A d-dimensional hash-table in cyclic coordinate space.  </li></ul><ul><ul><li>d ...
CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul...
Summary <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks  </li></ul><ul><li>...
Questions? <ul><li>Thank you for your attention. </li></ul><ul><li>Any questions? </li></ul>?
 
 
After this slide: slides in reserve
Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks  </li></ul><ul><li...
Requirements for Overlay Networks <ul><li>Fault-tolerance </li></ul><ul><ul><li>resilience of the connectivity when failur...
Requirements for Overlay Networks: Trade-offs <ul><li>Time – Space </li></ul><ul><ul><li>e.g. local information vs. comple...
Centralized P2P Networks <ul><li>Central index server, maintaining index: </li></ul><ul><ul><li>What: object name, file na...
Search in Centralized P2P Networks <ul><li>Search </li></ul><ul><ul><li>Peers contact central server asking for objects wh...
Step 1: Addressing in Distributed Hash Tables <ul><li>Mapping of content/nodes into linear space </li></ul><ul><ul><li>Usu...
Step 2: Association of Address Space with Nodes <ul><li>Arrangement of the range of values </li></ul><ul><ul><li>Each node...
Step 3: Locating a Data Item <ul><li>Locating the data  </li></ul><ul><ul><li>content-based routing </li></ul></ul><ul><li...
Step 4: Routing to a Data Item <ul><li>Routing to a key/value-pair </li></ul><ul><ul><li>Start lookup at arbitrary node of...
Step 5: Data Retrieval – Usage of located Resource <ul><li>Accessing the content </li></ul><ul><ul><li>Key/value-pair is d...
(Step 6) Where is the Data located? <ul><li>Association of Data with IDs </li></ul><ul><ul><li>Direct Storage </li></ul></...
Distributed Hash Table: Insert and Delete a Node <ul><li>Join of a new node </li></ul><ul><ul><li>Calculation of node ID <...
Node Failure and Node Departure <ul><li>Failure of a node </li></ul><ul><ul><li>Use of redundant key/value pairs (if a nod...
Summary of DHTs: Properties <ul><li>Hash buckets distributed over nodes </li></ul><ul><li>Nodes form an overlay network </...
Chord: Join Procedure (1) <ul><li>Request to join the Chord ring </li></ul>New Peer 1289 1. Contact a member  of the ring ...
CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul...
CAN: Routing <ul><li>2 CAN nodes are neighbors if </li></ul><ul><ul><li>their zones overlap along d-1 dimensions and  </li...
CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul...
Kademlia <ul><li>Widely deployed DHT (used in e.g. „eMule“) </li></ul><ul><li>Features </li></ul><ul><ul><li>DHT-based ove...
Kademlia: System Description <ul><li>Nodes are leaves in a binary tree </li></ul><ul><ul><li>Position is determined by sho...
Kademlia: Lookup Operation <ul><li>Every hop forwards the queries to a smaller sub-tree around the target </li></ul><ul><l...
Communication Networks II Peer-To-Peer Networking Note: many Images were taken and adapted from contribution at the book “...
Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul>...
Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul>...
Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul>...
Unstructured centralized P2P networks <ul><li>Simple strategy: </li></ul><ul><ul><li>Central server stores information abo...
Unstructured distributed P2P networks <ul><li>Fully Decentralized Approach </li></ul><ul><ul><li>No information about loca...
Upcoming SlideShare
Loading in...5
×

QuaP2P P2P Tutorial 2006

638

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
638
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Nicht standard protokoll, es ist das bekannteste in der Lehre Am einfachsten zum erklären. Kommt in freier Wildbahn aber kaum vor. Am häufigsten zitiert.
  • It has been observed by many measurement studies (e.g. Tran-Gia, Saroiu, etc.) that the rate at which peers join and leave the P2P systems is very high. This raises additional concerns, especially in cases where peers are assigned particular responsibilities and the connectivity of the overlay is not high enough to ensure that no partitioning of the system will take place. Overlay network design should not ignore the heterogeneity in node capabilities and behavior. Designing schemes that require homogenous components can either decrease the system capabilities to those achievable by the weakest components, or faulty/inefficient operation should be expected from the least capable nodes. Moreover, the observed variation in node behavior (e.g. up-time patterns) should be taken into account in the design of the overlay to increase the efficiency of the systems. Load-balance is the extent to which the load is evenly spread across nodes. The accounted load consists of the effort required for the basic overlay operations, e.g. maintenance, routing, indexing, caching, etc. Designing an overlay that avoids communication hot spots can increase the performance and the fault-tolerance of the overall system. On the other hand, by taking into account the heterogeneous environment , not all of the nodes are capable of offering the same amount of resources. A fair solution on the offered services should provide the incentives and the weighted balance between the resource contribution and the consumed overlay services. Security is the ability of a system to manage, protect and distribute sensitive information. In the context of P2P overlays security issues are basically raised by the presence of malicious peers , which do not forward or forward in the wrong direction received search requests . Additionally, selfish peers can behave in a way that could have similar results. Anonymity is the degree to which a system or component allows for (or supports) anonymous transactions. This is a special requirement for certain applications that require anti-censorship features or increase d privacy for the participating users. Of course misusage of those systems is always an issue (e.g. can be used to share illegal or inappropriate content) . (Introduce next slide) Meeting the complete set of the aforementioned requirements is not a trivial task. A number of trade-offs appear while designing P2P search services.
  • A trade-off which is common both in distributed and local search (although different techniques apply for each case) is the one between the time required to find the requested information versus the space that is required to store the information. In the case of distributed systems, the communication among peers is the most costly operation with respect to time and we will mainly consider only the number of messages exchanged and not local search operations on data structures. An example of a technique that favors time over space is the complete replication of the indexing information on every peer. No communication is required (at least for searching). An example of a technique that favors space over time is to assign every peer indexing responsibilities only for its local content. Every peer should contact every other peer to find all the information it searches (Gnutella approach). Another interesting trade-off appears between the request for security and privacy. Many security techniques require the logging of detailed information on the interactions among peers. This enables the easy tracing of peer‘s operations. On the other hand, the opposite effect appears in systems that provide anonymity on users‘ actions. More specifically for search operations, as it has already been mentioned, two main operations have been proposed: Looking for information that can be mapped in a simple key and searching for a set of results based on a more complex descripion. While the first approach can be very efficient in terms of workload and latency, the latter offers a more rich functionality. But in order to cover completely the matched items it comes at a high communication cost. In order to face the high communication cost, TTL-based solutions have been proposed to limit the network load. In that case, the overlay is not search exaustively and matching content will not be reported to the requestor. More advanced techniques can provide alternative trade-offs among these factors. P2P systems are supposed to be composed by autonomous entities. But for large scale systems this comes at a very high cost, either for search operations or the maintenance of the overlay. For this reason, alternatives have been proposed where hierarchical solutions introduced the concept of „super-peers“. Super-peers are peers with higher responsibilities that serve normal peers in certain aspects of the inter-peer collaboration. This introduces dependencies among the peers and can cause larger problems by (accidental or not) misbehavior of the super-peers. A different aspect on P2P algoritms is their reliability degree, which determines the additional operational overhead. This overhead can be required for example for the maintenance of the overlay structure that provides the degree of reliability. For example, deterministic maintenance algorithms require a very specific structure for the overlay. Althernatively, probabilistic approaches do not provide the same level of reliability, but they can provide a certain level on average at a much lower cost since they tolarate more overlay changes. (Introduce next slide) Until now we have described the environment, where the P2P search algorithms should operate, the general requirements and the introduced trade-offs. As a next step we will investigate the design dimensions of the most crucial component of a P2P system, the Overlay.
  • (This slide contains animation)
  • QuaP2P P2P Tutorial 2006

    1. 1. Overview on P2P Principles Kalman Graffi DFG Research Group QuaP2P Technische Universität Darmstadt
    2. 2. Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks </li></ul><ul><li>Unstructured P2P networks </li></ul><ul><ul><li>Centralized P2P network </li></ul></ul><ul><ul><li>Distributed P2P network </li></ul></ul><ul><li>Structured DHT-based P2P networks </li></ul><ul><ul><li>Chord </li></ul></ul><ul><ul><li>Content Addressable Network </li></ul></ul>
    3. 3. Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks </li></ul><ul><li>Unstructured P2P networks </li></ul><ul><ul><li>Centralized P2P network </li></ul></ul><ul><ul><li>Distributed P2P network </li></ul></ul><ul><li>Structured DHT-based P2P networks </li></ul><ul><ul><li>Chord </li></ul></ul>
    4. 4. Motivation <ul><li>A huge number of nodes participating in the network </li></ul><ul><ul><li>Having resources to share </li></ul></ul><ul><ul><li>With demands for resources they do not have </li></ul></ul><ul><li>Main question </li></ul><ul><ul><li>Which of the nodes keep resources I want? </li></ul></ul><ul><li>Pe er-to-Peer (P2P) as solution </li></ul><ul><ul><li>P2P offers mechanisms to find / look up what I want </li></ul></ul><ul><ul><li>Therefore: Build additional overlay network </li></ul></ul><ul><li>After finding the node providing the desired service: </li></ul><ul><ul><li>Communicate directly from peer to peer </li></ul></ul>
    5. 5. Peer-to-Peer Properties <ul><li>Heterogeneous peers </li></ul><ul><li>Reliable? Permanent? Connectivity of individual peers cannot be assumed </li></ul><ul><li>Peers offer and consume services and resources </li></ul><ul><li>Services are exchanged between any participating peers </li></ul><ul><li>Peers (=end-systems) form an overlay network </li></ul><ul><li>Peers have significant autonomy </li></ul><ul><li>Self-organizing system </li></ul>Overlay Connection Service Delivery
    6. 6. Overlay Networks Picture adapted from Traversat, et.al Project JXTA virtual network <ul><li>Overlay network </li></ul><ul><ul><li>network built ON TOP of one or more existing networks (e.g.IP network) </li></ul></ul><ul><ul><li>adds an additional layer of </li></ul></ul><ul><ul><ul><li>abstraction </li></ul></ul></ul><ul><ul><ul><li>indirection/virtualization </li></ul></ul></ul><ul><ul><li>Provide sophisticated services (search, look-up) </li></ul></ul><ul><li>Both P2P overlay and IP network </li></ul><ul><ul><li>have their own addressing scheme, provide routing functionality </li></ul></ul><ul><ul><li>are based on the end-to-end principle </li></ul></ul>TCP/IP TCP/IP TCP/IP Peers Overlay Network Underlay Networks
    7. 7. Overlay Networks: Properties <ul><li>Advantages: </li></ul><ul><li>New layer fastens search/lookup of requested information </li></ul><ul><li>Allow for bootstrapping </li></ul><ul><ul><li>Make use of existing environment adding new layer </li></ul></ul><ul><li>Not all nodes have to participate in maintaining </li></ul><ul><ul><li>But free riding is still a problem </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>Overhead </li></ul></ul><ul><ul><ul><li>Additional layer in networking stack, </li></ul></ul></ul><ul><ul><li>Complexity </li></ul></ul><ul><ul><ul><li>Layering does not eliminate complexity, it only manages it </li></ul></ul></ul><ul><ul><ul><li>Misleading behavior, unintended interaction between layers </li></ul></ul></ul><ul><ul><li>Redundancy / Features may be available at various layer </li></ul></ul><ul><li>Two types of P2P overlay networks: </li></ul><ul><ul><li>Unstructured and Structured </li></ul></ul>
    8. 8. Structured and Unstructured P2P Systems <ul><li>Unstructured P2P Networks </li></ul><ul><ul><li>objects have no special identifier </li></ul></ul><ul><ul><li>location of desired object a priori not known </li></ul></ul><ul><ul><li>each peer is only responsible for its own objects </li></ul></ul><ul><li>Search: Find all (or some) objects in the P2P network which fit to given criteria. </li></ul><ul><li>Structured P2P Networks </li></ul><ul><ul><li>peers and objects have identifiers, strict topology </li></ul></ul><ul><ul><li>objects are stored on peers according to their ID: responsibleFor(ObjID) = PeerID </li></ul></ul><ul><ul><li>distributed indexing points to object location </li></ul></ul><ul><li>Lookup / Addressing: Retrieve the object which is identified with a given identifier . </li></ul>
    9. 9. 1st Generation 2nd Generation 3rd Generation Unstructured P2P : Centralized from R.Schollmeier and J.Eberspächer, TU München DHT-Based Pure P2P Hybrid P2P Centralized P2P 1. Any terminal entity can be removed without loss of functionality 2. No central entities, fully distributed 3. “Fixed” connections in the overlay network 4.Search costs: O(log n) 5.Costs for state: O(log n) 6.For: Lookup <ul><li>Any terminal entity can be removed without loss of functionality </li></ul><ul><li>Dynamic central entities for faster search </li></ul><ul><li>3.Search costs: variable </li></ul><ul><li>4.Costs for state: variable </li></ul><ul><li>5.For: Searches </li></ul>1.Any terminal entity can be removed with- out loss of functionality 2. No central entities, fully distributed 3.Search costs: O(n) 4.Costs for state: O(1) 5.For: Searches 1.Central entity is necessary to provide the service 2.Central entity is some kind of index database 3.Search costs: O(1) 4.Costs for state: O(n) 5.For: Searches Structured P2P Unstructured P2P
    10. 10. <ul><li>Principle </li></ul><ul><ul><li>Central server stores information about locations </li></ul></ul>Unstructured Centralized P2P Systems <ul><ul><li> Node B requests item D from node A </li></ul></ul><ul><ul><li> Requester (B) asks server S for the location of D </li></ul></ul><ul><ul><li> Server S tells B that node A stores item D </li></ul></ul><ul><ul><li> Node A (provider) tells server that it stores item D </li></ul></ul>2. Send Query for desired object 3. P2P com-munication. Get Contents 1. Publish contents at own peer, tell server ?
    11. 11. Unstructured Centralized P2P Systems <ul><li>Advantages </li></ul><ul><ul><li>Search complexity of O(1) – “just ask the server” </li></ul></ul><ul><ul><li>Complex and fuzzy queries are possible </li></ul></ul><ul><ul><li>Simple, fast and finding all objects </li></ul></ul><ul><li>Problems </li></ul><ul><ul><li>No robustness: server is single point of failure (SPOF) </li></ul></ul><ul><ul><li>No self organization </li></ul></ul><ul><ul><li>No intrinsic scalability: O(N) network and system load Non-linear increasing maintenance cost </li></ul></ul><ul><ul><ul><li>in particular for achieving high availability and scalability </li></ul></ul></ul><ul><li>But overall, … </li></ul><ul><ul><li>Best principle for small and simple applications </li></ul></ul>
    12. 12. 1st Generation 2nd Generation 3rd Generation Unstructured P2P : Pure / Distributed from R.Schollmeier and J.Eberspächer, TU München DHT-Based Pure P2P Hybrid P2P Centralized P2P 1. Any terminal entity can be removed without loss of functionality 2. No central entities, fully distributed 3. “Fixed” connections in the overlay network 4.Search costs: O(log n) 5.Costs for state: O(log n) 6.For: Lookup <ul><li>Any terminal entity can be removed without loss of functionality </li></ul><ul><li>Dynamic central entities for faster search </li></ul><ul><li>3.Search costs: variable </li></ul><ul><li>4.Costs for state: variable </li></ul><ul><li>5.For: Searches </li></ul>1.Any terminal entity can be removed with- out loss of functionality 2. No central entities, fully distributed 3.Search costs: O(n) 4.Costs for state: O(1) 5.For: Searches 1.Central entity is necessary to provide the service 2.Central entity is some kind of index database 3.Search costs: O(1) 4.Costs for state: O(n) 5.For: Searches Structured P2P Unstructured P2P
    13. 13. Unstructured Distributed P2P Systems <ul><li>Fully Distributed Approach </li></ul><ul><ul><li>Central systems </li></ul></ul><ul><ul><ul><li>vulnerable, do not scale, unbalanced costs </li></ul></ul></ul><ul><ul><li>Unstructured P2P systems follow opposite approach </li></ul></ul><ul><ul><li>No global information available about location of item </li></ul></ul><ul><ul><ul><li>Information only stored at respective node providing it </li></ul></ul></ul><ul><li>Retrieval of data </li></ul><ul><ul><li>No routing information for content </li></ul></ul><ul><ul><li>Necessity to ask as many systems as possible </li></ul></ul><ul><ul><li>Approaches: </li></ul></ul><ul><ul><ul><li>Flooding: high traffic load on network, does not scale </li></ul></ul></ul><ul><ul><ul><li>Highest effort for searching </li></ul></ul></ul><ul><ul><ul><ul><li>quick search through large areas </li></ul></ul></ul></ul><ul><ul><ul><ul><li>many messages needed for unique identification </li></ul></ul></ul></ul>
    14. 14. Unstructured Distributed P2P Systems <ul><li>Characteristics </li></ul><ul><ul><li>All peers are equal (in their roles) </li></ul></ul><ul><ul><li>Search mechanism is provided by cooperation of all peers </li></ul></ul><ul><ul><li>Local view on the network </li></ul></ul>Overlay Network Service delivery <ul><li>Tasks to solve: </li></ul><ul><li>Connecting to the network </li></ul><ul><ul><li>No central index server. Joining strategies needed </li></ul></ul><ul><ul><li>To join: have to know at least 1 peer in network </li></ul></ul><ul><ul><li>Local view on network => advertisements needed </li></ul></ul><ul><li>Search </li></ul><ul><ul><li>different search strategies available </li></ul></ul><ul><ul><li>providing different benefits & drawbacks </li></ul></ul><ul><li>Service delivery </li></ul><ul><ul><li>Establish connection to other node </li></ul></ul><ul><ul><li>Peer to peer communication </li></ul></ul>
    15. 15. <ul><li>Principle </li></ul><ul><ul><li>No information about the objects is spread </li></ul></ul>Unstructured Distributed P2P Example 2. Search desired object 3. P2P com-munication. Get Contents <ul><ul><ul><li> Node C searching object floods the network </li></ul></ul></ul><ul><ul><ul><li>Node A and B send a reply </li></ul></ul></ul><ul><ul><ul><li> Node A and B (provider) store object, tell no one. </li></ul></ul></ul><ul><ul><ul><li> Node C requests the object from subset of the repliers </li></ul></ul></ul>1. Publish contents at own peer ?
    16. 16. Properties of Distributed P2P Systems <ul><li>Benefits: </li></ul><ul><ul><li>Robustness: Every peer is dispensable </li></ul></ul><ul><ul><ul><li>Switch off peer => no effect for network </li></ul></ul></ul><ul><ul><li>Balanced costs: each peer contributes the same </li></ul></ul><ul><ul><li>Self organization </li></ul></ul><ul><li>Drawbacks: </li></ul><ul><ul><li>Slow and expensive search (flood the network) </li></ul></ul><ul><ul><li>Finding all objects fitting to search criteria is not guaranteed </li></ul></ul><ul><ul><ul><li>Object out of reach for search query </li></ul></ul></ul>
    17. 17. 1st Generation 2nd Generation 3rd Generation Unstructured Hybrid P2P Systems from R.Schollmeier and J.Eberspächer, TU München DHT-Based Pure P2P Hybrid P2P Centralized P2P 1. Any terminal entity can be removed without loss of functionality 2. No central entities, fully distributed 3. “Fixed” connections in the overlay network 4.Search costs: O(log n) 5.Costs for state: O(log n) 6.For: Lookup <ul><li>Any terminal entity can be removed without loss of functionality </li></ul><ul><li>Dynamic central entities for faster search </li></ul><ul><li>3.Search costs: variable </li></ul><ul><li>4.Costs for state: variable </li></ul><ul><li>5.For: Searches </li></ul>1.Any terminal entity can be removed with- out loss of functionality 2. No central entities, fully distributed 3.Search costs: O(n) 4.Costs for state: O(1) 5.For: Searches 1.Central entity is necessary to provide the service 2.Central entity is some kind of index database 3.Search costs: O(1) 4.Costs for state: O(n) 5.For: Searches Structured P2P Unstructured P2P
    18. 18. Unstructured Hybrid P2P Systems <ul><li>Combine best of both worlds: </li></ul><ul><ul><li>Robustness by distributed indexing </li></ul></ul><ul><ul><li>Fast searches by server queries </li></ul></ul><ul><li>How it works: </li></ul><ul><ul><li>Supernodes are mini servers / super peers </li></ul></ul><ul><ul><li>Normal peers: </li></ul></ul><ul><ul><ul><li>have only overlay connections to supernodes </li></ul></ul></ul><ul><li>Use supernodes as servers for queries </li></ul><ul><ul><li>Supernodes: </li></ul></ul><ul><ul><ul><li>queries are flooded in supernodes subnetwork </li></ul></ul></ul><ul><li>Advantages: </li></ul><ul><ul><li>More robust than centralized solutions </li></ul></ul><ul><ul><li>Faster searches than in pure P2P systems </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>Need algorithms to choose reliable supernodes </li></ul></ul>
    19. 19. Unstructured Hybrid P2P Systems Example: Gnutella 0.6 from R.Schollmeier and J.Eberspächer, TU München
    20. 20. 1st Generation 2nd Generation 3rd Generation Structured DHT-based P2P Systems from R.Schollmeier and J.Eberspächer, TU München DHT-Based Pure P2P Hybrid P2P Centralized P2P 1. Any terminal entity can be removed without loss of functionality 2. No central entities, fully distributed 3. “Fixed” connections in the overlay network 4.Search costs: O(log n) 5.Costs for state: O(log n) 6.For: Lookup <ul><li>Any terminal entity can be removed without loss of functionality </li></ul><ul><li>Dynamic central entities for faster search </li></ul><ul><li>3.Search costs: variable </li></ul><ul><li>4.Costs for state: variable </li></ul><ul><li>5.For: Searches </li></ul>1.Any terminal entity can be removed with- out loss of functionality 2. No central entities, fully distributed 3.Search costs: O(n) 4.Costs for state: O(1) 5.For: Searches 1.Central entity is necessary to provide the service 2.Central entity is some kind of index database 3.Search costs: O(1) 4.Costs for state: O(n) 5.For: Searches Structured P2P Unstructured P2P
    21. 21. Distributed Hash Table: Steps of Operation <ul><li>Beginning: </li></ul><ul><ul><li>Mapping nodes and data onto same address space </li></ul></ul><ul><ul><ul><li>Peers and objects are addressed using flat IDs. </li></ul></ul></ul><ul><ul><ul><li>Nodes are responsible for data in certain parts of the address space: responsibleFor(ObjectID) = PeerID </li></ul></ul></ul><ul><ul><ul><li>Association of data to nodes may change (churn) </li></ul></ul></ul><ul><li>Later: Storing / Looking up data in the DHT </li></ul><ul><ul><li>Retrieving data = routing to the responsible node </li></ul></ul><ul><ul><ul><li>Responsible node not necessarily known in advance </li></ul></ul></ul><ul><ul><ul><li>Deterministic statement about availability of data </li></ul></ul></ul><ul><ul><ul><li>All nodes maintain routing information to other nodes </li></ul></ul></ul><ul><li>Limitations </li></ul><ul><ul><ul><li>Maintenance of routing information required </li></ul></ul></ul><ul><ul><ul><li>Load balancing problematic </li></ul></ul></ul><ul><ul><ul><li>No fuzzy search supported </li></ul></ul></ul>
    22. 22. <ul><ul><li>Principle: Location of the objects is found via routing </li></ul></ul><ul><ul><ul><li> Node A (provider) advertises object at responsible peer B. </li></ul></ul></ul>Structured Overlay Networks: Example 3. P2P com-munication. Get link to object. 2. “Routing” to / Lookup of desired Object <ul><ul><ul><li>Advertisement is routed to B. </li></ul></ul></ul><ul><ul><ul><li> Node C looking for object sends query to the network. </li></ul></ul></ul><ul><ul><ul><li>Query is routed to responsible node. </li></ul></ul></ul><ul><ul><ul><li> Node B replies to C by sending contact information of A </li></ul></ul></ul>1. Publish link at responsible Peer ?
    23. 23. Chord: Network Topology <ul><li>Uses SHA-1 to map IP address/object name to 160 Bit ID </li></ul><ul><li>Basic ring topology mod 2 n </li></ul><ul><ul><li>Successor/ Predecessor </li></ul></ul>Circular Key Space Link to ring successor 2207 2012-2207 2906 2683-2906 3485 2907-3485 2011 1623-2011 1622 1009-1622 1008 710-1008 709 660-709 659 612-659 2682 2208-2682 611 3486-4095 0-611 <ul><li>Enhanced topology </li></ul><ul><ul><li>k th finger of Peer n is shortcut pointing to peers being responsible for Object ID (n + 2 k ) </li></ul></ul><ul><ul><li>O(log(N)) fingers lead to lookup operation of O(log(N)) </li></ul></ul>Fingers poin to peers with ObjectIDs increasing ex-ponentially. Here: 709 + 2 k = …, 965, 1221, 1733, 2757 2207 2012-2207 2906 2683-2906 3485 2907-3485 2011 1623-2011 1622 1009-1622 1008 710-1008 709 660-709 659 612-659 2682 2208-2682 611 3486-4095 0-611
    24. 24. Chord: Addressing Content <ul><li>Query </li></ul><ul><ul><li>Contains the hash value of the queried content </li></ul></ul><ul><ul><li>On each step the distance from the destination is halved </li></ul></ul>Node 1008 queries item 3000 Use Fingers to locate the destination faster Without fingers: no shortcuts, walk the circle Responsible peer found 2207 2012-2207 2906 2683-2906 3485 2907-3485 2011 1623-2011 1622 1009-1622 1008 710-1008 709 660-709 659 612-659 2682 2208-2682 611 3486-… 0-611 2 Responsible for 1008 + 1024 3 1 Responsible for 2207 + 512 Responsible for 3000
    25. 25. Chord: Join Procedure <ul><li>Request to join the Chord ring </li></ul><ul><ul><ul><li>New node (e.g. 1289) contacts a member of the ring (e.g. 2906) </li></ul></ul></ul><ul><ul><ul><li>Contacted node routes the query to the responsible node (1622) </li></ul></ul></ul><ul><ul><ul><li>Responsible node (1622) contacts new node </li></ul></ul></ul>Then: 2207 2012-2207 2906 2683-2906 3485 2907-3485 2011 1623-2011 1622 1290-1622 1008 710-1008 709 660-709 659 612-659 2682 2208-2682 611 3486-… 0-611 2a. Set new predecessor 2b. Redistribute indexing information (e.g. 1009-1289) 3. Update successor of predecessor 4. Build fingers Fingers of peer n pointing to peers responsible for ObjectID n + 2 k thus, log(N) fingers are built. 1289 1009-1289 1. Set/contact successor
    26. 26. Summary <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks </li></ul><ul><li>Unstructured P2P networks </li></ul><ul><ul><li>Centralized P2P network </li></ul></ul><ul><ul><li>Distributed P2P network </li></ul></ul><ul><li>Structured DHT-based P2P networks </li></ul><ul><ul><li>Chord </li></ul></ul>
    27. 27. Questions? <ul><li>Thank you for your attention. </li></ul><ul><li>Any questions? </li></ul>?
    28. 28. Content Addressable Network (CAN) <ul><li>A d-dimensional hash-table in cyclic coordinate space. </li></ul><ul><ul><li>d hash-functions, 1 per coordinate </li></ul></ul><ul><ul><li>PeerID(p) =(h1(p),h2(p),... hd(p)) </li></ul></ul><ul><ul><li>ObjID(obj) =(h1(obj),…,hd(obj)) </li></ul></ul><ul><li>CAN nodes </li></ul><ul><ul><li>Each is responsible for a distinct rectangular zone of the space </li></ul></ul><ul><ul><li>Store data that hash into its zone </li></ul></ul><ul><ul><li>The peers cover together the entire space </li></ul></ul>1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 n2 n3 n4 n5 f1 f2 f3 f4 2-dimensional CAN <ul><li>Routing: </li></ul><ul><ul><li>A peer knows the IP addresses and zone ranges of its neighbors </li></ul></ul><ul><ul><li>Peers can communicate only with their neighbors </li></ul></ul><ul><li>Properties </li></ul><ul><ul><li>Routing table size O(d) </li></ul></ul><ul><ul><li>Guarantees that a file is found in at most d*n 1/d steps, where n is the total number of peers </li></ul></ul>n1
    29. 29. CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul><li>The node chooses randomly a point P in the space </li></ul></ul><ul><ul><li>The zone which includes P will be split in 2 halfs </li></ul></ul><ul><li>New node n6 requests to join </li></ul><ul><ul><li>Contacts a node (e.g. n5) </li></ul></ul><ul><ul><li>Selects point P </li></ul></ul><ul><ul><li>n5 routes the join query to n1 </li></ul></ul><ul><ul><li>n1 splits its zone </li></ul></ul><ul><ul><li>n6 is responsible for the new zone (at point P) </li></ul></ul>1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 n1 n2 n3 n4 n5 f1 f2 f3 f4 2-dimensional CAN Figure modified from another presentation n6 P n6
    30. 30. Summary <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks </li></ul><ul><li>Unstructured P2P networks </li></ul><ul><ul><li>Centralized P2P network </li></ul></ul><ul><ul><li>Distributed P2P network </li></ul></ul><ul><li>Structured DHT-based P2P networks </li></ul><ul><ul><li>Chord </li></ul></ul><ul><ul><li>Content Addressable Network </li></ul></ul>
    31. 31. Questions? <ul><li>Thank you for your attention. </li></ul><ul><li>Any questions? </li></ul>?
    32. 34. After this slide: slides in reserve
    33. 35. Overview <ul><li>Motivation </li></ul><ul><li>Peer-to-Peer principle </li></ul><ul><li>Overlay networks </li></ul><ul><li>Unstructured P2P networks </li></ul><ul><ul><li>Centralized P2P network </li></ul></ul><ul><ul><li>Distributed P2P network </li></ul></ul><ul><li>Structured DHT-based P2P networks </li></ul><ul><ul><li>Chord </li></ul></ul><ul><ul><li>Content Addressable Network </li></ul></ul>
    34. 36. Requirements for Overlay Networks <ul><li>Fault-tolerance </li></ul><ul><ul><li>resilience of the connectivity when failures are encountered </li></ul></ul><ul><ul><ul><li>by arbitrary leave of peers </li></ul></ul></ul><ul><li>Heterogeneity </li></ul><ul><ul><li>considering variations in physical capabilities and peer behavior (e.g. file fishing) </li></ul></ul><ul><li>Fairness </li></ul><ul><ul><li>evenly distributing workload across nodes </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>ability of a system to manage, protect and distribute sensitive information </li></ul></ul><ul><li>Privacy </li></ul><ul><ul><li>degree to which a system or component allows for (or supports) anonymous transactions </li></ul></ul>
    35. 37. Requirements for Overlay Networks: Trade-offs <ul><li>Time – Space </li></ul><ul><ul><li>e.g. local information vs. complete replication of indices </li></ul></ul><ul><li>Security – Privacy </li></ul><ul><ul><li>e.g. fully logged operations vs. totally untraceable </li></ul></ul><ul><li>Efficiency – Completeness </li></ul><ul><ul><li>e.g. exact key-based matching vs. partial matching (use of wildcards) </li></ul></ul><ul><li>Scope – Network load </li></ul><ul><ul><li>with TTL (time to live) </li></ul></ul><ul><ul><li>e.g. TTL based requests vs. exhaustive search </li></ul></ul><ul><li>Efficiency – Autonomy </li></ul><ul><ul><li>e.g. hierarchical vs. pure P2P overlays </li></ul></ul><ul><li>Reliability – Low maintenance overhead </li></ul><ul><ul><li>e.g. deterministic vs. probabilistic operations </li></ul></ul>
    36. 38. Centralized P2P Networks <ul><li>Central index server, maintaining index: </li></ul><ul><ul><li>What: object name, file name, criteria (ID3) … </li></ul></ul><ul><ul><li>Where (IP address, Port) </li></ul></ul><ul><ul><li>Search engine, combining both information </li></ul></ul><ul><ul><li>Global view on the network </li></ul></ul><ul><li>Normal peer, maintaining the objects: </li></ul><ul><ul><li>Each peer maintains only its own objects </li></ul></ul><ul><ul><li>decentralized storage (content at the edges) </li></ul></ul><ul><ul><li>file transfer between clients (decentralized) </li></ul></ul><ul><li>Issues: </li></ul><ul><ul><li>Unbalanced costs: central server is bottleneck </li></ul></ul><ul><ul><li>Security: server is single point of failure </li></ul></ul>Central Server Overlay Network
    37. 39. Search in Centralized P2P Networks <ul><li>Search </li></ul><ul><ul><li>Peers contact central server asking for objects which fulfill some criteria </li></ul></ul><ul><ul><li>Central server answers with list of addresses of peers that contain objects with these criteria </li></ul></ul><ul><ul><li>Peer contacts peers containing desired objects </li></ul></ul><ul><ul><li>Transferring object / providing service P2P </li></ul></ul>Central Server 3,4: Service Delivery P2P 1: Query server 2: Server answers
    38. 40. Step 1: Addressing in Distributed Hash Tables <ul><li>Mapping of content/nodes into linear space </li></ul><ul><ul><li>Usually: 0, …, 2 m -1 >> number of objects to be stored </li></ul></ul><ul><ul><li>Mapping of data and nodes into an address space (e.g.0 to 2 m -1) </li></ul></ul><ul><ul><ul><li>(with hash function) </li></ul></ul></ul><ul><ul><ul><li>E.g., Hash( String ) mod 2 m : H(„ my data “)  2313 </li></ul></ul></ul><ul><ul><li>Association of parts of address space to DHT nodes </li></ul></ul>The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. By Steinmetz, Wehrle H(Node Y)=3485 3485 - 610 1622 - 2010 611 - 709 2011 - 2206 2207- 2905 (3485 - 610) 2906 - 3484 1008 - 1621 Y X 2 m -1 0 Often, the address space is viewed as a circle. Data item “D”: H(“D”)=3107 H(Node X)=2906
    39. 41. Step 2: Association of Address Space with Nodes <ul><li>Arrangement of the range of values </li></ul><ul><ul><li>Each node is responsible for part of the value range </li></ul></ul><ul><ul><ul><li>Often with redundancy (overlapping of parts) </li></ul></ul></ul><ul><ul><ul><li>Continuous adaptation </li></ul></ul></ul><ul><ul><li>Real (underlay) and logical (overlay) topology are (mostly) uncorrelated </li></ul></ul>The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. By Steinmetz, Wehrle Node 3485 is responsible for data items in range 2907 to 3485 (in case of a Chord-DHT) Logical view of the Distributed Hash Table Mapping on the real topology 2207 2906 3485 2011 1622 1008 709 611
    40. 42. Step 3: Locating a Data Item <ul><li>Locating the data </li></ul><ul><ul><li>content-based routing </li></ul></ul><ul><li>Goal: Small and scalable effort </li></ul><ul><ul><li>O(1) with centralized hash table </li></ul></ul><ul><ul><ul><li>But: Management of a centralized hash table too costly (server) </li></ul></ul></ul><ul><ul><li>Minimum overhead with distributed hash tables </li></ul></ul><ul><ul><ul><li>O(log N): </li></ul></ul></ul><ul><ul><ul><ul><li>DHT hops to locate object </li></ul></ul></ul></ul><ul><ul><ul><li>O(log N): </li></ul></ul></ul><ul><ul><ul><ul><li>number of keys and routing information per node (N = # nodes) </li></ul></ul></ul></ul>The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. By Steinmetz, Wehrle
    41. 43. Step 4: Routing to a Data Item <ul><li>Routing to a key/value-pair </li></ul><ul><ul><li>Start lookup at arbitrary node of DHT </li></ul></ul><ul><ul><li>Routing to requested data item (key) </li></ul></ul>( 3107, (ip, port) ) Value = pointer to location of data Key = H(“ my data ”) Node 3485 manages keys 2907-3485, Initial node (arbitrary) H(„ my data “) = 3107 2207 2906 3485 2011 1622 1008 709 611 ? The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. By Steinmetz, Wehrle
    42. 44. Step 5: Data Retrieval – Usage of located Resource <ul><li>Accessing the content </li></ul><ul><ul><li>Key/value-pair is delivered to requester </li></ul></ul><ul><ul><li>Requester analyzes key/Value-tuple (and downloads data from actual location – in case of indirect storage) </li></ul></ul>H(„ my data “) = 3107 2207 2906 3485 2011 1622 1008 709 611 ? Get_Data(ip, port) Node 3485 sends (3107, (ip/port)) to requester In case of indirect storage: After knowing the actual Location, data is requested The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. By Steinmetz, Wehrle
    43. 45. (Step 6) Where is the Data located? <ul><li>Association of Data with IDs </li></ul><ul><ul><li>Direct Storage </li></ul></ul><ul><ul><li>Indirect Storage </li></ul></ul>D D 134.2.11.68 2207 2906 3485 2011 1622 1008 709 611 H SHA-1 („D“)=3107 D 2207 2906 3485 2011 1622 1008 709 611 H SHA-1 („D“)=3107 Item D: 134.2.11.68 D 134.2.11.68
    44. 46. Distributed Hash Table: Insert and Delete a Node <ul><li>Join of a new node </li></ul><ul><ul><li>Calculation of node ID </li></ul></ul><ul><ul><li>New node contacts DHT via arbitrary node </li></ul></ul><ul><ul><li>Assignment of a particular hash range </li></ul></ul><ul><ul><li>Copying of key/value-pairs of hash rang (usually with redundancy) </li></ul></ul><ul><ul><li>Binding into routing environment </li></ul></ul>2207 2906 3485 2011 1622 1008 709 611 ID: 3485 134.2.11.68    The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, edt. By Steinmetz, Wehrle
    45. 47. Node Failure and Node Departure <ul><li>Failure of a node </li></ul><ul><ul><li>Use of redundant key/value pairs (if a node fails) </li></ul></ul><ul><ul><li>Use of redundant / alternative routing paths </li></ul></ul><ul><ul><li>Key-value usually still retrievable if at least one copy remains </li></ul></ul><ul><li>Departure of a node </li></ul><ul><ul><li>Partitioning of hash range to neighbor nodes </li></ul></ul><ul><ul><li>Copying of key/value pairs to corresponding nodes </li></ul></ul><ul><ul><li>Unbinding from routing environment </li></ul></ul>The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, edt. By Steinmetz, Wehrle
    46. 48. Summary of DHTs: Properties <ul><li>Hash buckets distributed over nodes </li></ul><ul><li>Nodes form an overlay network </li></ul><ul><ul><li>Route messages in overlay to find responsible node </li></ul></ul><ul><li>Routing scheme in the overlay network is the difference between different DHTs </li></ul><ul><li>DHT behavior and usage: </li></ul><ul><ul><li>Node knows “object” name and wants to find it </li></ul></ul><ul><li>Unique and known object names assumed </li></ul><ul><ul><li>Node routes a message in overlay to the responsible node </li></ul></ul><ul><ul><li>Responsible node replies with “object” </li></ul></ul><ul><li>Semantics of “object” are application defined </li></ul>3.6
    47. 49. Chord: Join Procedure (1) <ul><li>Request to join the Chord ring </li></ul>New Peer 1289 1. Contact a member of the ring 2. Route the query in the ring 3. Provide new peer’s successor 2207 2012-2207 2906 2683-2906 3485 2907-3485 2011 1623-2011 1622 1009-1622 1008 710-1008 709 660-709 659 612-659 2682 2208-2682 611 3486-… 0-611
    48. 50. CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul><li>The node chooses randomly a point P in the space </li></ul></ul><ul><ul><li>The zone which includes P will be split in 2 halfs </li></ul></ul><ul><li>Example: Node n6 requests to Join </li></ul><ul><ul><li>Contacts n4 </li></ul></ul><ul><ul><li>Selects point P </li></ul></ul><ul><ul><li>n4 routes the Join query to n1 </li></ul></ul><ul><ul><li>n1 splits its zone </li></ul></ul><ul><ul><li>n6 is responsible for the new zone (at point P) </li></ul></ul>P n6 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 n1 n2 n3 n4 n5 f1 f2 f3 f4
    49. 51. CAN: Routing <ul><li>2 CAN nodes are neighbors if </li></ul><ul><ul><li>their zones overlap along d-1 dimensions and </li></ul></ul><ul><ul><li>abut along one dimension </li></ul></ul><ul><li>I.e. </li></ul><ul><ul><li>A node knows the IP addresses of its neighbors </li></ul></ul><ul><ul><li>A node knows the coordinates of neighboring zones </li></ul></ul><ul><ul><li>Nodes can communicate only with their neighbors </li></ul></ul><ul><li>Properties </li></ul><ul><ul><li>Routing table size O(d) </li></ul></ul><ul><ul><li>Guarantees that a file is found in at most d*n 1/d steps, where n is the total number of nodes </li></ul></ul>1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 n1 n2 n3 n4 n5 f2 f4 f3 f6 <ul><li>Lookup example: </li></ul><ul><li>Node n5 is looking for file f3 </li></ul>Abut = direkt angrenzen f5 f1
    50. 52. CAN: New Peer Join <ul><li>New node has to acquire a zone to be responsible for </li></ul><ul><li>Steps: </li></ul><ul><ul><li>The node chooses randomly a point P in the space </li></ul></ul><ul><ul><li>The zone which includes P will be split in 2 halfs </li></ul></ul><ul><li>Example: Node n6 requests to Join </li></ul><ul><ul><li>Contacts n4 </li></ul></ul><ul><ul><li>Selects point P </li></ul></ul><ul><ul><li>n4 routes the Join query to n1 </li></ul></ul><ul><ul><li>n1 splits its zone </li></ul></ul><ul><ul><li>n6 is responsible for the new zone (at point P) </li></ul></ul>P n6 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 n1 n2 n3 n4 n5 f1 f2 f3 f4
    51. 53. Kademlia <ul><li>Widely deployed DHT (used in e.g. „eMule“) </li></ul><ul><li>Features </li></ul><ul><ul><li>DHT-based overlay network using the XOR metric </li></ul></ul><ul><ul><ul><li>E.g. D( 1 10 1 01, 0 10 0 01) = 4 + 32 = 36 </li></ul></ul></ul><ul><ul><ul><li>Simple operation </li></ul></ul></ul><ul><ul><ul><li>Symmetrical (A->B == B->A) </li></ul></ul></ul><ul><ul><li>Use lookup messages to maintain the overlay network </li></ul></ul><ul><ul><ul><li>(Cannot be applied to asymmetrical Chord) </li></ul></ul></ul><ul><ul><li>Multiple routing possibilities </li></ul></ul><ul><ul><li>Parallel asynchronous queries </li></ul></ul><ul><ul><ul><li>Overcome faulty nodes </li></ul></ul></ul><ul><li>Properties </li></ul><ul><ul><li>Scalable </li></ul></ul><ul><ul><ul><li>Logarithmic complexity in node degree (O(log(N))) and lookup steps (O(log(N))) </li></ul></ul></ul><ul><ul><li>Efficient </li></ul></ul><ul><ul><ul><li>Low maintenance cost </li></ul></ul></ul><ul><ul><li>Robust </li></ul></ul>3.9
    52. 54. Kademlia: System Description <ul><li>Nodes are leaves in a binary tree </li></ul><ul><ul><li>Position is determined by shortest unique prefix of node ID </li></ul></ul><ul><li>For every node (e.g. node „001“) </li></ul><ul><ul><li>Divide the binary tree into a series of successively lower sub-trees that do not contain that node </li></ul></ul><ul><ul><li>At least one contact node is required in each sub-tree </li></ul></ul><ul><ul><ul><li>Large sub-trees provide many neighbor alternatives </li></ul></ul></ul>
    53. 55. Kademlia: Lookup Operation <ul><li>Every hop forwards the queries to a smaller sub-tree around the target </li></ul><ul><li>Example: Node „001“ routes to “101” </li></ul><ul><ul><li>Node „001“ needs a contact in 1-(*) sub-tree (e.g. „110“) </li></ul></ul><ul><ul><li>Node „110“ needs a contact in 10-(*) sub-tree (e.g. „100“ </li></ul></ul><ul><ul><li>Node „100“ forwards the query to destination „101“ </li></ul></ul>1 2 3
    54. 56. Communication Networks II Peer-To-Peer Networking Note: many Images were taken and adapted from contribution at the book “P2P Systems and Applications” Ed. Steinmetz, Wehrle H(„ my data “) = 3107 2207 7.31.10.25 peer-to-peer.info 12.5.7.31 95.7.6.10 86.8.10.18 planet-lab.org berkeley.edu 2906 3485 2011 1622 1008 709 611 61.51.166.150 ?
    55. 57. Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul><ul><li>objects are stored on peers according to their ID </li></ul></ul><ul><ul><li>distributed indexing points to object location </li></ul></ul><ul><li>Lookup / Addressing: Retrieve the object which is identified with a given identifier . </li></ul>3. P2P com-munication. Get Contents 2. “Routing” to / Lookup of desired Object 1. Publish contents at responsible Peer
    56. 58. Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul><ul><li>objects are stored on peers according to their ID </li></ul></ul><ul><ul><li>distributed indexing points to object location </li></ul></ul><ul><li>Lookup / Addressing: Retrieve the object which is identified with a given identifier . </li></ul>3. P2P com-munication. Get Contents 2. “Routing” to / Lookup of desired Object 1. Publish contents at responsible Peer
    57. 59. Structured Overlay Networks <ul><li>Principle </li></ul><ul><ul><li>peers and objects have identifiers </li></ul></ul><ul><ul><li>objects are stored on peers according to their ID </li></ul></ul><ul><ul><li>distributed indexing points to object location </li></ul></ul><ul><li>Lookup / Addressing: Retrieve the object which is identified with a given identifier . </li></ul>
    58. 60. Unstructured centralized P2P networks <ul><li>Simple strategy: </li></ul><ul><ul><li>Central server stores information about locations </li></ul></ul><ul><ul><ul><li> Node A (provider) tells server that it stores item D </li></ul></ul></ul><ul><ul><ul><li> Node B (requester) asks server S for the location of D </li></ul></ul></ul><ul><ul><ul><li> Server S tells B that node A stores item D </li></ul></ul></ul><ul><ul><ul><li> Node B requests item D from node A </li></ul></ul></ul>Node A Server S “ A stores D ” Node B The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, edt. By Steinmetz, Wehrle Transmission: D  Node B  “ Where is D ?”  “ A stores D ”  “ A stores D ” 
    59. 61. Unstructured distributed P2P networks <ul><li>Fully Decentralized Approach </li></ul><ul><ul><li>No information about location of data at intermediate systems </li></ul></ul><ul><ul><li>Necessity for broad search </li></ul></ul><ul><ul><ul><li> Node B (requester) asks neighboring nodes for item D </li></ul></ul></ul><ul><ul><ul><li> -  Nodes forward request to further nodes (breadth-first search / flooding) </li></ul></ul></ul><ul><ul><ul><li> Node A (provider of item D) sends D to requesting node B </li></ul></ul></ul>The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, edt. By Steinmetz, Wehrle & Transmission: D  Node B “ I have D ?”  “ B searches D ” Node A Node B “ I store D ”              

    ×