Opportunistic and Peer-to-Peer Networks

Peer-to-Peer Networks

Kalman Graffi Heinrich Heine Universität Düsseldorf 16 April 2015 2

Call for Papers

Tools to be used

Conference Web Site –  http://www.tsn.hhu.de/teaching/lectures/2015ss/oppp2pnet.html

Conference management tool EasyChair –  For seminar paper & reviews management –  https://easychair.org/conferences/?conf=oppp2pnet2015

Simulator to use: PeerfactSim.KOM –  www.peerfact.org –  Visit website for documentation

Doodle for topic selection –  http://doodle.com/59payaptnc2e3ygu

Schedule

09. April 2015 –  Organizational details –  Presentation of the topics –  Time for questions

09.-21. April 2015 –  Doodle-based choosing of seminar topics

23. April 2015

–  Assignment to the topics

23. July 2015

–  Final presentation

Overview on Topics

Peer-to-Peer Networks PA1 - Simple Replication – TA PA2 - Erasure Code based Replication – RA PA3 - File Sharing of linked and connected Files – RA PO1 - Location-based Overlay using Space-filling Curves – TA PO2 - Location-based 2-dimensional Overlay – TA PM1 - Security in P2P Monitoring Networks – AD PM2 - Trees also want to Gossip – AD PM3 - Memory-based Mechanism for Document Statistics – AD PM4 - Publish/Subscribe-based Mechanism for Document Statistics – AD PM5 - Publish/Subscribe-based Mechanism for Document Statistics – AD Mobile Ad Hoc and Opportunistic Networks MO1 - MANET Testbed with Raspberry PIs - AC MO2 - Opportunistic Network Testbed with Raspberry PIs - AC MO3 - Scheduling Messages in Opportunistic Networks – SS MO4 - Local Connectivity Options between Android Devices - AI MO5 - Local Connectivity Options for Android Devices and Raspberry Pis - AI

http://doodle.com/59payaptnc2e3ygu

Peer-to-Peer Systems

Much more information to be found here: http://www.tsn.hhu.de/teaching/lectures/2014ws/p2p.html

Networks

Peer-to-Peer Networks –  Network of equal participants – Application Layer –  Freedom to create logical topologies, harness node resources –  Strong heterogeneity, churn (on/offline behavior), no trust –  Focus on data management

Opportunistic Networks –  Mobile Ad Hoc Networks that span „local communication islands“ –  Mobility of nodes

•  à connect islands over time à delay tolerant communication –  Focus on routing / communication – Network Layer

Combination of both –  Mobile decentralized network with p2p network on top

A few Definitions for Peer-to-Peer Systems

Peer-to-peer systems and applications are distributed systems without any centralized control or hierarchical organization, where the software running at each node is equivalent in functionality. [...] The core operation in peer-to-peer systems is efficient location of data items.

–  I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications”

Peer-to-peer systems can be characterized as distributed systems in

which all nodes have identical capabilities and responsibilities and all communication is symmetric.

–  A. I. T. Rowstron and P. Druschel, “Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems“

The sheer scale and dynamism in which P2P networks are supposed to operate make the design of P2P systems challenging even for relatively simple applications.

–  M. Naor and U. Wieder, “Novel architectures for p2p applications: the continuous-discrete approach“

Detailed Characteristics - Properties

1. Self-organizing system –  Relevant mechanisms performed by peers

•  No central control •  Decentralized resource search, allocation and scheduling

–  (Sometimes, servers assist à centralized p2p systems)

2. Combined client and server functionality –  Resources provided by end systems

•  Storage, communication (forwarding messages) –  Mostly similar rights – same code!

•  Roles based on capabilities

3. Direct interaction between peers (= “peer to peer”) –  Provision of services, such as: search, data hosting,

communication

Detailed Characteristics - Challenges

4. Relevant resources located at (private) nodes (peers) –  Uncontrolled, voluntary offers –  Widely spread –  Often operating behind firewalls or NAT gateways –  Requires proper mechanism to find and use

5. Capacities of peers are heterogeneous –  Bandwidth, CPU power, storage space, … –  Quality depends on device / connectivity

6. Churn: variable connectivity –  Peers are online for a limited time –  Very unpredictable, not reliable

Overlay Networks

A network

–  interconnected nodes –  provides services (service model) –  defines how nodes interact –  needs for addressing, routing, …

Overlay network –  = network built ON TOP of one or more existing networks –  adds an additional layer of

•  abstraction •  indirection/virtualization

TCP/IP

Peers Overlay Network

Underlay Networks

Schematic View on P2P Systems

IP Network (Underlay) providing: Routing

Overlay Network providing: Search / Lookup of Data Multicast, Data Storage Publish/Subscribe…

Peer-to-Peer Service Delivery

Firewall + NAT TCP/IP Network

TCP/IP Network TCP/IP

Network

Typical Service / Content Discovery and Provision

Intelligence in the network –  Enabling search for resources –  “Content”-based routing –  Provider and client matching –  All roles are distributed fulfilled by large number of nodes

Node Node Node Node

Network

Advanced Network

Summary on the motivation

A huge number of nodes participating in the network –  Have resources to share –  Have demands towards the use of resources

which may not be satisfied easily and by single nodes ??? Main question for “intelligent network”

–  How to find nodes providing desired resources –  How to organize the exchange of resources

Peer-to-Peer (P2P) –  P2P builds overlay network(s) –  P2P overlay offers mechanisms to find / look up what is wanted

Mode of operation –  After locating the node providing the desired service: –  Interact directly from peer to peer

Challenges in P2P related Data Management and Retrieval

Essential challenges in (most) Peer-to-Peer systems –  Location of a data items at distributed systems

•  Where shall the item be stored by the provider? •  How does a requester find the actual location of an item?

Challenges –  Scale – potentially millions of nodes –  Dynamism – nodes go regularly online and offline

Data item „D“

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 89.11.20.15

I have item „D“. Where to place „D“?

I want item „D“. Where can I find „D“?

Structured and Unstructured P2P Networks

Unstructured P2P Networks –  objects have no special identifier –  location of desired object a priori not known –  each peer is only responsible for objects it submitted

Structured P2P Networks –  peers and objects have identifiers –  objects are stored on peers according to their ID:

responsibleFor(ObjID) = PeerID –  distributed indexing points to object location

Search:

–  Find all (or some) objects in the P2P network which fit to given criteria Lookup / Addressing:

–  Retrieve the object which is identified with a given identifier

Structured Overlay Networks: Interconnection Networks

Structured Overlay Networks –  Give peers and objects (unique) identifier

•  PeerIDs and ObjectIDs shall be from the SAME key set •  Each peer is responsible for a specific range of ObjectIDs

–  Indexing (knowledge on location of resources) to be distributed –  No search needed anymore (local indexing) –  No server knowing all (global indexing) available

New challenge: to find peer(s) with specific ID in overlay

–  Lookup: •  “Route” queries across the overlay network to peer with specific ID

–  Once peer is found •  Initiate direct communication •  Upload / download resources

Schematic View on Distributed Hash Table

Functions in a Structured P2P Overlay (all) IsMyKey(K) à true if node is responsible for Key K Route(K, M, hint) à send message M to node responsible for K

§  Hint: Optional first hop GetNodeHandle (K, hint) à get contact details of responsible node Send(M, q) à Send Message M to node q

Additional Functions in a Distributed Hash Table

Put (Data D, Key K) à Copies Data to node responsible for K GetData (Key K) à Gets Data stored under the Key K Optional further functions:

–  Replication –  Secure Communication –  Access Control

H(„my data“)= 3107

7.31.10.25

peer-to-peer.info

12.5.7.31

95.7.6.10

86.8.10.18

planet-lab.orgberkeley.edu

29063485

201116221008709

89.11.20.15

Look up in Structured P2P Systems

Principle –  Location of the objects is found via routing

•  � Node A (provider) advertises object at responsible peer B »  Advertisement is routed to B.

•  � Node C looking for object sends query »  Query is routed to responsible node.

•  � Node B replies to C by sending contacting information of A

1. Publish link at responsible Peer

3. P2P com-munication. Get link to object.

2. “Routing” to / Lookup of desired Object

Node A

Node B

Node C

Strategies for Data Retrieval: Distributed Indexing

Goal is scalable complexity for –  Communication effort: O(log(N)) hops –  Node state: O(log(N)) routing entries

H(„my data“)= 3107

7.31.10.25

peer-to-peer.info

12.5.7.31

95.7.6.10

86.8.10.18

planet-lab.orgberkeley.edu

29063485

201116221008709

89.11.20.15

Routing in O(log(N)) steps to the node storing the data

Nodes store O(log(N)) routing information to other nodes

The content of this slide has been adapted from “Peer-to-Peer Systems and Applications”, ed. by Steinmetz, Wehrle

Structured Homogenous P2P Overlay Networks – Chord

This slide set is based on the lecture "Communication Networks 2" of Prof. Dr.-Ing. Ralf Steinmetz at TU Darmstadt

Chord: An Efficient Lookup Network

Chord uses SHA-1 hash function –  Results in a 160-bit object/node identifier –  Same hash function for objects and nodes

Node ID hashed from e.g., IP address Object ID hashed from object name

–  Object names assumed to be known Chord is organized in a ring which wraps around

–  Nodes keep track of predecessor and successor •  System invariant for valid network operation

–  Node responsible for •  objects between its predecessor and itself

–  Fingers used to enable efficient content addressing •  O(log(N)) fingers lead to lookup operation of O(log(N)) length

Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications (2001) by Ion Stoica, et.al.

Chord: Network Topology

Basic ring topology –  Successor/

Predecessor

Uses SHA-1to map –  IP address/object name

onto –  160 Bit ID

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-4047 0-611 Peers are responsible

for own ID and IDs back to predecessor

Chord: Network Topology

Enhanced topology –  kth finger of Peer n is shortcut pointing

to peers being responsible for Object ID (n + 2^k) –  k ranges from 0 to log(N) –  O(log(N)) fingers lead to lookup operation of O(log(N))

Fingers points to peers with ObjectIDs increasing exponentially. Here: 709 + 2k

= …, 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-4047 0-611

Example Peer ID 7, ID range: 0 - 127

17 peers in the network: –  3, 7, 10, 19, 21, 31, 36, 37, 51,

60, 65, 78, 82, 90, 93, 101, 105

log_2(128) = 7 à 7 fingers

–  Calculate finger IDs, find corresponding peers

Peer ID From To 3 106 3 7 4 7 10 8 10 19 11 19 21 20 21 31 22 31 36 32 36 37 37 37 51 38 51 60 52 60 65 61 65 78 66 78 82 79 82 90 83 90 93 91 93 101 94 101 105 102 105

Responsibility range

Finger No. Calculation Finger ID Real Peer

0 10+2^0 11 19 1 10+2^1 12 19 2 10+2^2 14 19 3 10+2^3 18 19 4 10+2^4 26 31 5 10+2^5 42 51 6 10+2^6 74 78

Fingers of node 10

Chord: Addressing Content

Query –  Contains the hash value of the queried content –  On each step the distance from the destination is halved

(remember fingers)

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

Responsible for 1008 + 1024

Responsible for 3000

Chord: Join Procedure (1)

Request to join the Chord ring

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

1. Set successor

Chord: Join Procedure (2)

Request to join the Chord ring

2207 2012-2207

2906 2683-2906 3485

2907-3485

2011 1623-2011

Nx:1622 1290-1622 Ny:1008

710-1008 709 660-709

659 612-659

2682 2208-2682

611 3486-… 0-611

4. Build fingers

2. Redistribute indexing information (e.g. 1009-1289)

3. Update successor of predecessor

Nz:1289 1009-1289

1. & 2. Notify Successor Actions: NZ: Set Successor (NX) NZ: Notify NX NX: Set Predecessor NX: Copy items (index) to NZ

3. & 4. Stabilize Actions: NY: Ask Predecessor of NX NY: Set Successor (NZ) NY: Notify NZ NZ: Set Predecessor (NY) NX: Clear moved items All: Fix Fingers

Fingers of peer n pointing to peers responsible for ObjectID n + 2k thus, log(N) fingers are built

Chord – Evaluation

Advantages –  Lookups will find the target (if it exists) –  Good scalability of O(log n) –  Very popular, shows main idea of DHTs –  Often used as basis for research extensions

Drawbacks

–  Heterogeneity not supported •  all nodes are treated equally, although some are strong/weak

–  Maintaining unidirectional links (fingers) is only beneficial for one party

•  Traffic costs not optimally used –  Only one-directional routing: not optimally efficient

Location-based P2P Overlay Networks – Space-filling Curves – Geodemlia

This slide set is based on the lecture "Communication Networks 2" of Prof. Dr.-Ing. Ralf Steinmetz at TU Darmstadt

Location-aware Services

Answering on questions: –  “Where I am?” = Locating –  “What is near by? Where is …” = Searching

–  “How can I go to?” = Navigating

Location-aware services…

–  are highly attractive for end-users and providers

–  they can offer highly personalized services based on the user‘s location

Example:

–  List Italian restaurants within walking distance

Closest Italian restaurant?

Space-Filling Curves

Main idea: –  Fill 2-dimensional space with

1-dimensional curve –  Map 1 dimensional curve to Chord –  à Each position in 2D map is

managed by a node in Chord

Expected limitations:

Geodemlia

Geodemlia –  Structured p2p overlay –  Location-based –  Similar to Kademlia

Geographical position: Pos = (long,lat) –  Longitude: -180° .. 180° –  Latitude: -90° .. 90°

Each node: –  Geographical position –  IP contacts –  Random identifier, 160 bits

Each object

–  Geographical position –  Set of tags –  Random identifier, 160 bits

Geodemlia - Interface

FIND_NODES(pos, k, b) –  Pos – Point in the world which is searched –  k – closest nodes to be replied –  b – bloom filter of already known nodes

STORE(o, pos) –  Object o to be stored –  Position pos of the object

AREA_SEARCH(pos, r, s, b) –  Pos – Point in the world which surrounding is searched –  r – Radius around the point to be covered –  s – set of search terms –  b – bloom filter of already known nodes

Geodemlia – Routing Table

Routing Table –  Predefined directions: 0 … n-1

•  Based on the angle (-π .. π) starting north

–  For each direction j •  K-buckets are maintained •  160 buckets for distances

2^i – 2^(i+1)

–  Routing table entry – per peer •  Position (long, lat) •  Peer ID (160 bits) •  IP contacts

Example: n=4

Geodemlia Routing

FIND_NODES(pos, k, b) –  „Like Kademlia“ –  Parallel routing (alpha) –  Iterative routing – k closest nodes

Approaching the target position

–  Like in Kademlia –  Only position-based –  Using Bloom-filters to

signal already known nodes

FIND_NODES(Pos, 2, ---)

k closest nodes to POS k closest nodes to POS

FIND_NODES(Pos, 2, Bloom)

FIND_NODES(Pos, 2, Bloom) Newly learned closest nodes Already queried nodes

Geodemlia Routing

STORE(o, pos) –  First find nodes at position pos –  Store object o at k closest peers

AREA_SEARCH(pos, r, s, b) –  Similar to FIND_NODES – just with larger scope –  All nodes in radius around position are contacted –  They tell their fitting objects

Improvements of P2P Overlays

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

Responsible for 3000

Simple Replication

Motivation –  Object stored at only one node: lost if node leaves

–  Replication through multiple IDs per object –  File published under each ID –  File looked up under next ID if lookup for previous IDs failed –  Number of replicas flexible

Examples

–  Multiple hash functions •  ID_1: h1(object), ID_2: h2(object), ID_3: h3(object), …

–  Sequential hashing •  ID_1: h(object), ID_2: h(ID_1), ID_3: h(ID_2), …

Evaluation of Simple Replication

Good –  Easy to implement

Shortcommings

–  Hashes of ID_i and ID_i+1 not close, each one requires a new lookup

–  If number of replica fixed (i.e. i=5) •  Too much replication in stable scenario, too few in dynamic scenario

–  If number of replica flexible •  Determined by each replica holder to adapt load / churn risk •  How to know how long the replica chain is?

Improvement of simple replication: PAST

–  Replication around a single ID

Redundancy through full copy replication

Traditional replication: –  Several copies of same content

Example PAST (extension to Pastry): Nodes [] replicaSet (key à k, int à max rank)

–  Returns an ordered set of peers of magnitude (max rank) on which replicas of the object with key k can be stored

–  The nodes which become roots for the key k when the local node fails

12469 3 5 7 8

PAST Evaluation

Good –  ID related replication: 1 lookup sufficient to find object –  Replication ratio flexible (might depend on object / peer

properties) –  Failed replica nodes are detected by overlay: easy to react

Drawback –  Replication not peer heterogeneity aware

•  Weak nodes might be overloaded by replication task –  Security

•  Replicas all in one ID area: easier to attack

Erasure Codes

Erasure codes –  Split content in blocks (symbols) (e.g. 50) –  Create redundancy in blocks

•  à e.g. 200 blocks –  For restoring content

•  50 out of 200 blocks needed

Slide based on Anwitaman Datta, “Peer�-to-Peer Storage Systems: Crowdsourcing the Storage Cloud“, ICDCN’10

Erasure Codes: Static Resilience

Replicated 𝑟 times –  Faults that can be tolerated: r - 1 –  Probability of failure: f^r –  Storage efficiency: 1/r –  Access: Find any one good replica

Erasure coded (k of n)

–  Faults that can be tolerated: n-k –  Probability of failure:

–  Storage efficiency: k/n –  Access: Find k good blocks

Assume: Peer failure is i.i.d. with failure probability 𝑓

Jun.-Prof. Dr.-Ing. Kalman Graffi, Peer-to-Peer Systems, WS 2013/2014 7

Erasure Codes: Static Resilience

Replicated 𝑟 times � Faults that can be tolerated: 𝑟 − 1 � Probability of failure: 𝑓 � Storage efficiency: 1/𝑟 � Access: Find any one good replica

Erasure coded (k of n)

� Faults that can be tolerated: 𝑛 − 𝑘 � Probability of failure:

∑ 𝑛𝑛 − 𝑘 + 𝑗 𝑓 1 − 𝑓

� Storage efficiency: k/n � Access: Find 𝑘 good blocks

Assume: Peer failure is i.i.d. with failure probability 𝑓

Slide based on Anwitaman Datta, “Peer•-to-Peer Storage Systems: Crowdsourcing the Storage Cloud“, ICDCN’10

Example: Static Resilience

Churn rate, f=0.25 Replication

–  r = 5 •  à Availability ~ 0.73 •  Too low

–  r = 24 •  à Availability > 0.999 •  Too much overhead!

Erasure code

–  N=517, k=100 •  à Availability ~ 0.999 •  Overhead = 5.17

Monitoring the Quality of Peer-to-Peer Systems – Introduction to P2P Quality Monitoring – Gossip-based solutions – Tree-based solutions

Quality of Service in P2P Networks

Quality of service (QoS) –  “The well-defined and controllable behavior of a system with

respect to quantitative parameters” Challenges for providing (constant) quality in p2p systems:

–  Various scenarios •  Distributed storage •  Content delivery •  Discovery and contacting of users

–  Dynamics over time •  Network size •  Churn

–  Peer heterogeneity •  Peer capacities •  Connectivity

Overlay

Application

Devices

Network

Manage-ment

Monitoring and Controlling System Metrics

Examples –  Statistics: minimum, maximum, average, standard deviation –  P2P system: peer count, online time, –  Overlay “metrics”: Hop count, routing delay –  Overhead: bandwidth consumption and traffic (per message type) –  Resources: Free / used CPU, memory, storage space, bandwidth

Monitoring –  Obtain (global) knowledge on the system statistics

•  Aggregatable: Size of statistics for 10 or 1000 peers equal •  Statistics must be fresh, monitoring mechanism of low overhead

–  Information on system status can be used for optimized decisions •  E.g. peer count defines size of time-to-live •  E.g. churn pattern defines stabilization frequency

P2P Monitoring

Goal: Obtaining statistics on the global system –  Input: local states x_i(t) of peers p_i at time t –  Output: global status (aggregate) at time t: F(t) = f(x_1(t),…,x_n(t))

Aggregate function: f(R*) à R –  Matches non-empty set of values to a single value –  Associative (aggregation of aggregations) –  commutative (order not relevant)

Operations: –  Add local statistics –  Get global statistics

Monitoring the Quality of Peer-to-Peer Systems – Gossip-based Approaches

► Gossiping Protocols

Idea: –  Communicate only with neighbors (gossip)

•  Assumes no specific overlay topology –  Exchange and aggregate information

•  E.g. calculate averages, minimum, maximum

Characteristics –  Gossip protocols are round-based (epochs) –  For every round

•  Each node selects a subset of nodes to interact with (pairwise) •  The selection function is often probabilistic; •  Nodes interact via “small” messages •  Local state changes due to new information

–  In general: “quick” convergence D. Kempe, A. Dobra,J. Gehrke, “Gossip-Based Computation of Aggregate Information,” IEEE Symposium on Foundations of Computer Science (FOCS’03)

Example Average Calculation

Example: 12 nodes –  Initial state –  After 1 round

•  With communication links –  After 5 rounds –  After 10 rounds

Gossip-Protocol: PushSum

Initialization of PushSum

Calculation of the Sum

–  One nodes starts with 1, all others with 0 –  Create average, once converged: sum = 1 / average

–  Example:

Observation: –  During the gossiping: local input x_i cannot be changed –  Aggregations round-based (epochs)

Initializing an Epoch –  Centralized

•  Several leader algorithms exist –  E.g. node with maximum specific value

•  Epoch may be restarted periodically by leader

–  Decentralized •  Besides local measure (x_i) and weight (w_i): add version number •  Every node may start new epoch concurrently

–  Larger version numbers dominate smaller ones –  Epoch runs out after convergence and minimal value variations (<ε)

Initializing an Epoch and Peer Election

Performance and Complexity of Push-Sum

Performance: precision –  Simulations with 1M nodes

•  Gossip every 5 second –  For most time:

•  False values •  Although convergence exist

–  Problem •  Peer count starts always at 0

Convergence time •  n = number of nodes •  ε = accepted relative error

–  Push-Sum converges quickly –  Problem:

•  Huge message overhead per node

W. Terpstra, C. Leng, A. Buchmann: Brief Announcement: Practical Summation via Gossip, ACM Symposium on Principles of Distributed Computing (PODC 2007)

In-pre-cise

Monitoring the Quality of Peer-to-Peer Systems – Tree-based Approach: SkyEye.KOM

► Tree-based Monitoring Mechanism

Idea: –  Create (additional) tree topology on top of DHT –  Protocol:

•  Periodically –  Calculate aggregate of own local view and received from child nodes –  Send aggregate to parent node

•  Root calculates global view –  And passes global view to all peers

Example: SkyEye.KOM (2009)

–  Assumes structured p2p overlay –  Aims at high precision with low overhead

SkyEye.KOM: Tree Topology

Tree of information domains –  Domain: ID interval

•  E.g. [0, 0.5[ or [0.75, 0.875[ •  Largest domain, level 0: [0,1[

–  Domain ID: “middle value” in interval

–  Domain size split in β parts per level

Domain IDs build tree topology

–  Node degree: β child nodes –  Tree topology of Domain IDs does

not change over time! •  Only the peers responsible for the

Domain IDs might change –  Assignment of peers to domains

dynamic

1 10 50

20 30 40

P2P Overlay

0 1 0.09 0.2 0.31 0,4 0.5 0.6 0.75 0.9

Internet

0,3125

0.875 0.625 0.125

Domain Domain ID

0.3125

SkyEye.KOM: Communication

Example tree –  Tree degree (β) = 2

•  Results in logarithmic tree size

–  Balanced, if ID space balanced

–  Not always β children •  Peers may be Coordinators

at various levels

SkyEye.KOM: Communication Protocol

Gathering global view –  All peers measure local

status –  Periodically sent to parent

peer •  à Update Interval (UI)

Aggregation –  Direct: count, sum, minimum,

maximum, sum of squares –  Derived: mean, variance, std.

deviation

Dissemination of global view –  Global view in root –  Every update message is

acknowledged –  Contains global view from

level above

Global view

Local measures, (synchronized signal in simulations)

Aggregated view

β child nodes

… 1a 1b 1β

1. Independent updates in UI intervals per node

2b 2a 2β

2. ACKs with view of parent peer for every update

Evaluation of SkyEye.KOM

Simulation Setup –  Node count 5000 –  Churn: Join, KAD churn –  Tree degree = 4 –  Update interval = 60sec

Observation: –  Time delayed, precise

monitor –  Very low overhead

•  <100 bytes / s •  Overhead is precisely

monitored

► Benchmarking of Monitoring Solutions

Structured / tree-based solutions –  Limited in applicability à key-based routing needed

Unstructured / gossip-based solutions –  Needs only connected graph à not limited in application

Question: –  Why do not we use only gossip-based solutions?

Answer: –  They are inefficient –  Imprecise OR costy

Comparative Evaluation –  Node count: 1000, churn –  SkyEye.KOM: UI=15 sec, β = 8, synchronized (every 20min) –  PushSum: 30 messages per epoch –  Centralized for comparison, UI = 60 sec –  Same overhead allowed for all monitoring approaches

Churn – Reference: Node Count

Simulation setup –  Churn with joining and

instantly leaving nodes –  Both decentralized

solutions •  Use ca. 200 bytes/s per

node •  For better comparability

Aggregation time –  Of global view –  Performance of tree similar

to centralized solution –  Gossip-approach slower

•  Sawtooth: epochs

Reference Signals: Steps, Sawtooth and Sine PushSum

–  Imprecise monitoring –  Epochs are visible –  Although same traffic

overhead Centralized and tree-based

–  Precise –  Tree become imprecise with

too much churn

http://doodle.com/59payaptnc2e3ygu

Peer-to-Peer Networks PA1 - Simple Replication – TA PA2 - Erasure Code based Replication – RA PA3 - File Sharing of linked and connected Files – RA PO1 - Location-based Overlay using Space-filling Curves – TA PO2 - Location-based 2-dimensional Overlay – TA PM1 - Security in P2P Monitoring Networks – AD PM2 - Trees also want to Gossip – AD PM3 - Memory-based Mechanism for Document Statistics – AD PM4 - Publish/Subscribe-based Mechanism for Document Statistics – AD PM5 - Publish/Subscribe-based Mechanism for Document Statistics – AD Mobile Ad Hoc and Opportunistic Networks MO1 - MANET Testbed with Raspberry PIs - AC MO2 - Opportunistic Network Testbed with Raspberry PIs - AC MO3 - Scheduling Messages in Opportunistic Networks – SS MO4 - Local Connectivity Options between Android Devices - AI MO5 - Local Connectivity Options for Android Devices and Raspberry Pis - AI

Opportunistic and Peer-to-Peer Networks › fileadmin › redaktion › ...Apr 16, 2015 ·...

Documents

Chord: A Scalable Peer-to-peer Lookup Service for Internet ...rich/class/cs293b-cloud/papers/chord.pdfChord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion Stoica∗

Chdhord (CAN,Tapestry, Pastry) [Stoica01a]mhchen/CN2010/Slides/P2P_overview_… · Stoica, R. Morris, D. Karger, F. Kaashoek, and H B l krishn n H.Balakrishnan. Chord: A peer-to-peer

PIER: Peer-to-Peer Information Exchange and Retrieval Ryan Huebsch Joe Hellerstein, Nick Lanham, Boon Thau Loo, Scott Shenker, Ion Stoica p2p@db.cs.berkeley.edu

Robert Morris, M. Frans Kaashoek, David Karger, Hari Balakrishnan, Ion Stoica, David Liben-Nowell, Frank Dabek Chord: A scalable peer-to-peer look-up protocol

Chord: A scalable peer-to-peer lookup service for Internet applications · 2001-12-05 · Chord: A scalable peer-to-peer lookup service for Internet applications Ion Stoica, Robert

(12) United States Patent US 8,850,021 B2 (45) Date of ... › ~caoj › pub › doc › jcao_p_US8850021.pdf · Stoica et al.: “Chord: A Scalable Peer-to-peer Lookup Service for

Stoica Cristian

Aurel Stoica

STOICA EMIL.pdf

Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Stoica et al. Presented by Tam Chantem March 30, 2007

1 Secure Peer-to-Peer File Sharing Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, Hari Balakrishnan MIT Laboratory

Hálózatba kapcsolt erőforrás platformok és alkalmazásaik · 2017-02-27 · Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion Stoica, Robert Morris,

Stoica Lascu

Chord: a scalable peer-to-peer lookup protocol for internet applications … · 2020-04-06 · Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Ion Stoica,

1 Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan

Peer-to-Peer Networking Credit slides from J. Pang, B. Richardson, I. Stoica

Teatru Stoica

Sistemi P2P Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Autori: I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F

Today’s Papers › ~kubitron › courses › ... · • Chord: A Scalable Peer‐to‐peer Lookup Protocol for Internet Applications, Ion Stoica, Robert Morris, David Liben‐Nowell,

CHORD: A Scalable Peer-to-Peer Lookup Service for Internet ...cs527/Lectures2010/9c-Chord-527-10.pdfCHORD: A Scalable Peer-to-Peer Lookup Service for Internet Applications Ion Stoica,