GNUSTREAM: A P2P MEDIA STREAMING SYSTEM PROTOTYPE

Xuxian Jiang Yu Dong Dongyan Xu Bharat Bhargava

Department of Computer Sciences

Purdue University, West Lafayette, IN 47907

E-mail: {jiangx,dong,dxu,bb}@cs.purdue.edu

ABSTRACT

receiver-driven media streaming system.

top of Gnutella

integrates

*dynamic peer location and

*streaming capacity aggregation

*GnuStream streaming session is controlled by the

receiver peer

*dynamic set of peer senders

instead of one fixed sender

1. INTRODUCTION

[1] .On Peer-to-Peer Media Streaming.

open-after-downloading.v .play-while-downloading.

peer

*online or offline

sender set members may change dynamically,

*sender: not be able to contribute full streaming bandwidth

set of peer senders

architectures for synchronous broadcast

Narada [3] and PeerCast [4]

þdynamic construction of a multicast tree

ýnot consider the limited

contribution of bandwidth

CoopNet [5] builds

*multiple distribution trees

*spanning a source and all peer receivers

*each tree transmitting a separate description of the media signal.

ý consults the source node for its upstream

peer senders

ZIGZAG [6]

*peer receivers hierarchy of bounded-degree clusters

*multicast tree based on the hierarchy.

ýassumes that each peer only receives from one upstream peer sender.

GnuStream,

receiver-driven

media streaming system

top of Gnutella,

• underlying P2P network dynamics
• heterogeneity.

Features:

• multi-sender bandwidth aggregation,
• adaptive buffer control,
• peer failure or degradation detection and
• streaming quality maintenance

2. SYSTEM OVERVIEW

2.1. System Environment

P1:

• call Gnutella lookup service
• locates four candidate senders P2-P5.
• aggregated bandwidth sufficient full quality?
• P5 standby sender

2.2. System Features

(1) Integration with P2P lookup substrate

readily deployable in the current Gnutella P2P network environment.

(2) Multi-sender aggregation

load allocation policies

• Even allocation

*Suitable for a well-provisioned and homogeneous

environment

• Proportional allocation:

*proportion to the current capability of peer senders

*flexible and adaptive

*dynamic and heterogeneous environment

(3) Receiver data collection

receiver

*coordinates the arrival of different media data segments,

*reconstructs media data in their original and continuous order before *feeding them to the media player.

(4) Detection of peer status change

periodic probing and soft states

detect any changes in the status of peer senders,

• peer disconnection,
• failure, and
• bandwidth degradation

(5) Recovery from failure or degradation:

*migrate all or part of its streaming load to another peer sender or a

standby peer sender

*active peer senders change dynamically

6) Buffer control:

accommodate

*dynamic set of peer senders

*end-to-end network congestion,

buffer control mechanisms

*more concurrency and scheduling complexity

3. DESIGN AND IMPLEMENTATION

3.1. Three-layer Architecture

1. Network Abstraction Layer,
2. Streaming Control Layer and
3. Media Playback Layer

(1) Network Abstraction Layer (NAL)

• masks underlying P2P network
• uniform interface of P2P lookup substrate.
• peer and content discovery
• deployable in Gnutella,
• portable to other P2P networks

(2) Streaming Control Layer (SCL)

• heterogeneity of P2P networks.
• bandwidth aggregation,
• data collection, and
• status change detection and recovery.

• sender set
• maintain the maximum streaming quality èBuffer management essential

(3) Media Playback Layer (MPL):

• adaptable to the aggregated streaming bandwidth
• media quality adaptation

based on the media data collected by SCL

double buffering between media decoder and player

· efficiency

· low switching overhead.

· .plug-n-play.

3.2. GnuStream Implementation

*Microsoft Visual C++ 6.0

*Gnutella client, namely Gnucleus.

buffer management.

• control buffer

core of buffer control mechanisms

• Double display buffers >MPL
• decode buffer >MPL

*speed up display

*reduce the synchronization overhead between MPL and SCL.

• Data collection buffer >SCL

*eliminate data overflow and underflow

*smooth jitter in the presence of multiple senders.

*Inside the control buffer

*coordinate the multiple peer senders

*delicate buffer model is implemented to enforce the real-time property of media streaming.

Buffer Model

• manipulate the control buffer using different control pointers

*offset pointer: amount of data already consumed.

*End-of-data: trunk of continuous data available in buffer

*End-of-buffer indicates the end or maximum

size of buffer

• SCL

*adjusts the data feeding rate to the decoder

*display frame rate is tunable

(according to current aggregated streaming bandwidth)

*monitor the streaming progress

*compute system parameters

-next frame needed and

-expected bit-rate

from each peer sender.

4. EXPERIMENTS

multiple desktop PCs

• XEON CPU 2.00 GHz,
• 1.00G RAM
• 3COM 3C920 100Mbps Integrated Fast Ethernet Controller.

*configured as peer senders/recv

*ý maximum streaming bandwidth=60KB/s

(1) P2P streaming session setup

*Before session starts

• receiver
• compute the aggregated streaming bandwidth
• how many peer senders are needed.

test media clip

• image size 352*240,
• frame rate 30frames/second
• YUV sampling 4:2:0
• bits per pixel, 8
• compression rate 26:1.

resultant streaming bandwidth approximately 143 KBps

receiver

*contacts three peer senders

*discovered by Gnutella lookup service

*each streaming bandwidth of 60KBps.

*initiates the streaming session

(2) Buffering for continuous media playback

*continuous and jitter-free media playback

• receiver
• buffering both before and during
• initial buffering delay = …

if playback > arrival = 1/A – 1/P

else = 0

test video clip

• 1680 frames.
• AFR is 25 fps
• initial buffering delay = 11.2 seconds.

during the initial buffering,

• senders transmit @ same rate as contributed streaming bandwidth
• aggregated streaming bandwidth (3*60KBps) > playback rate (143.0KBps):

• exploit the residual bandwidth to pretransmit media data which will be buffered

(3) Peer failure detection and recovery

• turn off the Gnutella services on one of the peer senders
• test the responsiveness of GnuStream.s peer failure recovery

• 1 second to detect and recovery from the failure,

*replaced standby sender

*detection and recovery latency

*tradeoff

system reactivity v peer probing overhead

*no interruption to media playback

(buffer control)

5. CONCLUSIONS

• readily deployable in Gnutella network.
• dynamics and heterogeneity of P2P
• aggregated streaming capacity = full streaming quality
• self monitoring and adjustment (peer failure and bandwidth degradation)
• open source software system,

http://www.cs.purdue.edu/homes/jiangx/GnuStream/

6. REFERENCES

[1] D. Xu, M. Hefeeda, S. Hambrusch and B. Bhargava, .On

Peer-to-Peer Media Streaming., IEEE ICDCS 2002, July

2002.

[2] T. Nguyen and A. Zakhor, .Distributed Video Streaming

Over Internet., SPIE/ACM MMCN 2002, Jan. 2002.

[3] Y. Chu, S. Rao and H. Zhang, .A Case for End System

Multicast., ACM SIGMETRICS, June 2000.

[4] H. Deshpande, M. Bawa and H. Garcia-Molina,

.Streaming Live Media over a Peer-to-Peer Network.,

Stanford Database Group Technical Report (2001-20), Aug.

2001.

[5] V. N. Padmanabhan, H. J. Wang, P.A. Chou and K.

Sripanijkulchai, .Distributing Streaming Media Content Using

Cooperative Networking., ACM NOSSDAV, May 2002.

[6] D. A. Tran, K. A. Hua and T. T Do .ZIGZAG: An

Efficient Peer-to-peer Scheme for Media Streaming., IEEE

INFOCOM2003, April 2003.

Back to top