Saarland University Faculty of Natural Sciences and Technology I Department of Computer Science. Masters Thesis

Size: px
Start display at page:

Download "Saarland University Faculty of Natural Sciences and Technology I Department of Computer Science. Masters Thesis"

Transcription

1 Saarland University Faculty of Natural Sciences and Technology I Department of Computer Science Masters Thesis Experimental Comparison of Byzantine Fault Tolerant Distributed Hash Tables submitted by Supriti Singh submitted Supervisor: Dr. Christian Grothof Advisors: Bartlomiej Polot Sree Harsha Totakura Reviewers: Dr. Christian Grothof Prof. Dr. Sebastian Hack

2 Acknowledgements I am fortunate to have received support from so many people in accomplishing this thesis. I take this chance to express my gratitude. I express deepest regards and respect to my thesis supervisor, Dr. Christian Grothoff for providing me this opportunity to work on this topic. I would also like to thank my thesis advisor Prof. Sebastian Hack, Saarland University. Many thanks to my advisors, Bartlomiej Polot and Sree Harsha Totakura. Bart helped me in understanding the existing DHT, R 5 N architecture. Harsha helped me with the experimental setup and explanation of GNUnet testbed. I would also like to thank my family and friends who were a constant support throughout. i

3 Abstract Masters Thesis Experimental Comparison of Byzantine Fault Tolerant Distributed Hash Tables by Supriti Singh Distributed Hash Tables (DHTs) are a key data structure for construction of a peer to peer systems. They provide an efficient way to distribute the storage and retrieval of key-data pairs among the participating peers. DHTs should be scalable, robust against churn and resilient to attacks. X-Vine is a DHT protocol which offers security against Sybil attacks. All communication among peers is performed over social network links, with the presumption that a friend can be trusted. This trust can be extended to a friend of a friend. It uses the tested Chord Ring topology as an overlay, which has been proven to be scalable and robust. The aim of the thesis is to experimentally compare two DHTs, R 5 N and X-Vine. GNUnet is a free software secure peer to peer framework, which uses R 5 N. In this thesis, we have presented the implementation of X-Vine on GNUnet, and compared the performance of R 5 N and X-Vine.

4 Contents Acknowledgements i Abstract ii List of Figures List of Tables vi vii 1 Introduction Distributed Hash Table General DHT architecture DHT Properties Byzantine Failures and Defenses in DHT Motivation X-Vine Chord Key and Peer mapping Finger Table Concurrent Node Joins and Stabilization Node failures Performance X-Vine Architecture Adversary Model X-Vine Trust Model Intuition Friends and Overlay Endpoints/Fingers Byzantine Fault tolerance Global Policies Local Policies Redundant Routing R 5 N DHT Key Features Design Kademlia R 5 N Design iii

5 Contents iv Routing PUT/GET Security X-Vine and R 5 N X-Vine GNUnet Implementation GNUnet GNUnet DHT System Key and Peer Identifier Space Global Data Structures X-Vine Client-Service Protocol PUTing data into DHT GETing data from DHT X-Vine Peer to Peer Protocol Overlay Ring Topology Setup Search space Trail Setup Algorithm Overlay Ring Topology Maintenance Looking for Successor Verify Successor Verify Successor Result Notify Successor Notify Successor Confirmation Storage and lookup of key-data pair Handling PUT request Handling GET request Security Protocol Experimental Setup Comparison Parameters DHT Profiler Results and Analysis Scale Free Topology Analysis D Torus Analysis Related Work Whanau Whanau Design Performance Persea Design Performance Conclusion and Future Work Future Work

6 Contents v Experiments Implementation Bibliography 34

7 List of Figures 2.1 Chord Finger table Social network Social network and its corresponding overlay network, Trail GNUnet Architecure DHT Architecure Trail Setup example Persea vi

8 List of Tables 6.1 Average PUT and GET path length in Scale Free for different network sizes Control and Data traffic in Scale Free topology for different network size Total number of PUTs and Successful GETs Average PUT and GET path length in 2D Torus topology for different network sizes Control and Data traffic (in MB) in 2D Torus topology for different network sizes vii

9 Chapter 1 Introduction 1.1 Distributed Hash Table A Distributed Hash Table (DHT) is a decentralized storage structure for a peer to peer (P2P) system. It provides storage and lookup of key-data pair similar to a hash table. Each data to be stored in DHT is associated with a key. The key-data pair is stored at a particular peer to which the key maps. DHTs offer simple APIs, PUT and GET to store and retrieve the data from the P2P system. 1.2 General DHT architecture A typical DHT consists of a storage layer on top of a lookup protocol [1]. A lookup protocol ensures that peers connect in an overlay topology such that they are reachable to each other. It also ensures that peers decide on some mapping to store key/data pair at the correct destination peer. Storage layer provides a way to store and retrieve the data from the DHT. Lookup protocol of a typical DHT has the following components. 1. A peer identifier space. 2. A key identifier space. 3. A rule to map keys to peers. 4. Per-peer routing tables, which stores information to reach to other peers. 5. Rules to update routing table in case of peer joining, leaving or failing. The storage layer provides APIs, PUT and GET to access the data from the DHT. Storage layer can also provide features like replication and data authentication. 1

10 Chapter 1. Introduction DHT Properties A DHT should have following features. 1. Load balancing Distribution of keys among the participating peers should be balanced. In case there is a skewed distribution, few peers store large amount of data. If such peer becomes unavailable due to churn, network will be destabilized. Also, in case this peer is malicious, it has access to large amount of information which is undesirable. Hence, DHT should use a mapping function which equally distributes key among the participating peers. 2. Scalability A DHT should be able to scale and operate under arbitrary changes in the network size. To handle it, lookup protocol should be able to update routing table of nodes in accordance to the changes. 3. Fault tolerance A DHT should be able to operate even with nodes continuously leaving, failing or with malicious participants. There can be multiple kinds of malicious behaviors and resulting failures. They are discussed in Section 1.4 along with the general defense techniques. 1.4 Byzantine Failures and Defenses in DHT In a P2P systems with byzantine failures, participating peers fail in arbitrary ways. A non byzantine fault tolerant system responds in an unpredictable way in event of a byzantine failure. In a DHT, participating peers can be either malicious or honest. Even if peers are not malicious, they may crash or fail to send and receive messages from the other peers. This failure can result in loss of data. DHT uses replication in order to provide service even in case of such failures. In case there are malicious peers, following attacks are possible on DHT [1]. 1. Attack on lookup protocol. Lookup protocol ensures that each peer maintains a routing table with information to reach to other peers in network. It also ensures that routing table are updated in case of nodes leaving and joining the system. An adversary can be part of routing tables of honest nodes. It can intercept all its queries or drop the packets. It can route lookup request to a non-existent or to an incorrect node. As the malicious peer participates in routing table maintenance, it will appear as alive to all other peers. Hence, a retransmission of the lookup request will again go through the same malicious peer. One possible defense again such attack would be that querying peer tries to reach to the destination peer through different routes, instead of one fixed route. This approach will increase the chances of taking a route with no malicious peers.

11 Chapter 1. Introduction 3 2. Storage and retrieval attack An adversary can store data, but can deny access to data. Similarly, it can claim to be responsible for a data, but refuses to serve the client. DHTs use replication in order to avoid such single point of responsibility. Also, clients of DHTs are expected to contact all the peers that hold replicas. 3. Overload a specific peer with data. An adversary can attack a particular peer in the network, by generating lot of data and storing it at the target peer. Eventually, the target peer will get over-loaded and the system will treat the affected peer as failed and will run stabilization algorithm to handle it. This attack is a typical Denial of Service attack. To overcome such attacks, DHT should use replication. Even if a peer is unreachable, the other replicas should be accessible. But if malicious peer is one of the replicas or it colludes with other replicas, the attack may be succeed. Also, DHT should do node assignment in a random way that does not adhere to actual physical topology. Replicas should be placed at different physical location. This would prevent a localized attack from preventing access to a specific key. 4. Unsolicited messages Consider a scenario where Alice asks for reply from Bob. The path between them goes through Chuck. Chuck can send back an unsolicited reply. Peer Authentication can be used to avoid such forgery attacks. 5. Rapid peer join and leave Every DHT runs stabilization algorithm to handle peer churn. Key-data pair is transferred to the correct peer so that the lookup returns a valid result. A malicious node might try to convince the system that some new peer has joined or left the system. This can result in control traffic, leading to reduced efficiency and poor performance of the system. This attack would work best if attacker can avoid being a part of the data transfer. But in an adversary model, where malicious peer has limited resources, it is not possible. The DHT should be able to provide data transfer in a way that does not result in network overload. 1.5 Motivation This thesis aims to experimentally compare two byzantine fault tolerant DHTs, R 5 N and X-Vine. X-Vine and R 5 N uses different approaches to mitigate security attacks. While R 5 N uses randomized paths for lookup, X-Vine follows the social network trail. R 5 N is currently used in GNUnet. GNUnet is a secure open source peer to peer framework. In order to compare X-Vine and R 5 N, X-Vine has been implemented in GNUnet. Performance comparison is done on various parameters, such as PUT/GET success rate, network traffic generated and average number of hops for PUT/GET.

12 Chapter 2 X-Vine X-Vine is a social network based Byzantine fault tolerant Distributed Hash Table (DHT). It uses social network links for all the communication among the peers. It uses Chord DHT as its base protocol. This chapter explains the basic architecture of X-Vine. Section 2.1 discusses Chord, the base DHT protocol of X-Vine. Section 2.2 explains how X-Vine builds upon Chord, and discusses its byzantine fault tolerant features. 2.1 Chord Chord [2] is a basic DHT protocol, that has been proven to be robust and scalable. However, it is not secure against attacks [3] Key and Peer mapping Chord uses consistent hashing to assign keys to peers. Consistent Hashing uses a base hash function such as SHA-1 to assign m-bit identifiers to peers and keys. m should be large enough such that probability of two different peers having the same identifier is negligible. Consistent hash function balances the load among all the participating peers with high probability. In a Chord DHT with n peers, each peer is responsible for only K/n keys, where K is the total number of keys. All the peers in Chord are ordered in an identifier circle modulo 2 m, where m = number of bits in the identifier space. Key, k is assigned to a peer, successor(k) such that peer s identifier is either equal to or follows k in the identifier space. Figure 2.1 shows an identifier circle with m = 3. The network can have at most 8 peers. Peer 0, 3 and 5 are present in the network. Successor of identifier 3 is peer 3. Successor of identifier 4 is peer 5 and successor of identifer 6 is peer 0. 4

13 Chapter 2. X-Vine 5 Figure 2.1: Peers and their successor nodes Finger Table In Chord, each peer maintains pointer to its immediate successor in the network. A naive way to do lookup in the network will be to follow these successor pointers. But this scheme requires O(n) messages. To do lookup more efficiently, each peer maintains a set of fingers in the network that are spaced exponentially away from it. These fingers are stored in a finger table. A peer maintains at most m finger entries, where m is number of bits in the identifier space. The i th finger of node n is the first node, s, that succeeds n by atleast 2 i 1, where 1 <= i <= m. Figure 2.2 shows the finger tables of peers 0, 3 and Concurrent Node Joins and Stabilization In a peer-to-peer systems, peers can arbitrarily join, leave or fail. In such events, Chord tries to maintain the following invariants: Each peer s successor is correctly maintained. Each key, k is stored at peer, successor(k) As an example, consider a new node, n p joining the system. It contacts its immediate successor, n s in the network. Each peer should also maintain a pointer to its immediate predecessor. Hence, n s adds n p as its predecessor. Another new node, n joins the system, such that, n p < n < n s. The new node, n and n s add each other as their successor and predecessor respectively. Node, n p inquires n s about its current predecessor. Eventually n p will add n as its successor. Each peer also periodically verifies its existing fingers. In case there are changes in the network, the finger table will be updated.

14 Chapter 2. X-Vine 6 Figure 2.2: Finger table Node failures In case of node failures, Chord tries to maintain the following invariant: When a node, n fails, then all the peers which used n as its finger, must update their finger tables. They should replace n with its successor. Failure of a peer must not disrupt the queries which are in progress. In order to keep successor pointers correct in case of node failures, each Chord peer maintains a list of consecutive r successors. In case one of the successors fails, then the next live successor is selected Performance In an n-peer system, each peer in Chord maintains information about O(log n) other peers. Data lookup requires O(log n) messages. In case of peers leaving or joining the network, O(log n 2 ) messages are exchanged to stabilize the network.

15 Chapter 2. X-Vine X-Vine Architecture This section describes X-Vine protocol. Section explain the malicious behavior for which X-Vine provides protection. Section explains the intuition for using social network links for security. Section explains routing algorithm of X-Vine. Section gives a detailed explanation of X-Vine security protocol [4] Adversary Model X-Vine assumes that a set of peers are colluding and compromised. The malicious peers are byzantine in nature. X-Vine focuses in particular on Sybil attacks. In Sybil attacks, a single entity creates multiple identities. This entity is referred as Sybil node. It uses these identities to gain disproportionately large influence and launch attacks as explained in Section X-Vine Trust Model As seen in section 1.4, a peer-to-peer system is prone to security attack due to presence of malicious nodes in the system. X-Vine is a social network based DHT. It works on assumption that a friend peer is unlikely to be selfish or malicious. The same trust can be extended to friend of a friend. Hence, to avoid mis-routing of messages, routing is done through a trail of friend peers [5] Intuition Figure 2.3 shows a social network with set of honest and Sybil nodes. An edge between honest and Sybil sub graph is referred as an attack edge. An honest node adds other honest nodes as its friends. Sybil nodes can also setup trust relation with honest nodes. Honest and Sybil areas of network can not be differentiated. Previous work [6][7] have shown that it is costly for an adversary to set up a large number of trust links. Hence, the number of edges within an individual region will always be greater than the attack edges. Sybil nodes tries to disrupt the network by mis-routing. Consider an honest node, Alice which wants to contact another honest node, Bob. Alice does not have a direct path to reach to Bob, but she can contact Bob through a series of friends. Alice have three friends, Chuck, Dan and Dave. Chuck is a Sybil node. But, Alice can not distinguish between its real friends and adversary. If Alice tries to reach to Bob only through Chuck, then Bob will never receive the message. In order to avoid such a situation, Alice will try to contact Bob through its other two friends. As attack edges are limited, Alice will eventually reach to Bob [8].

16 Chapter 2. X-Vine 8 Figure 2.3: Social network Friends and Overlay Endpoints/Fingers X-Vine builds an overlay network over the social network underlay topology. In this overlay network, a node has direct connection to its friend. A node also maintains overlay links to its overlay endpoints. These overlay endpoints are selected in manner similar to fingers in Chord. Figure 2.4 shows a social network and its corresponding X-Vine overlay network. Similar to Chord, X-Vine do PUT and GET at the key s successor node. However, nodes in X-Vine can not directly communicate with its overlay endpoints. All the communication must use social network links. Hence, a node needs to setup a trail through social network to reach to its overlay endpoints. All the nodes which are part of this trail should store an entry in their routing table. Figure 2.5 shows a trail from a peer, 0 to its overlay endpoint, 4. The trail goes from and each peer stores an entry in its routing table Byzantine Fault tolerance In order to limit Sybil attacks on both routing table maintenance and lookup protocol, X-Vine provides a set of local and global policies. These policies ensures that no node accumulates a large state.

17 Chapter 2. X-Vine 9 (a) Underlay topology (b) Chord ring overlay topology. Dotted lines shows Peer 0 s fingers. Figure 2.4: Social network and its corresponding overlay network, Figure 2.5: Trail from 0 to its finger, 4 through the overlay network. Peer 3 and 1 store an entry in their respective routing tables.

18 Chapter 2. X-Vine Global Policies A joining node needs to setup trails to its overlay endpoints in the network. But as the new node has no routing state, it uses one of its existing friend in the network as a bootstrap node. Thus, an earlier joined node will be part of significantly more trails. To avoid such accumulation of state at few nodes, X-Vine defines the following policies: 1. Threshold on trail length. X-Vine defines a global threshold thr 1 on trail length. When a new node joins the network, an existing node scans all the trail that might have crossed thr 1. It contacts the existing social contacts of new node to find a shorter alternative trails. 2. Threshold on routing table size. X-Vine defines a global threshold thr 2 on routing table size. This threshold limits the number of trails of which a peer can be part of. Thus, it avoids a single peer to accumulate large state. A peer whose routing table size has crossed, thr 2 scans its routing table for the trails such that their length has crossed thr 1. It contacts the overlay endpoints of all the such trail to check if an alternate shorter trail can be established Local Policies In order to account for heterogeneity of the participating peers, X-Vine allows individual peers to make local decision regarding their participation in routing and lookup. Based on its available resources, a peer decides the following thresholds. 1. Bounding routes per friend link. A peer can setup a threshold, b l to limit the number of trails that should be setup through an adjacent social link. X-Vine assumes that there are limited number of attack edges. Hence, b l bounds the number of overlay path between Sybil subgraph and honest subgraph, irrespective of adversary s attack strategy. 2. Bounding routes per node. A peer can setup a threshold, b n on its own routing table size. If there are maximum b n trails already stored in a peer s routing table, it can deny to be part of any more trails. By limiting its own routing size, a peer can avoid clustering attack Redundant Routing An adversary can drop or route PUT/GET requests to a non existent or a wrong node. To limit such attacks, X-Vine does lookups over r different trusted trails (redundant routes). If at least one of the route consists of only honest nodes, the lookup will succeed.

19 Chapter 3 R 5 N DHT R 5 N stands for Randomized Recursive Routing for Restricted-Route Networks [9]. It is a secure DHT that uses randomized routes for secure lookup and routing. Section 3.1 lists down the main features of R 5 N DHT. Section 3.2 explains R 5 N lookup and routing protocol. It also discusses its security protocol. Section 3.3 gives a brief comparison of X-Vine and R 5 N architecture. 3.1 Key Features R 5 N design has the following key features: 1. Restricted Route Underlay Topology Restricted route topology refers to an underlay network infrastructure where not every peer can directly communicate with other peers. For example, in a friend to friend network a peer can setup direct connections only with the set of peers that it already knows as friends. But, most of the DHTs assume a universal connectivity among the participating peers. This assumption results in limited participation. R 5 N routing algorithm works efficiently even in a restricted route underlay topology. 2. Recursive Kademlia R 5 N uses a recursive version of Kademlia DHT [10]. Section explains Kademlia s routing tables and iterative routing. In recursive routing, the initiator peer forwards the lookup/routing request to another peer. The querying/initiator peer is contacted again if a response expected by it. Initiator peer does not have control over the algorithm. 11

20 Chapter 3. R 5 N DHT Design Kademlia Kademlia DHT has been shown to work well with common rates of churn [11] and capable of handling large number of peers [12]. But Kademlia is vulnerable to Sybil [13] attacks. Kademlia s routing table is structured as an array of k-buckets. Here, k is the number of bits in the identifier space. The j th k bucket stores upto k peers, whose identifiers are between distance 2 j and 2 (j+1) from the local peer. Distance between two peer IDs are calculated using XOR. Kademlia lookup algorithm is iterative. In iterative algorithm, the initiating peer directly contacts the next hop, collects information and iterate the process until it reaches the destination hop. Hence, the iterator has direct control over the whole lookup algorithm. In Kademlia, at each hop the intiating node picks r closest peers for the next hop. These r peers are queried and they return a set of peers closer to the key. The algorithm stops when no more closer peers are found. The data is finally stored at the final r closest peers. Kademlia contacts O(log n) peers during the search in n peer system R 5 N Design Routing Routing table in R 5 N is constructed similar to Kademlia. But it uses a recursive routing. Routing is completed in two phases. In first phase, the message is forwarded to some number of hops. When the hop counter exceeds a threshold, T = logn, where n is the network size, routing starts its second phase. In phase two, routing is done deterministically through the set of peers from the routing table that are closest to the target key. The first phase of routing makes the lookup independent of the initiator s location, and the second phase finds the nearest peer PUT/GET In R 5 N, data to be stored is replicated at large number of peers that are closer to the key. A PUT operation stores the data at a random subset of these peers, and GET attempts to get the data from one of these replicas. The PUT requests are repeated at regular interval to handle churn and increase replication. Since R 5 N follows nondeterministic routing, repeated PUT may store data at different peers. These replicated PUTs increase chance of a successful GET. R 5 N also retries GET request few times to increase the chance of reaching to the correct data.

21 Chapter 3. R 5 N DHT Security R 5 N derives its security through the non-deterministic routing. As the GET and PUT requests take different route each time, it is difficult for an adversary to position itself to eclipse a particular key-data pair. Also, R 5 N two phase routing algorithm acts as defense against Denial of Service attack. The number of hops a request can travel is bounded by the threshold, T. This limits the flooding of message by an adversary. 3.3 X-Vine and R 5 N X-Vine and R 5 N are secure DHTs. X-Vine uses social network links, but R 5 N uses non-deterministic routing for security. Similar to R 5 N, X-Vine also do not make assumption about universal connectivity. Peers in X-Vine can communicate only with their immediate friends.

22 Chapter 4 X-Vine GNUnet Implementation 4.1 GNUnet GNUnet is a free software peer to peer framework with main focus on security. Figure 4.1 shows the GNUnet system architecture. It consist of layers of services. Each service provides a set of APIs. Other services can access its functionality through these set of APIs. GNUnet also contains user interfaces. User interface uses other services through their APIs but they don t have their own APIs. GNUnet provides a range of services and user interfaces, which are then combined into a layered GNUnet instance referred as GNUnet peer. [14] Figure 4.1: GNUnet Architecure [14] 14

23 Chapter 4. X-Vine GNUnet Implementation GNUnet DHT System Figure 4.2 shows GNUnet DHT system and its interaction with other relevant subsystems of GNUnet. DHT Client Request Response DHT Service (R5N / XVine) Send Receive Core Put Get Put Datacache Stats Figure 4.2: DHT service and its interaction with other relevant subsytem 1. DHT Client A DHT user accesses the DHT service through its APIs, PUT and GET. DHT client handles these requests and pass them on to the specific DHT service. 2. DHT Service DHT Service receives requests from the DHT Client and from other peers. executes the lookup and routing protocol to appropriately serve the requests. It 3. Datacache Datacache maintains an ephemeral storage for key/data pairs. DHT Service interacts with Datacache service to store and fetch the DHT Data. 4. Core The Core subsystem sets up secure communications between nodes in the GNUnet overlay network. It is build upon the Transport subsystem of GNUnet, that provides the actual link layer communication. DHT uses APIs provided by Core to send/receive messages from other peers in the overlay network. 5. Statistics DHT Service uses APIs provided by Statistics subsystem to record performance related statistics like traffic generated and packet dropped by DHT. Due to the layered-architecture of GNUnet, it is possible to swap one implementation of a service with another, while keeping the APIs same. GNUnet currently uses R 5 N DHT. X-Vine has been implemented as a separate DHT service in GNUnet, and it uses the same client side interface as R 5 N.

24 Chapter 4. X-Vine GNUnet Implementation Key and Peer Identifier Space X-Vine is based on Chord. Given any network topology, X-Vine should connect its peers in a Chord ring overlay topology. We consider a 64-bit identifier space for our implementation. In GNUnet, a peer identity is of type struct GNUNET PeerIdentity which is a 256-bit value. The key used in GNUnet is of type struct GNUNET Hashcode which is a 512-bit value. We extract the 64 most significant bits from the peer identity and key, and use it as a unique identifier. For simplicity, the terms key and peer identity will be used to refer to the 64 bit identifier when discussing in context of the Chord overlay. 4.4 Global Data Structures In X-Vine, every peer maintains the following data structures: 1. Friend Peermap The Friend Peermap keeps track of all friends connected to the peer. Peers connected through the core are added as friends of each other. This data structure is a hash map that uses peer identity as hash key. An individual entry of the Friend Peermap is represented by struct FriendInfo. Peers can send and receive messages only through their friends. Hence, a per-friend queue is maintained to keep a track of Pending Messages to be sent to the friend. 2. Finger Table It keeps track of all fingers of the peer. This data structure is implemented using an array. An individual entry of this array is represented by struct FingerInfo. It contains the unique peer identity of the finger, and a list of trails which can be used to reach the finger. 3. Routing Table A peer stores information about trails (of which it is a part), in its Routing Table. A trail is uniquely identified by its trail id. The routing table is implemented as a hashmap with trail id as the hash key. An individual entry is represented by struct RoutingTrail. It contains the peer identities of the next hop and the previous hop of the trail. 4.5 X-Vine Client-Service Protocol This section describes the interaction between DHT client and DHT service PUTing data into DHT The client sends a struct GNUNET DHT ClientPutMessage to the service to PUT (store) data into DHT. Along with the key-data pair, the message has the following fields.

25 Chapter 4. X-Vine GNUnet Implementation bit unique ID for PUT operation The service uses the same 64-bit ID to send back the PUT confirmation to the client. 2. Desired replication level R 5 N performs PUT at the number of peers specified by this field. But in current implementation of X-Vine, this field is not being used. X-Vine stores the data at a single peer. 3. Expiration time Data in DHT is ephemeral. The data is deleted after expiration time as specified during PUT. 4. Block type Data is stored in blocks in Datacache. This field specifies the data format. The service sends a PUT confirmation as soon as it has locally processed the request. But PUT request may still be propagating in the network toward its destination peer. A subsequent GET (retrieve) may or may not succeed, depending on the progress of PUT message GETing data from DHT The client sends a struct GNUNET DHT ClientGetMessage to the service to GET (retrieve) the data from the DHT. The message contains a unique 64-bit ID for GET operation, key for the data to be fetched and block type of the desired data. The interpretation of these fields is the same as in the PUT message. Apart from these fields, the GET message also contains replication level field, that specifies the number of routes over which R 5 N should try to retrieve the data. This field is not being used in X-Vine. The service responds with struct GNUNET DHT ClientResultMessages. The response contains the block type, expiration, key, unique ID of the request and the value (block) corresponding to the key. 4.6 X-Vine Peer to Peer Protocol X-Vine peers interact among themselves such that they can achieve the following goals: 1. Setup and Maintenance of Overlay Ring Topology. Peers exchange a set of messages among themselves to setup an overlay Chord ring topology. In case of churn, peers also need to ensure that the ring topology is maintained. Section 4.7 and 4.8 describe the algorithms. 2. Storage and lookup of key-data pair. To handle PUT and GET request from clients, peers exchange messages such that they can find the correct peer to store/retrieve the data. Section 4.9 explain the details of the algorithm used in this phase.

26 Chapter 4. X-Vine GNUnet Implementation Overlay Ring Topology Setup In this phase, every peer sets up its friend and finger table. A peer connected directly through Core is added as a friend. Section describes the algorithm to search for fingers in the network Search space In a 64 bit identifier space, a peer can have 64 possible fingers. Additionally, a peer keeps track of its immediate predecessor. In X-Vine current implementation, the peer starts the search with its successor (finger index = 0), followed by its immediate predecessor. After finding these two fingers, it starts the search backward, iterating from finger index 63 to finger index Trail Setup Algorithm Trail Setup Algorithm is used to establish trails for successor, predecessor and each finger of the peer. The peer periodically looks for its fingers, and stores multiple trails to reach the same finger. This improves resilience against Sybil attacks, as the peer can randomly choose the trail to reach a finger, thereby reducing the probability of choosing a trail with a malicious node. The peer which is looking for its finger in the network is referred as source peer. It performs the following steps: 1. Using the Chord formula, source peer computes a 64-bit finger identity value from its own 64-bit peer identity (Section 2.1.2). The peer which is the closest successor of finger identity value will be the source peer s finger. Peer identity of closest successor is not known to source peer. 2. Source Peer constructs a message of type struct PeerTrailSetupMessage. The message contains, finger identity value, trail id, a unique identifier for the trail to be constructed from the source peer to its finger, trail, list of identities of peers which will be part of the trail, and intermediate trail id, which will be explained later. 3. The source peer sends the message to a randomly selected friend to start the search for its finger. Every peer that receives the trail setup message performs the following steps. 1. Receiving peer searches its own friend and finger table for a peer, closer than itself to the finger identity value.

27 Chapter 4. X-Vine GNUnet Implementation If the closest peer is a friend, the receiving peer adds its peer identity to the trail in the message, and forwards the trail setup message to the friend. 3. If the closest peer is a finger, the trail setup message must be forwarded on the trail to this finger. The receiving peer updates the field, intermediate trail id with the trail id of the trail from receiving peer to the closest finger. It adds its own identity to the trail, and forwards the message to the first peer in the intermediate trail. 4. If the receiving peer is the closest successor of finger identity value, it must be the required finger. It constructs a struct PeerTrailSetupResultMessage and sends it back to the source peer, through the same trail. Every peer which is part of the trail adds an entry in its routing table. Figure 4.3 illustrates the algorithm with an example. Let us consider a 6-bit identifier space, with peer identities ranging from 0 to 63. Peer 0 is looking for a finger, indexed 5. The finger identity value is calculated to be 32. Peer 0 forwards trail setup message to its friend, peer 5. Peer 5 looks for the closest peer, and forwards the message to its friend, peer 20. Peer 20 finds its finger, peer 28 to be closer and forwards the message along the intermediate trail. Peer 7 on the intermediate trail has a friend closer than the finger (peer 28) and forwards the request to peer 30. Peer 30 forwards the request to its friend, peer 34. Peer 34 is the closest successor of finger identity value. Peer 34 then sends the trail setup result message back, and every peer on the trail adds an entry in their routing table. 4.8 Overlay Ring Topology Maintenance To handle churn, each X-Vine peer periodically verifies its successor and predecessor pointers. This ensures that even with nodes joining and leaving, eventually all the peers will be connected in overlay ring topology. Figure 4.4 shows the state diagram of the peer which follows the algorithm to keep its successor and predecessor pointers updated Looking for Successor At the beginning, each peer tries to search for its successor using the Trail Setup Algorithm explained in Section When a successor is found, the peer sends a message of type struct PeerVerifySuccessorMessage to the newly found successor. This message is sent again, if a reply is not received from the successor within a specific timeout Verify Successor The relationship between a successor and predecessor is mutual, i.e. each peer must be the predecessor of its successor. The peer which receives the verify successor message checks if this relation holds true. If the receiving peer is a valid successor, it sends a message of type struct PeerVerifySuccessorResultMessage to the source peer to indicates its validity.

28 Chapter 4. X-Vine GNUnet Implementation (a) Peer 0 initiates trail setup for finger identity value = (b) Peer 0 forwards trail setup message to randomly selected friend, peer (c) Peer 5 forwards message to closest friend, peer (d) Peer 20 forwards message to closest finger peer (e) Peer 7 in intermediate trail, finds a friend closer than finger, and forwards to peer 30. TrailID Prev Next id_0 0 5 TrailID Prev Next id_ TrailID Prev Next id_ (f) Finger 30 forwards to closest friend peer 34, which is the finger. It sends result back, and all peers add entry in Routing Table. Figure 4.3: Trail Setup example

29 Chapter 4. X-Vine GNUnet Implementation 21 Figure 4.4: State Machine Diagram to illustrate Overlay Ring Topology Maintenance. However, if the condition is not true, there exists a peer P, which is the current predecessor of the receiving peer. Peer P could be the successor of the source peer. The receiving peer sends the struct PeerVerifySuccessorResultMessage to the source peer, indicating that it is not a valid successor. The message also contains the identity of peer P, and the trail to get to peer P from the source peer. This trail is a concatenation of the trails from source peer to receiving peer, and from the receiving peer to peer P Verify Successor Result The initiating peer performs either of the two following tasks depending on the result of the verify successor message.

30 Chapter 4. X-Vine GNUnet Implementation 22 If the result says, that the recipient was indeed a valid successor, the peer reschedules the verify successor task after a delay. This delay is exponentially incremented as the stability of the network grows. If the recipient was not a valid successor, the peer updates its current successor to the peer which is indicated as a probable successor in the result. The peer then sends a message of type struct PeerNotifyNewSuccessorMessage to the new successor. The aim of this message is to notify all peers in the trail to add the routing information in their routing tables. This message is sent again, if the acknowledgement is not received from the new successor Notify Successor Each peer on the trail from initiating peer to the new successor, adds routing information to their routing tables, and forwards the message. On receiving the message, the new successor acknowledges it by sending a message of type struct PeerNotifyConfirmationMessage back to the initiating peer Notify Successor Confirmation On receiving the acknowledgement from the new successor, the initiating peer again sends the verify successor message to the new successor. This periodic process ensures that the overlay ring topology is maintained when churn occurs in the network. 4.9 Storage and lookup of key-data pair Handling PUT request The peer which receives the PUT Request from the DHT Client uses the look up protocol to reach the peer which is responsible for storing the key-data pair. In lookup, the DHT Service identifies the closest successor of the key, using the similar algorithm as for trail setup. It forwards the PUT request to the successor. The receiving peer performs similar lookup and forwards the request. The PUT request is subsequently delivered to the peer which is responsible for storing the key-data pair. The destination peer then stores the key-data pair Handling GET request The peer which receives the GET Request from the DHT Client uses similar look up protocol to reach the peer where the key should have been stored.

31 Chapter 4. X-Vine GNUnet Implementation 23 The GET Result must also be sent through the same path used by the GET Request. Hence, each peer appends its own identity to the list of peers who have forwarded the GET Request Message. The destination peer, looks for the requested key in its datacache. If the key is not found, a message of type struct PeerGetResultMessage is sent to the requesting peer, indicating that a GET failure has occured. If the key is found, the data associated with the key is sent to the requesting peer in the message of type struct PeerGetResultMessage Security Protocol For secure lookup and routing algorithm, X-Vine implementation defines the following threshold. 1. Maximum Trails through a friend. A peer can locally decide a threshold on number of trails it wants to setup through any of its friends. It is defined by MAXIMUM TRAILS PER FINGER. The attack edges, g are limited in a social network graph. Hence, the total number of attack edges that an adversary can launch is bounded by (g * MAXIMUM TRAILS PER FINGER). 2. Bounded Routing State Size The threshold, ROUTING TABLE THRESHOLD, states the number of trails of which a peer wants to be part of. This limit ensures that no adversary can overburden a peer s resource. A peer that has reached this threshold, rejects all the trail setup request. It sends a struct PeerTrailRejectionMessage to the previous hop that forwarded it the trail setup request. The message contains a time estimate, CONGESTION TIMEOUT, for which the peer assumes it will be unavailable. 3. Redundant Routing Malicious peers can drop PUT/GET request. In order to make progress even with malicious peers, each peer stores multiple trails to reach to its finger. Maximum number of possible trails is defined by parameter, MAXIMUM TRAILS PER FINGER. In case of PUT/GET, an honest node sends the request across all the trails to reach to destination finger. This increases the chance of taking a path with honest nodes. All the thresholds described above are set statically in the current implementation.

32 Chapter 5 Experimental Setup This chapter explains the environment used to compare R 5 N and X-Vine. Section 5.1 lists down the parameters used to compare the two DHTs. Section 5.2 explains in detail the features of profiler which collects the relevant statistics from the DHT services. 5.1 Comparison Parameters Given same topology and the network size, R 5 N and X-Vine performance is compared for the following fields: 1. Successful GETs This field specifies the number of GETs that retrieved the correct data from DHT. 2. Average PUT and GET path length This field gives the number of hops taken to reach to the destination peer for PUT and GET request. 3. Control and Data Traffic This field gives the count of total number of messages exchanged among the peers in DHT service. 5.2 DHT Profiler DHT Profiler collects the relevant statistics needed for comparison of the DHT services. It uses the Testbed subsystem of GNUnet. Testbed subsystem starts a specified number of peers and connect them in the user desired topology. Once the peers are connected in a particular topology, the profiler starts the DHT service on all of the peers. Profiler collects the following relevant information 1. Control and Data Traffic Every peer running the DHT service, stores the total number of messages it received or sent through the Core into the Statistics subsystem. Profiler collects it from all the peers, and returns the total traffic generated by the DHT service. 24

33 Chapter 5. Experimental Setup PUT/GET length PUT/GET requests provides an option, GNUNET DHT RO RECORD ROUTE. This option instructs the DHT to keep track of the PUT/GET path followed in the overlay topology. Profiler sets this option when doing PUT/GET. 3. PUTs/GETs Profiler specifies a time out for PUT and GET operation. The PUTs are always 100% as the DHT service sends the PUT confirmation as soon as it has locally processed the message. For GETs, the profiler checks if the data returned for a particular key is of same size as expected. GETs may fail if they are not completed within the specified timeout set by the profiler. In case of X-Vine, the profiler waits for the network to stabilize before starting the PUTs and GETs. The network is considered to be stabilized when all the peers have found their correct successor, and have at least O(log n) finger entries, where n is the total number of peers in the system.

34 Chapter 6 Results and Analysis R 5 N and X-Vine are compared using two different topologies, Scale Free and 2D Torus. The X-Vine has been shown to work well in Scale Free topology. R 5 N has been proven to work well in 2D Tours. Hence, these two topologies were selected. For both the topologies, experiments were done with varying network sizes. Section 6.1 and Section 6.2 discusses the results for Scale Free and 2D Torus topologies respectively. For all the experiments, replication level in PUT and GET operation for R 5 N was set to 1. Timeout for PUT and GET operation was set to 30 seconds. The experiments were performed only for non-malicious peers. 6.1 Scale Free Topology Scale free topology is a network where the number of outgoing links of a node follow a Power law distribution. This topology is constructed progressively by adding nodes to the network and introducing links to existing nodes, such that the probability of linking to a given node, i is proportional to the number of existing links, k, that node has [15]. TESTBED subsystem requires two parameters to be provided for construction of Scale free topology. 1. SCALE FREE CAP This specifies the maximum number of edges a peer is permitted to have while generating scale free topology. Its value is set to SCALE FREE M This specifies the number of edges to be established when adding a new node to the scale free network. Its value is set to Analysis In this topology, the GETs were completed successfully for both the DHTs. Table 6.1 shows the average PUT path and GET path length for X-Vine and R 5 N. 26

35 Chapter 6. Results and Analysis 27 For small networks, the average PUT and GET path length for both the DHTs are comparable. But as the network size increases, R 5 N s average PUT/GET path length increases marginally but X-Vine shows a significant increase. The reason for such pattern is that in X-Vine, a peer can send and receive the messages only from its friends. If a peer s finger is the closest successor to the key, the peer traverse the trail to reach it. Unlike R 5 N, X-Vine do not have any replication strategy, and the data is always stored at a single peer. Hence, as the network increases, the average PUT/GET path length increases. Network Size Avg. PUT Length Avg. GET Length X-Vine R 5 N X-Vine R 5 N Table 6.1: Average PUT and GET path length in Scale Free for different network sizes. Table 6.2 shows the control and data traffic caused by the two DHTs. As expected, X-Vine generates significantly higher traffic. In X-Vine, peers exchange compartively higher number of messages to set up and maintain the overly ring topology [4.7][4.8]. In some of the messages, trails(a list of peers) are being passed. As seen in table 6.1, the average PUT/GET path length is higher for X-Vine. Hence, the total traffic generated is so high. Network Size Bandwidth X-Vine R 5 N Table 6.2: Control and Data traffic in Scale Free topology for different network size D Torus 2D Torus is a network topology, where a peer has total number of outgoing edges 4. In a N-Torus network, there are N neighbours in horizontal dimension and N neighbours in vertical dimension Analysis Table 6.3 shows the total number of PUTs made and corresponding number of successful GETs. Unlike Scale Free topology, R 5 N does not have 100% successful GETs. For the experiments, only one replication was used. Therefore, not all the GETs were successful.

March 10, Distributed Hash-based Lookup. for Peer-to-Peer Systems. Sandeep Shelke Shrirang Shirodkar MTech I CSE

March 10, Distributed Hash-based Lookup. for Peer-to-Peer Systems. Sandeep Shelke Shrirang Shirodkar MTech I CSE for for March 10, 2006 Agenda for Peer-to-Peer Sytems Initial approaches to Their Limitations CAN - Applications of CAN Design Details Benefits for Distributed and a decentralized architecture No centralized

More information

Lecture 6: Overlay Networks. CS 598: Advanced Internetworking Matthew Caesar February 15, 2011

Lecture 6: Overlay Networks. CS 598: Advanced Internetworking Matthew Caesar February 15, 2011 Lecture 6: Overlay Networks CS 598: Advanced Internetworking Matthew Caesar February 15, 2011 1 Overlay networks: Motivations Protocol changes in the network happen very slowly Why? Internet is shared

More information

CS555: Distributed Systems [Fall 2017] Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2017] Dept. Of Computer Science, Colorado State University CS 555: DISTRIBUTED SYSTEMS [P2P SYSTEMS] Shrideep Pallickara Computer Science Colorado State University Frequently asked questions from the previous class survey Byzantine failures vs malicious nodes

More information

LECT-05, S-1 FP2P, Javed I.

LECT-05, S-1 FP2P, Javed I. A Course on Foundations of Peer-to-Peer Systems & Applications LECT-, S- FPP, javed@kent.edu Javed I. Khan@8 CS /99 Foundation of Peer-to-Peer Applications & Systems Kent State University Dept. of Computer

More information

GNUnet Distributed Data Storage

GNUnet Distributed Data Storage GNUnet Distributed Data Storage DHT and Distance Vector Transport Nathan S. Evans 1 1 Technische Universität München Department of Computer Science Network Architectures and Services July, 24 2010 Overview

More information

Chord : A Scalable Peer-to-Peer Lookup Protocol for Internet Applications

Chord : A Scalable Peer-to-Peer Lookup Protocol for Internet Applications : A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Ion Stoica, Robert Morris, David Liben-Nowell, David R. Karger, M. Frans Kaashock, Frank Dabek, Hari Balakrishnan March 4, 2013 One slide

More information

08 Distributed Hash Tables

08 Distributed Hash Tables 08 Distributed Hash Tables 2/59 Chord Lookup Algorithm Properties Interface: lookup(key) IP address Efficient: O(log N) messages per lookup N is the total number of servers Scalable: O(log N) state per

More information

Content Overlays. Nick Feamster CS 7260 March 12, 2007

Content Overlays. Nick Feamster CS 7260 March 12, 2007 Content Overlays Nick Feamster CS 7260 March 12, 2007 Content Overlays Distributed content storage and retrieval Two primary approaches: Structured overlay Unstructured overlay Today s paper: Chord Not

More information

Overlay and P2P Networks. Structured Networks and DHTs. Prof. Sasu Tarkoma

Overlay and P2P Networks. Structured Networks and DHTs. Prof. Sasu Tarkoma Overlay and P2P Networks Structured Networks and DHTs Prof. Sasu Tarkoma 6.2.2014 Contents Today Semantic free indexing Consistent Hashing Distributed Hash Tables (DHTs) Thursday (Dr. Samu Varjonen) DHTs

More information

Distributed Systems Final Exam

Distributed Systems Final Exam 15-440 Distributed Systems Final Exam Name: Andrew: ID December 12, 2011 Please write your name and Andrew ID above before starting this exam. This exam has 14 pages, including this title page. Please

More information

Detecting and Recovering from Overlay Routing Attacks in Peer-to-Peer Distributed Hash Tables

Detecting and Recovering from Overlay Routing Attacks in Peer-to-Peer Distributed Hash Tables Detecting and Recovering from Overlay Routing Attacks in Peer-to-Peer Distributed Hash Tables A thesis for the degree of Master of Science in Computer Science Keith Needels keithn@csh.rit.edu Department

More information

Peer to Peer I II 1 CS 138. Copyright 2015 Thomas W. Doeppner, Rodrigo Fonseca. All rights reserved.

Peer to Peer I II 1 CS 138. Copyright 2015 Thomas W. Doeppner, Rodrigo Fonseca. All rights reserved. Peer to Peer I II 1 Roadmap This course will feature key concepts in Distributed Systems, often illustrated by their use in example systems Start with Peer-to-Peer systems, which will be useful for your

More information

Scalability In Peer-to-Peer Systems. Presented by Stavros Nikolaou

Scalability In Peer-to-Peer Systems. Presented by Stavros Nikolaou Scalability In Peer-to-Peer Systems Presented by Stavros Nikolaou Background on Peer-to-Peer Systems Definition: Distributed systems/applications featuring: No centralized control, no hierarchical organization

More information

Goals. EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Solution. Overlay Networks: Motivations.

Goals. EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Solution. Overlay Networks: Motivations. Goals CS : Introduction to Computer Networks Overlay Networks and PP Networks Ion Stoica Computer Science Division Department of lectrical ngineering and Computer Sciences University of California, Berkeley

More information

Telematics Chapter 9: Peer-to-Peer Networks

Telematics Chapter 9: Peer-to-Peer Networks Telematics Chapter 9: Peer-to-Peer Networks Beispielbild User watching video clip Server with video clips Application Layer Presentation Layer Application Layer Presentation Layer Session Layer Session

More information

Distributed Systems. 16. Distributed Lookup. Paul Krzyzanowski. Rutgers University. Fall 2017

Distributed Systems. 16. Distributed Lookup. Paul Krzyzanowski. Rutgers University. Fall 2017 Distributed Systems 16. Distributed Lookup Paul Krzyzanowski Rutgers University Fall 2017 1 Distributed Lookup Look up (key, value) Cooperating set of nodes Ideally: No central coordinator Some nodes can

More information

EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Overlay Networks: Motivations

EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Overlay Networks: Motivations EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley

More information

Resilient GIA. Keywords-component; GIA; peer to peer; Resilient; Unstructured; Voting Algorithm

Resilient GIA. Keywords-component; GIA; peer to peer; Resilient; Unstructured; Voting Algorithm Rusheel Jain 1 Computer Science & Information Systems Department BITS Pilani, Hyderabad Campus Hyderabad, A.P. (INDIA) F2008901@bits-hyderabad.ac.in Chittaranjan Hota 2 Computer Science & Information Systems

More information

CS514: Intermediate Course in Computer Systems

CS514: Intermediate Course in Computer Systems Distributed Hash Tables (DHT) Overview and Issues Paul Francis CS514: Intermediate Course in Computer Systems Lecture 26: Nov 19, 2003 Distributed Hash Tables (DHT): Overview and Issues What is a Distributed

More information

Problems in Reputation based Methods in P2P Networks

Problems in Reputation based Methods in P2P Networks WDS'08 Proceedings of Contributed Papers, Part I, 235 239, 2008. ISBN 978-80-7378-065-4 MATFYZPRESS Problems in Reputation based Methods in P2P Networks M. Novotný Charles University, Faculty of Mathematics

More information

L3S Research Center, University of Hannover

L3S Research Center, University of Hannover , University of Hannover Structured Peer-to to-peer Networks Wolf-Tilo Balke and Wolf Siberski 3..6 *Original slides provided by K. Wehrle, S. Götz, S. Rieche (University of Tübingen) Peer-to-Peer Systems

More information

Distributed Systems. 17. Distributed Lookup. Paul Krzyzanowski. Rutgers University. Fall 2016

Distributed Systems. 17. Distributed Lookup. Paul Krzyzanowski. Rutgers University. Fall 2016 Distributed Systems 17. Distributed Lookup Paul Krzyzanowski Rutgers University Fall 2016 1 Distributed Lookup Look up (key, value) Cooperating set of nodes Ideally: No central coordinator Some nodes can

More information

Lecture 8: Application Layer P2P Applications and DHTs

Lecture 8: Application Layer P2P Applications and DHTs Lecture 8: Application Layer P2P Applications and DHTs COMP 332, Spring 2018 Victoria Manfredi Acknowledgements: materials adapted from Computer Networking: A Top Down Approach 7 th edition: 1996-2016,

More information

PEER-TO-PEER (P2P) systems are now one of the most

PEER-TO-PEER (P2P) systems are now one of the most IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 25, NO. 1, JANUARY 2007 15 Enhancing Peer-to-Peer Systems Through Redundancy Paola Flocchini, Amiya Nayak, Senior Member, IEEE, and Ming Xie Abstract

More information

Peer-to-Peer Systems and Distributed Hash Tables

Peer-to-Peer Systems and Distributed Hash Tables Peer-to-Peer Systems and Distributed Hash Tables CS 240: Computing Systems and Concurrency Lecture 8 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. Selected

More information

P2P Network Structured Networks: Distributed Hash Tables. Pedro García López Universitat Rovira I Virgili

P2P Network Structured Networks: Distributed Hash Tables. Pedro García López Universitat Rovira I Virgili P2P Network Structured Networks: Distributed Hash Tables Pedro García López Universitat Rovira I Virgili Pedro.garcia@urv.net Index Description of CHORD s Location and routing mechanisms Symphony: Distributed

More information

Peer to peer systems: An overview

Peer to peer systems: An overview Peer to peer systems: An overview Gaurav Veda (Y1148) gveda@cse.iitk.ac.in Computer Science & Engineering Indian Institute of Technology Kanpur, UP, INDIA - 208016 Abstract Peer-to-peer (p2p) systems is

More information

L3S Research Center, University of Hannover

L3S Research Center, University of Hannover , University of Hannover Dynamics of Wolf-Tilo Balke and Wolf Siberski 21.11.2007 *Original slides provided by S. Rieche, H. Niedermayer, S. Götz, K. Wehrle (University of Tübingen) and A. Datta, K. Aberer

More information

Introduction to Peer-to-Peer Systems

Introduction to Peer-to-Peer Systems Introduction Introduction to Peer-to-Peer Systems Peer-to-peer (PP) systems have become extremely popular and contribute to vast amounts of Internet traffic PP basic definition: A PP system is a distributed

More information

Kademlia: A P2P Informa2on System Based on the XOR Metric

Kademlia: A P2P Informa2on System Based on the XOR Metric Kademlia: A P2P Informa2on System Based on the XOR Metric Today! By Petar Mayamounkov and David Mazières, presented at IPTPS 22 Next! Paper presentation and discussion Image from http://www.vs.inf.ethz.ch/about/zeit.jpg

More information

CompSci 356: Computer Network Architectures Lecture 21: Overlay Networks Chap 9.4. Xiaowei Yang

CompSci 356: Computer Network Architectures Lecture 21: Overlay Networks Chap 9.4. Xiaowei Yang CompSci 356: Computer Network Architectures Lecture 21: Overlay Networks Chap 9.4 Xiaowei Yang xwy@cs.duke.edu Overview Problem Evolving solutions IP multicast Proxy caching Content distribution networks

More information

CRESCENDO GEORGE S. NOMIKOS. Advisor: Dr. George Xylomenos

CRESCENDO GEORGE S. NOMIKOS. Advisor: Dr. George Xylomenos CRESCENDO Implementation of Hierarchical Chord (Crescendo), according to Canon paradigm and evaluation, via simulation over realistic network topologies, of the Crescendo's advantages in comparison to

More information

Overlay Networks: Motivations. EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Motivations (cont d) Goals.

Overlay Networks: Motivations. EECS 122: Introduction to Computer Networks Overlay Networks and P2P Networks. Motivations (cont d) Goals. Overlay Networks: Motivations CS : Introduction to Computer Networks Overlay Networks and PP Networks Ion Stoica Computer Science Division Department of lectrical ngineering and Computer Sciences University

More information

Motivation for peer-to-peer

Motivation for peer-to-peer Peer-to-peer systems INF 5040 autumn 2015 lecturer: Roman Vitenberg INF5040, Frank Eliassen & Roman Vitenberg 1 Motivation for peer-to-peer Ø Inherent restrictions of the standard client/ server model

More information

S/Kademlia: A Practicable Approach Towards Secure Key Based Routing

S/Kademlia: A Practicable Approach Towards Secure Key Based Routing S/Kademlia: A Practicable Approach Towards Secure Key Based Routing Ingmar Baumgart, Sebastian Mies P2P NVE 2007, Hsinchu, Taiwan, Institute of Telematics Prof. Dr. M. Zitterbart Motivation Kademlia is

More information

Chord: A Scalable Peer-to-peer Lookup Service For Internet Applications

Chord: A Scalable Peer-to-peer Lookup Service For Internet Applications Chord: A Scalable Peer-to-peer Lookup Service For Internet Applications Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan Presented by Jibin Yuan ION STOICA Professor of CS

More information

Peer-to-Peer Systems. Network Science: Introduction. P2P History: P2P History: 1999 today

Peer-to-Peer Systems. Network Science: Introduction. P2P History: P2P History: 1999 today Network Science: Peer-to-Peer Systems Ozalp Babaoglu Dipartimento di Informatica Scienza e Ingegneria Università di Bologna www.cs.unibo.it/babaoglu/ Introduction Peer-to-peer (PP) systems have become

More information

Debunking some myths about structured and unstructured overlays

Debunking some myths about structured and unstructured overlays Debunking some myths about structured and unstructured overlays Miguel Castro Manuel Costa Antony Rowstron Microsoft Research, 7 J J Thomson Avenue, Cambridge, UK Abstract We present a comparison of structured

More information

Distributed K-Ary System

Distributed K-Ary System A seminar presentation Arne Vater and Prof. Schindelhauer Professorship for Computer Networks and Telematik Department of Computer Science University of Freiburg 2007-03-01 Outline 1 2 3 4 5 Outline 1

More information

Security for Structured Peer-to-peer Overlay Networks. Acknowledgement. Outline. By Miguel Castro et al. OSDI 02 Presented by Shiping Chen in IT818

Security for Structured Peer-to-peer Overlay Networks. Acknowledgement. Outline. By Miguel Castro et al. OSDI 02 Presented by Shiping Chen in IT818 Security for Structured Peer-to-peer Overlay Networks By Miguel Castro et al. OSDI 02 Presented by Shiping Chen in IT818 1 Acknowledgement Some of the following slides are borrowed from talks by Yun Mao

More information

Today. Why might P2P be a win? What is a Peer-to-Peer (P2P) system? Peer-to-Peer Systems and Distributed Hash Tables

Today. Why might P2P be a win? What is a Peer-to-Peer (P2P) system? Peer-to-Peer Systems and Distributed Hash Tables Peer-to-Peer Systems and Distributed Hash Tables COS 418: Distributed Systems Lecture 7 Today 1. Peer-to-Peer Systems Napster, Gnutella, BitTorrent, challenges 2. Distributed Hash Tables 3. The Chord Lookup

More information

Content Overlays (continued) Nick Feamster CS 7260 March 26, 2007

Content Overlays (continued) Nick Feamster CS 7260 March 26, 2007 Content Overlays (continued) Nick Feamster CS 7260 March 26, 2007 Administrivia Quiz date Remaining lectures Interim report PS 3 Out Friday, 1-2 problems 2 Structured vs. Unstructured Overlays Structured

More information

Winter CS454/ Assignment 2 Instructor: Bernard Wong Due date: March 12 15, 2012 Group size: 2

Winter CS454/ Assignment 2 Instructor: Bernard Wong Due date: March 12 15, 2012 Group size: 2 Winter CS454/654 2012 Assignment 2 Instructor: Bernard Wong Due date: March 12 15, 2012 Group size: 2 Distributed systems is a rapidly evolving field. Most of the systems we have studied (or will study)

More information

Searching for Shared Resources: DHT in General

Searching for Shared Resources: DHT in General 1 ELT-53206 Peer-to-Peer Networks Searching for Shared Resources: DHT in General Mathieu Devos Tampere University of Technology Department of Electronics and Communications Engineering Based on the original

More information

CS 640 Introduction to Computer Networks. Today s lecture. What is P2P? Lecture30. Peer to peer applications

CS 640 Introduction to Computer Networks. Today s lecture. What is P2P? Lecture30. Peer to peer applications Introduction to Computer Networks Lecture30 Today s lecture Peer to peer applications Napster Gnutella KaZaA Chord What is P2P? Significant autonomy from central servers Exploits resources at the edges

More information

: Scalable Lookup

: Scalable Lookup 6.824 2006: Scalable Lookup Prior focus has been on traditional distributed systems e.g. NFS, DSM/Hypervisor, Harp Machine room: well maintained, centrally located. Relatively stable population: can be

More information

Searching for Shared Resources: DHT in General

Searching for Shared Resources: DHT in General 1 ELT-53207 P2P & IoT Systems Searching for Shared Resources: DHT in General Mathieu Devos Tampere University of Technology Department of Electronics and Communications Engineering Based on the original

More information

Peer-to-Peer Systems and Security

Peer-to-Peer Systems and Security Peer-to-Peer Systems and Security Attacks! Christian Grothoff Technische Universität München April 13, 2013 Salsa & AP3 Goal: eliminate trusted blender server Idea: Use DHT (AP3: Pastry, Salsa: custom

More information

Introduction to P2P Computing

Introduction to P2P Computing Introduction to P2P Computing Nicola Dragoni Embedded Systems Engineering DTU Compute 1. Introduction A. Peer-to-Peer vs. Client/Server B. Overlay Networks 2. Common Topologies 3. Data Location 4. Gnutella

More information

Peer-to-peer systems and overlay networks

Peer-to-peer systems and overlay networks Complex Adaptive Systems C.d.L. Informatica Università di Bologna Peer-to-peer systems and overlay networks Fabio Picconi Dipartimento di Scienze dell Informazione 1 Outline Introduction to P2P systems

More information

Peer to Peer Networks

Peer to Peer Networks Sungkyunkwan University Peer to Peer Networks Prepared by T. Le-Duc and H. Choo Copyright 2000-2018 Networking Laboratory P2P Applications Traditional P2P applications: for file sharing BitTorrent, Emule

More information

Effects of Churn on Structured P2P Overlay Networks

Effects of Churn on Structured P2P Overlay Networks International Conference on Automation, Control, Engineering and Computer Science (ACECS'14) Proceedings - Copyright IPCO-214, pp.164-17 ISSN 2356-568 Effects of Churn on Structured P2P Overlay Networks

More information

Finding Data in the Cloud using Distributed Hash Tables (Chord) IBM Haifa Research Storage Systems

Finding Data in the Cloud using Distributed Hash Tables (Chord) IBM Haifa Research Storage Systems Finding Data in the Cloud using Distributed Hash Tables (Chord) IBM Haifa Research Storage Systems 1 Motivation from the File Systems World The App needs to know the path /home/user/my pictures/ The Filesystem

More information

Page 1. How Did it Start?" Model" Main Challenge" CS162 Operating Systems and Systems Programming Lecture 24. Peer-to-Peer Networks"

Page 1. How Did it Start? Model Main Challenge CS162 Operating Systems and Systems Programming Lecture 24. Peer-to-Peer Networks How Did it Start?" CS162 Operating Systems and Systems Programming Lecture 24 Peer-to-Peer Networks" A killer application: Napster (1999) Free music over the Internet Key idea: share the storage and bandwidth

More information

Department of Computer Science Institute for System Architecture, Chair for Computer Networks. File Sharing

Department of Computer Science Institute for System Architecture, Chair for Computer Networks. File Sharing Department of Computer Science Institute for System Architecture, Chair for Computer Networks File Sharing What is file sharing? File sharing is the practice of making files available for other users to

More information

Tracking Objects in Distributed Systems. Distributed Systems

Tracking Objects in Distributed Systems. Distributed Systems Tracking Objects in Distributed Systems Arvind Krishnamurthy Fall 2004 Distributed Systems Consider the Shared virtual memory system (SVM) by Kai Li: It tracks pages in a cluster system Simplest version

More information

Detecting and Recovering from Overlay Routing. Distributed Hash Tables. MS Thesis Defense Keith Needels March 20, 2009

Detecting and Recovering from Overlay Routing. Distributed Hash Tables. MS Thesis Defense Keith Needels March 20, 2009 Detecting and Recovering from Overlay Routing Attacks in Peer-to-Peer Distributed Hash Tables MS Thesis Defense Keith Needels March 20, 2009 Thesis Information Committee: Chair: Professor Minseok Kwon

More information

Chord. Advanced issues

Chord. Advanced issues Chord Advanced issues Analysis Theorem. Search takes O (log N) 5me (Note that in general, when there are m fingers, 2 m may be much larger than N) Proof. A(er log N forwarding steps, distance to key is

More information

Distributed Hash Tables

Distributed Hash Tables KTH ROYAL INSTITUTE OF TECHNOLOGY Distributed Hash Tables Distributed Hash Tables Vladimir Vlassov Large scale data bases hundreds of servers High churn rate servers will come and go Benefits fault tolerant

More information

Modern Technology of Internet

Modern Technology of Internet Modern Technology of Internet Jiří Navrátil, Josef Vojtěch, Jan Furman, Tomáš Košnar, Sven Ubik, Milan Šárek, Jan Růžička, Martin Pustka, Laban Mwansa, Rudolf Blažek Katedra počítačových systémů FIT České

More information

Routing in the Dark: Pitch Black. A Thesis Presented to the Faculty of Engineering and Computer Science University of Denver

Routing in the Dark: Pitch Black. A Thesis Presented to the Faculty of Engineering and Computer Science University of Denver Routing in the Dark: Pitch Black A Thesis Presented to the Faculty of Engineering and Computer Science University of Denver In Partial Fulfillment of the Requirements for the Degree Master of Science by

More information

Cycloid: A constant-degree and lookup-efficient P2P overlay network

Cycloid: A constant-degree and lookup-efficient P2P overlay network Performance Evaluation xxx (2005) xxx xxx Cycloid: A constant-degree and lookup-efficient P2P overlay network Haiying Shen a, Cheng-Zhong Xu a,, Guihai Chen b a Department of Electrical and Computer Engineering,

More information

Overlay networks. To do. Overlay networks. P2P evolution DHTs in general, Chord and Kademlia. Turtles all the way down. q q q

Overlay networks. To do. Overlay networks. P2P evolution DHTs in general, Chord and Kademlia. Turtles all the way down. q q q Overlay networks To do q q q Overlay networks P2P evolution DHTs in general, Chord and Kademlia Turtles all the way down Overlay networks virtual networks Different applications with a wide range of needs

More information

Securing Chord for ShadowWalker. Nandit Tiku Department of Computer Science University of Illinois at Urbana-Champaign

Securing Chord for ShadowWalker. Nandit Tiku Department of Computer Science University of Illinois at Urbana-Champaign Securing Chord for ShadowWalker Nandit Tiku Department of Computer Science University of Illinois at Urbana-Champaign tiku1@illinois.edu ABSTRACT Peer to Peer anonymous communication promises to eliminate

More information

P2P Network Structured Networks: Distributed Hash Tables. Pedro García López Universitat Rovira I Virgili

P2P Network Structured Networks: Distributed Hash Tables. Pedro García López Universitat Rovira I Virgili P2P Network Structured Networks: Distributed Hash Tables Pedro García López Universitat Rovira I Virgili Pedro.garcia@urv.net Index Introduction to DHT s Origins of structured overlays Case studies Chord

More information

Peer to Peer Networks

Peer to Peer Networks Sungkyunkwan University Peer to Peer Networks Prepared by T. Le-Duc and H. Choo Copyright 2000-2017 Networking Laboratory Presentation Outline 2.1 Introduction 2.2 Client-Server Paradigm 2.3 Peer-To-Peer

More information

Page 1. Key Value Storage"

Page 1. Key Value Storage Key Value Storage CS162 Operating Systems and Systems Programming Lecture 14 Key Value Storage Systems March 12, 2012 Anthony D. Joseph and Ion Stoica http://inst.eecs.berkeley.edu/~cs162 Handle huge volumes

More information

An Adaptive Stabilization Framework for DHT

An Adaptive Stabilization Framework for DHT An Adaptive Stabilization Framework for DHT Gabriel Ghinita, Yong Meng Teo Department of Computer Science National University of Singapore {ghinitag,teoym}@comp.nus.edu.sg Overview Background Related Work

More information

Distributed File Systems: An Overview of Peer-to-Peer Architectures. Distributed File Systems

Distributed File Systems: An Overview of Peer-to-Peer Architectures. Distributed File Systems Distributed File Systems: An Overview of Peer-to-Peer Architectures Distributed File Systems Data is distributed among many sources Ex. Distributed database systems Frequently utilize a centralized lookup

More information

DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES

DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES Dr. Jack Lange Computer Science Department University of Pittsburgh Fall 2015 Outline System Architectural Design Issues Centralized Architectures Application

More information

Distributed Hash Tables: Chord

Distributed Hash Tables: Chord Distributed Hash Tables: Chord Brad Karp (with many slides contributed by Robert Morris) UCL Computer Science CS M038 / GZ06 12 th February 2016 Today: DHTs, P2P Distributed Hash Tables: a building block

More information

CS 347 Parallel and Distributed Data Processing

CS 347 Parallel and Distributed Data Processing CS 347 Parallel and Distributed Data Processing Spring 2016 Notes 9: Peer-to-Peer Systems Previous Topics Data Database design Queries Query processing Localization Operators Optimization Transactions

More information

Architectures for Distributed Systems

Architectures for Distributed Systems Distributed Systems and Middleware 2013 2: Architectures Architectures for Distributed Systems Components A distributed system consists of components Each component has well-defined interface, can be replaced

More information

Secure Routing in Peer-to-Peer Distributed Hash Tables

Secure Routing in Peer-to-Peer Distributed Hash Tables Secure Routing in Peer-to-Peer Distributed Hash Tables Keith Needels Department of Computer Science Rochester Institute of Technology Rochester, NY 14623 keithn@csh.rit.edu Minseok Kwon Department of Computer

More information

EE 122: Peer-to-Peer Networks

EE 122: Peer-to-Peer Networks EE 122: Peer-to-Peer Networks Ion Stoica (and Brighten Godfrey) TAs: Lucian Popa, David Zats and Ganesh Ananthanarayanan http://inst.eecs.berkeley.edu/~ee122/ (Materials with thanks to Vern Paxson, Jennifer

More information

internet technologies and standards

internet technologies and standards Institute of Telecommunications Warsaw University of Technology 25 internet technologies and standards Piotr Gajowniczek Andrzej Bąk Michał Jarociński Internet application layer peer-to-peer systems overview

More information

Horizontal or vertical scalability? Horizontal scaling is challenging. Today. Scaling Out Key-Value Storage

Horizontal or vertical scalability? Horizontal scaling is challenging. Today. Scaling Out Key-Value Storage Horizontal or vertical scalability? Scaling Out Key-Value Storage COS 418: Distributed Systems Lecture 8 Kyle Jamieson Vertical Scaling Horizontal Scaling [Selected content adapted from M. Freedman, B.

More information

Priority Based Routing for Mobile Peer-To-Peer Communications

Priority Based Routing for Mobile Peer-To-Peer Communications San Jose State University SJSU ScholarWorks Master's Projects Master's Theses and Graduate Research 2009 Priority Based Routing for Mobile Peer-To-Peer Communications Swathi Venugopal San Jose State University

More information

Overview Computer Networking Lecture 16: Delivering Content: Peer to Peer and CDNs Peter Steenkiste

Overview Computer Networking Lecture 16: Delivering Content: Peer to Peer and CDNs Peter Steenkiste Overview 5-44 5-44 Computer Networking 5-64 Lecture 6: Delivering Content: Peer to Peer and CDNs Peter Steenkiste Web Consistent hashing Peer-to-peer Motivation Architectures Discussion CDN Video Fall

More information

CIS 700/005 Networking Meets Databases

CIS 700/005 Networking Meets Databases Announcements CIS / Networking Meets Databases Boon Thau Loo Spring Lecture Paper summaries due at noon today. Office hours: Wed - pm ( Levine) Project proposal: due Feb. Student presenter: rd Jan: A Scalable

More information

Peer-to-Peer Systems. Chapter General Characteristics

Peer-to-Peer Systems. Chapter General Characteristics Chapter 2 Peer-to-Peer Systems Abstract In this chapter, a basic overview is given of P2P systems, architectures, and search strategies in P2P systems. More specific concepts that are outlined include

More information

An Expresway over Chord in Peer-to-Peer Systems

An Expresway over Chord in Peer-to-Peer Systems An Expresway over Chord in Peer-to-Peer Systems Hathai Tanta-ngai Technical Report CS-2005-19 October 18, 2005 Faculty of Computer Science 6050 University Ave., Halifax, Nova Scotia, B3H 1W5, Canada An

More information

Making Gnutella-like P2P Systems Scalable

Making Gnutella-like P2P Systems Scalable Making Gnutella-like P2P Systems Scalable Y. Chawathe, S. Ratnasamy, L. Breslau, N. Lanham, S. Shenker Presented by: Herman Li Mar 2, 2005 Outline What are peer-to-peer (P2P) systems? Early P2P systems

More information

NodeId Verification Method against Routing Table Poisoning Attack in Chord DHT

NodeId Verification Method against Routing Table Poisoning Attack in Chord DHT NodeId Verification Method against Routing Table Poisoning Attack in Chord DHT 1 Avinash Chaudhari, 2 Pradeep Gamit 1 L.D. College of Engineering, Information Technology, Ahmedabad India 1 Chaudhari.avi4u@gmail.com,

More information

CSCI-1680 P2P Rodrigo Fonseca

CSCI-1680 P2P Rodrigo Fonseca CSCI-1680 P2P Rodrigo Fonseca Based partly on lecture notes by Ion Stoica, Sco5 Shenker, Joe Hellerstein Today Overlay networks and Peer-to-Peer Motivation Suppose you want to write a routing protocol

More information

Scalable overlay Networks

Scalable overlay Networks overlay Networks Dr. Samu Varjonen 1 Lectures MO 15.01. C122 Introduction. Exercises. Motivation. TH 18.01. DK117 Unstructured networks I MO 22.01. C122 Unstructured networks II TH 25.01. DK117 Bittorrent

More information

Distributed Hash Tables

Distributed Hash Tables Distributed Hash Tables CS6450: Distributed Systems Lecture 11 Ryan Stutsman Material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University.

More information

Lecture 6: Securing Distributed and Networked Systems. CS 598: Network Security Matthew Caesar March 12, 2013

Lecture 6: Securing Distributed and Networked Systems. CS 598: Network Security Matthew Caesar March 12, 2013 Lecture 6: Securing Distributed and Networked Systems CS 598: Network Security Matthew Caesar March 12, 2013 1 Today: Distributed Internet Services Previous cycle: how to build Internet services that run

More information

DISTRIBUTED HASH TABLE PROTOCOL DETECTION IN WIRELESS SENSOR NETWORKS

DISTRIBUTED HASH TABLE PROTOCOL DETECTION IN WIRELESS SENSOR NETWORKS DISTRIBUTED HASH TABLE PROTOCOL DETECTION IN WIRELESS SENSOR NETWORKS Mr. M. Raghu (Asst.professor) Dr.Pauls Engineering College Ms. M. Ananthi (PG Scholar) Dr. Pauls Engineering College Abstract- Wireless

More information

Protocol for Tetherless Computing

Protocol for Tetherless Computing Protocol for Tetherless Computing S. Keshav P. Darragh A. Seth S. Fung School of Computer Science University of Waterloo Waterloo, Canada, N2L 3G1 1. Introduction Tetherless computing involves asynchronous

More information

Halo: High-Assurance Locate for Distributed Hash Tables

Halo: High-Assurance Locate for Distributed Hash Tables Halo: High-Assurance Locate for Distributed Hash Tables Apu Kapadia Institute for Security Technology Studies Dartmouth College Hanover, NH 3755, USA akapadia@cs.dartmouth.edu Nikos Triandopoulos Department

More information

Sybil defenses via social networks

Sybil defenses via social networks Sybil defenses via social networks Abhishek University of Oslo, Norway 19/04/2012 1 / 24 Sybil identities Single user pretends many fake/sybil identities i.e., creating multiple accounts observed in real-world

More information

Distributed Information Processing

Distributed Information Processing Distributed Information Processing 14 th Lecture Eom, Hyeonsang ( 엄현상 ) Department of Computer Science & Engineering Seoul National University Copyrights 2016 Eom, Hyeonsang All Rights Reserved Outline

More information

Scaling Out Key-Value Storage

Scaling Out Key-Value Storage Scaling Out Key-Value Storage COS 418: Distributed Systems Logan Stafman [Adapted from K. Jamieson, M. Freedman, B. Karp] Horizontal or vertical scalability? Vertical Scaling Horizontal Scaling 2 Horizontal

More information

Overlay Networks. Behnam Momeni Computer Engineering Department Sharif University of Technology

Overlay Networks. Behnam Momeni Computer Engineering Department Sharif University of Technology CE443 Computer Networks Overlay Networks Behnam Momeni Computer Engineering Department Sharif University of Technology Acknowledgments: Lecture slides are from Computer networks course thought by Jennifer

More information

Purpose and security analysis of RASTER

Purpose and security analysis of RASTER Purpose and security analysis of RASTER Oliver Gasser Advisor: Christian Grothoff Seminar Future Internet SS2010 Lehrstuhl Netzarchitekturen und Netzdienste Fakultät für Informatik, Technische Universität

More information

Small-World Overlay P2P Networks: Construction and Handling Dynamic Flash Crowd

Small-World Overlay P2P Networks: Construction and Handling Dynamic Flash Crowd Small-World Overlay P2P Networks: Construction and Handling Dynamic Flash Crowd Ken Y.K. Hui John C. S. Lui David K.Y. Yau Dept. of Computer Science & Engineering Computer Science Department The Chinese

More information

A Decentralized Content-based Aggregation Service for Pervasive Environments

A Decentralized Content-based Aggregation Service for Pervasive Environments A Decentralized Content-based Aggregation Service for Pervasive Environments Nanyan Jiang, Cristina Schmidt, Manish Parashar The Applied Software Systems Laboratory Rutgers, The State University of New

More information

Towards Benchmarking of P2P Technologies from a SCADA Systems Protection Perspective

Towards Benchmarking of P2P Technologies from a SCADA Systems Protection Perspective Towards Benchmarking of P2P Technologies from a SCADA Systems Protection Perspective CIIP at Mobilight 2010 Abdelmajid Khelil, Sebastian Jeckel, Daniel Germanus and Neeraj Suri 11.05.10 Abdelmajid Khelil

More information

Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications

Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 11, NO. 1, FEBRUARY 2003 17 Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Ion Stoica, Robert Morris, David Liben-Nowell, David R. Karger,

More information