Peer-to-Peer Systems (cntd.) 15/11 – 2004 INF5070 – Media Servers and Distribution Systems:

CFS – Cooperative File System

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems CFS – Cooperative File System  Design Challenges  Distribute files in a peer-to-peer manner  Load Balancing — spread storage burden evenly  Fault tolerance — tolerate unreliable participants  Speed — comparable to whole-file FTP  Scalability — avoid O(#participants) algorithms  CFS approach based on Chord  Blocks of files are indexed using Chord  Root block found by file name, refers to first directory block  Directory blocks contain hashes of blocks DF B1 B2 Public key Root Block signature Directory Block Inode Block Data Block Data Block H(D) H(F)H(B1) H(B2)

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems CFS Replication Mechanism  Increase availability (fault tolerance)  Increase efficiency (server selection)  The predecessor of the data block returns its successors and their latencies  Client can choose the successor with the smallest latency  Ensures independent replica failure N40 N10 N5 N20 N110 N99 N80 N60 N50 Block 17 N Replicate blocks at r successors

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems N40 N10 N5 N20 N110 N99 N80 N60 Lookup(BlockID=45) N50 N RPCs: 1. Chord lookup 2. Chord lookup 3. Block fetch 4. Send to cache CFS Copies to Caches Along Lookup Path CFS Cache Mechanism

Pastry

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Pastry  “Competitor” to Chord and Tapestry (and CAN and …)  Approach taken  Only concerned with efficient indexing  Distributed index  Decentralized lookup service for key/value pairs  Uses DHTs  Content handling is an external problem entirely  No relation to content  No included replication or caching  P2P aspects  Every node must maintain keys  Adaptive to membership changes  Leaf nodes  Client nodes act also as file servers

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Pastry  DHT approach  Each node has Unique nodeId  Assigned when node joins  Used for routing  Each Message has a key  NodeIds and keys are in base 2 b  b is configuration parameter with typical value 4 (hexadecimal digits)  Pastry node routes the message to the node with the closest nodeId to the key  Number of routing steps is O(log N)  Pastry takes into account network locality  Each node maintains  Routing table is organized into  log 2 b N  rows with 2 b -1 entry each  Neighborhood set M — nodeId’s, IP addresses of  M  closest nodes, useful to maintain locality properties  Leaf set L — set of  L  nodes with closest nodeId

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Pastry Routing b=2, so nodeId is base 4 (16 bits) Contains the nodes that are numerically closest to local node Contains the nodes that are closest to local node according to proximity metric 2 b -1 entries per row  log 2 b N  rows Entries in the n th column share the first n digits with current node common prefix – next digit – rest n th digit of current node Entries in the m th row have m as next digit Entries with no suitable nodeId are left empty

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems 1331 X 1 : | | | X 2 : | | | L: 1232 | 1221 | 1300 | X 0 : | | | source 1221 des t Pastry Routing

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Pastry  Assessment  Scalability, fairness, load balancing  Distributed index of arbitrary size  Support for physical locality and locality by hash value  Stochastically logarithmic search effort  Network topology is partially accounted for, given an additional metric for physical locality  Stochastically logarithmic lookup in large systems, variable lookup costs  Content location  Search by hash key: limited ways to formulate queries  All indexed files are reachable  Not restricted to file location  Failure resilience  No single point of failure  Several possibilities for backup routes

Streaming in Peer-to-peer networks

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Peer-to-peer network

Promise

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Promise  Video streaming in Peer-to-Peer systems  Video segmentation into many small segments  Pull operation  Pull from several sources at once  Based on Pastry and CollectCast  CollectCast  Adds rate/data assignment  Evaluates  Node capabilities  Overlay route capabilities  Uses topology inference  Detects shared path segments  Using ICMP similar to traceroute  Tries to avoid shared path segments  Labels segments with quality (or goodness)

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Promise [Hafeeda et. al. 03] Receiver active sender standby senderactive sender Thus, Promise is a multiple sender to one receiver P2P media streaming system which 1) accounts for different capabilities, 2) matches senders to achieve best quality, and 3) dynamically adapts to network fluctuations and peer failure Each active sender: receives a control packet specifying which data segments, data rate, etc., pushes data to receiver as long as no new control packet is received standby sender The receiver: sends a lookup request using DHT selects some active senders, control packet receives data as long as no errors/changes occur if a change/error is detected, new active senders may be selected

SplitStream

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems SplitStream  Video streaming in Peer-to-Peer systems  Uses layered video  Uses overlay multicast  Push operation  Build disjoint overlay multicast trees  Based on Pastry

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems SplitStream Source: full quality movie Stripe 2 Stripe 1 [Castro et. al. 03] Each node: joins as many multicast trees as there are stripes (K) may specify the number of stripes they are willing to act as router for, i.e., according to the amount of resources available Each movie is split into K stripes and each stripe is multicasted using a separate three Thus, SplitStream is a multiple sender to multiple receiver P2P system which distributes the forwarding load while respecting each node’s resource limitations, but some effort is required to build the forest of multicast threes

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems SplitStream  Easy to build disjoint trees  Disjoint tree  Guaranteed  in the overlay  Contrast to disjoint tree in Promise  Best-effort only  At the IP level Example:Use source nodes: , Use degree 2 Inner nodes from ● ● ● ● ● ● Inner nodes from ● ● ● ● ● ●

2004 Carsten Griwodz & Pål Halvorsen INF5070 – media servers and distribution systems Some References 1.M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Rowstron and A. Singh, "SplitStream: High-bandwidth multicast in a cooperative environment", SOSP'03, Lake Bolton, New York, October Mohamed Hefeeda, Ahsan Habib, Boyan Botev, Dongyan Xu, Bharat Bhargava, "Promise: Peer-to-Peer Media Streaming Using Collectcast", ACM MM’03, Berkeley, CA, November Sitaram, D., Dan, A.: “Multimedia Servers – Applications, Environments, and Design”, Morgan Kaufmann Publishers, Tendler, J.M., Dodson, S., Fields, S.: “IBM e-server: POWER 4 System Microarchitecture”, Technical white paper, Tetzlaff, W., Flynn, R.: “Elements of Scalable Video Servers”, IBM Research Report (87884), Intel, 7.MPEG.org, 8.nCUBE,