Peer-to-Peer Computing

CSC8530 – Dr. Prasad

Jon A. Preston

April 21, 2004

Agenda

Overview of Peer-to-peer computing Parallel Downloading Peer-to-Peer Media Streaming References

Collaborative Software Engineering

Peer-to-Peer Computing

Autonomy from centralized servers Dynamic (peers added & removed

frequently)

File Sharing (KaZaA – outpaces Web traffic, 3,000 terabytes, 3 million up peers)

Communication (instant messenger) Computation (seti@home)

Peer-to-Peer Computing (cont)

De-centralized data sharing Dynamic growth of system capacity Various data lookup/discovery schemes

– Centralized directory servers (Napster)– Controlled request flooding (Gnutella)– Hierarchy with supernodes (KaZaA)

Heterogeneous collection of peers– Need a way of encouraging reporting of true outgoing

bandwidth

Worldwide Computer(P2P Computation)

“Moonlight” your computer Share/lease processor and storage Process others’ simulations, etc. Archive other’s files (even when computer off) Receive micropayments for services rendered PC is component of worldwide computer “Internet-scale OS” – centralized structure

– Must allocate resources, coordination, security/privacy, etc.

Parallel Downloading

Potential widespread utilization on P2P networks

Past work shows parallel downloading (PD) has higher aggregated downloading throughput

Shorter download times by clients

Communication in PD

Client must determine segments of file for each server request

Alternative: “Tornado Code”– Servers keep sending until client says “enough”– Requires less communication about quantity and

which part of the file the client wants– Does require high buffering on client (entire file)

Parallel vs. Sequential Download

Parallel incurs non-trivial cost– Synchronization– Coordination– Encoding/decoding

Adopt PD if download performance improves significantly…

Large-Scale Deployment of PD

Koo et al developed a model in May 2003 that shows SD is better than PD– Assumes that Capacityservers >> Capacityclients

– Homogenous network– Analyzed average download time– Performance is similar, but SD requires less

overhead

Peer-to-Peer Media Streaming

Peer-to-peer file sharing– Act as server and client– “Open-after-download”

Media Streaming– “Play-while-downloading”– Subset of peers “owns” a media file– These peers stream media to requesting peers– Recipients become supplying peers themselves

Characteristics of P2P Media Streaming Systems

Self-growing – requesting peers become supplying peers (total system capacity grows)

Serverless – each peer is not to act as server (open large number of simultaneous/client connections)

Heterogeneous – peers contribute different outbound connection bandwidths

Many-to-one – many supplying peers to one real-time playing client (hard deadlines)

Two Problems

Media data assignment

Fast amplification

Media Data Assignment

Given– Requesting peer– Multiple supplying peers– Heterogeneous outbound bandwidth on suppliers

Determine– Subset of media to request from each supplier

A B C D

Variable Buffer Delays

Buffer delay dependsupon the orderingof which segments ofthe media file to obtainfrom each supplyingpeer.

Fast Amplification

Differential selection algorithm– Favor higher-class (higher outbound bandwidth)– Ultimately benefit all requesting peers– Should not starve any lower-class peer– Enforced via pure distributed algorithm– Probability of selection proportional to requesting

peer’s promised outbound bandwidth

Variable Capacity Growth

Selection Algorithm

Each supplying peer– Determines which requesting peer to serve– Maintains probability vector – one entry per class

of peers (class defined by bandwidth)– Receives “reminders” from peers

If supplier (Ps) is busy, it can receive a reminder from requesting peer (Pr)

This reminder tells the supplier to remember the requesting peer (Pr) and not elevate other peers in classes below Pr when current service complete

Admission Probability Vector

One entry per class-i set of peers If not busy, Ps grants request of Pr with probability

Pr[i], where i = class of Pr

If Ps is a class-k peer, Pr[i] defined as follows– For i < k, Pr[i] = 1.0 (favored class)– For i >= k, Pr[i] = 1/(2i-k)

If idle, elevate non-favored (and non-served) entries by factor of 2 (i.e. Pr[i] = Pr[i] * 2)

Use reminders to effect what happens after service completed (raise or not)

Making a Request

Knows candidate supplying peers {Ps1, Ps2, … Psn}

Pr will be admitted if it obtains permission from enough suppliers such that aggregated outbound bandwidth sufficient to service request

– Requesting peer then computes media data assignment

If not admitted, send “reminders” to busy supplying peers that favor Pr. Backoff exponentially.

When request is finished, Pr becomes a supplying peer, increasing the overall system capacity.

Differential Acceptance Results

Non-differential Acceptance Results

References

Simon Koo, Catherine Rosenberg, Dongyan Xu, "Analysis of Parallel Downloading for Large File Distribution", Proceedings of IEEE International Workshop on Future Trends in Distributed Computing Systems (FTDCS 2003), San Juan, PR, May 2003.

Dongyan Xu, Mohamed Hefeeda, Susanne Hambrusch, Bharat Bhargava, "On Peer-to-Peer Media Streaming", Proceedings of IEEE International Conference on Distributed Computing Systems (ICDCS 2002), Wien, Austria, July 2002

Ripeanu, M. Peer-to-peer architecture case study: Gnutella network. In International Conference on Peer-to-peer Computing (2001).

J. Kangasharju, K.W. Ross, D. Turner, Adaptive Content Management in Structured P2P Communities, 2002, http://cis.poly.edu/~ross/papers/AdaptiveContentManagement.pdf

Androutsellis-Theotokis S. Whitepaper: A Survey of Peer-to-Peer File Sharing Technologies, Athens University of Economics and Business, Greece, 2002.

Collaborative Software Engineering

Overview of Collaborative Computing Synchronous and Asynchronous Notification Algorithms Distributed Mutex Achieving “undo” and “redo” Transparencies vs. Awareness Distributed Software Engineering

Overview of Collaborative Computing

Utilize computing to improve workflow and coordination/communication– Shared displays/applications– Online meetings– Collaborative development (configuration

management)– Minimize impact of physical distance

Collaboratories– Emulate scientific labs

Synchronous and Asynchronous

Synchronous– Same time, different place– ICQ, Chat, etc.– Can store session

Asynchronous– Different time, same/different place– Email, newsgroups, web forums– Store session, replay

Notification Algorithms

Unicast– Latency potential issue

Multicast– Significant bandwidth consumption– Network flooding

Frequency– Synchronous implies high frequency of change notifications– Asynchronous implies low frequency of change notifications

Granularity– Differentials or whole state– How to incorporate new users (latecomers)

Distributed Mutex

Token-based– Only the process that holds the token can enter the critical

section– Transmission of token algorithm (round-robin, hold & wait

for request)– How does a process know where to request token?

Permission-based– Sends request to enter CS to other processes– Other processes get to “vote”– Process enters CS only if it achieves enough votes

Achieving “undo” and “redo”

Particularly important in collaborative systems– High level of “what if” inherent in the system– Others might adversely affect someone else’s work

In OO-based systems, undo and redo are inverses of each other

In text-based systems, insert and delete are inverses of each other

In bitmap-based systems, undo and redo are not so easy– Save entire image (too much space)– Save only differential area (replay sequence of actions to recreate

state)

Transparencies vs. Awareness

Does the application know about the collaboration or not?

– Transparencies Communication layer sits on top of the application Useful for sharing legacy systems Have no access to source (or cannot modify it) Negative – no concurrency (one input/output at a time)

– Aware Applications Collaboration integrated into the application Requires centralized execution with distributed I/O Or requires a homogeneous architecture (same client on each

users’ machine)

Distributed Software Engineering

Synchronous and asynchronous collaboration

Provide meta view of others in system Allow for viewing of entire current system Fine-grain source locking/check-out Provide sandbox for developers to test/build

local source How do we improve concurrency?

Handling Concurrent Development

Split-combine (low level of concurrent development)

Copy-merge (high level of concurrency, problematic to merge)